From csr21 at cam.ac.uk  Wed Oct 12 16:35:01 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 12 Oct 2005 17:35:01 +0100
Subject: [climacs-devel] Query Replace
Message-ID: <sqek6qsngq.fsf@cam.ac.uk>

Hi,

Asking for Query Replace of the string "X4" to "Xa////" actually
causes "XA////" to be inserted as a replacement.  This isn't what I
expected, and doesn't happen with Emacs' query-replace.

(Also, ESC % doesn't work as a shortcut, though M-% does, probably
because of the :shift modifier in the esa:set-key, and McCLIM not
canonizing it properly).

Cheers,

Christophe


From csr21 at cam.ac.uk  Thu Oct 13 09:43:24 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 13 Oct 2005 10:43:24 +0100
Subject: [climacs-devel] Query Replace
In-Reply-To: <sqek6qsngq.fsf@cam.ac.uk> (Christophe Rhodes's message of "Wed, 
	12 Oct 2005 17:35:01 +0100")
References: <sqek6qsngq.fsf@cam.ac.uk>
Message-ID: <sqslv5kb0j.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Asking for Query Replace of the string "X4" to "Xa////" actually
> causes "XA////" to be inserted as a replacement.  This isn't what I
> expected, and doesn't happen with Emacs' query-replace.

I caved in and "fixed" this myself.  (I think I basically implemented
what's in emacs' docstring for query-replace, but I didn't try testing
it or thinking about what case means in this Unicode world)

> (Also, ESC % doesn't work as a shortcut, though M-% does, probably
> because of the :shift modifier in the esa:set-key, and McCLIM not
> canonizing it properly).

I didn't fix this.

Cheers,

Christophe


From splittist at yahoo.com  Thu Oct 13 16:11:32 2005
From: splittist at yahoo.com (John Q)
Date: Thu, 13 Oct 2005 09:11:32 -0700 (PDT)
Subject: [climacs-devel] Cutting up gui.lisp
Message-ID: <20051013161132.68992.qmail@web33514.mail.mud.yahoo.com>

There's no doubt about it, gui.lisp is a big file.

I propose splitting it up like this:

* gui.lisp - frame and command-table stuff. 
* commands.lisp - miscellaneous command definitions.
* files.lisp - file related commands etc.
* windows.lisp - window related commands etc.
* search.lisp - search related commands etc.
* develop.lisp - development related commands etc.
* unicode.lisp - unicode related stuff.

These probably aren't the best names - perhaps they
should have a '-commands' suffix (eg.
'window-commands.lisp')?

Thoughts? I figured it could all live in the
climacs-gui package for now, too.

JQS/TCO



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


From strandh at labri.fr  Thu Oct 13 17:16:53 2005
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 13 Oct 2005 19:16:53 +0200
Subject: [climacs-devel] Cutting up gui.lisp
In-Reply-To: <20051013161132.68992.qmail@web33514.mail.mud.yahoo.com>
References: <20051013161132.68992.qmail@web33514.mail.mud.yahoo.com>
Message-ID: <17230.38533.845047.250309@serveur5.labri.fr>

John Q writes:
 > There's no doubt about it, gui.lisp is a big file.
 > 
 > I propose splitting it up like this:
 > 
 > * gui.lisp - frame and command-table stuff. 
 > * commands.lisp - miscellaneous command definitions.
 > * files.lisp - file related commands etc.
 > * windows.lisp - window related commands etc.
 > * search.lisp - search related commands etc.
 > * develop.lisp - development related commands etc.
 > * unicode.lisp - unicode related stuff.
 > 
 > These probably aren't the best names - perhaps they
 > should have a '-commands' suffix (eg.
 > 'window-commands.lisp')?
 > 
 > Thoughts? 

Sure.  Perhaps the xyz-commands.lisp convention is better, and use
misc-commands.lisp for what you named commands.lisp above.  But I
don't have a strong opinion.  It is easy to reorganize again should it
not turn out right. 

 > I figured it could all live in the
 > climacs-gui package for now, too.

I agree. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Sun Oct 16 19:57:27 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Sun, 16 Oct 2005 20:57:27 +0100
Subject: [climacs-devel] Re: Query Replace
In-Reply-To: <sqslv5kb0j.fsf@cam.ac.uk>
References: <sqek6qsngq.fsf@cam.ac.uk> <sqslv5kb0j.fsf@cam.ac.uk>
Message-ID: <4352B0A7.9090909@yahoo.com>

Christophe Rhodes wrote:
> Christophe Rhodes <csr21 at cam.ac.uk> writes:
>> (Also, ESC % doesn't work as a shortcut, though M-% does, probably
>> because of the :shift modifier in the esa:set-key, and McCLIM not
>> canonizing it properly).
> 
> I didn't fix this.

I think I did.

JQS


From brad.beveridge at gmail.com  Fri Oct 21 05:41:19 2005
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Thu, 20 Oct 2005 22:41:19 -0700
Subject: [climacs-devel] A few questions about Climacs
Message-ID: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>

Hi all, I have a few questions about Climacs, some that might be a
little heretical ;)
Firstly, from what I have read Climacs sounds like an interesting
project - well done!
So now the heretical part :)
I like Vim (ssshh) rather than Emacs.  I imagine that it shouldn't be
too hard to add an input system that is Vim like - can I please get a
few tips on where to start looking to make these changes?

The reason that I would like to make a Vim like editor in Lisp is that
I think it would be nice for Vim lovers to have an editor that is
closely integrated with Lisp, preferably able to integrate with
Slime/Swank so that the final editor is a nice IDE.
Is Slime integration an eventual goal of Climacs?

Finally, how usable is Climacs as an editor right now?

Thanks
Brad


From athas at sigkill.dk  Fri Oct 21 15:41:24 2005
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 21 Oct 2005 17:41:24 +0200
Subject: [climacs-devel] Question about the info-pane display function
Message-ID: <871x2eri6z.fsf@sigkill.dk>

The display-function for the info-pane/modeline,
climacs-gui::display-info, is very simple, and seems to be a bit
hackish as well (as far as I can see, text for overwrite-mode,
fill-mode and isearch-mode is hard-coded in the function). Is this
simplicity by design, or is it merely a placeholder until something
more flexible can be put in place? If the latter is the case, is
anyone working on it? If not, I might be able to lend a hand, since it
doesn't seem to require all kinds of arcane knowledge about CLIM. :-)

It should be simple enough to implement some kind of format-string
system, where the order (and amount) of information in the pane can be
customized by changing the string, until something like GNU Emacs'
`mode-line-format'-variable and semantics can be developed.

What is your input on this?
-- 
Troels "Athas" Henriksen


From m.retzlaff at gmx.net  Fri Oct 21 16:56:41 2005
From: m.retzlaff at gmx.net (Max-Gerd Retzlaff)
Date: Fri, 21 Oct 2005 18:56:41 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <871x2eri6z.fsf@sigkill.dk>
References: <871x2eri6z.fsf@sigkill.dk>
Message-ID: <20051021165641.GA7601@mgr.home>

Hello

On Fri, Oct 21, 2005 at 05:41:24PM +0200, Troels Henriksen wrote:
> The display-function for the info-pane/modeline,
> climacs-gui::display-info, is very simple, and seems to be a bit
> hackish as well (as far as I can see, text for overwrite-mode,
> fill-mode and isearch-mode is hard-coded in the function). Is this
> simplicity by design, or is it merely a placeholder until something
> more flexible can be put in place? If the latter is the case, is
> anyone working on it? If not, I might be able to lend a hand, since it
> doesn't seem to require all kinds of arcane knowledge about CLIM. :-)
> 
> It should be simple enough to implement some kind of format-string
> system, where the order (and amount) of information in the pane can be
> customized by changing the string, until something like GNU Emacs'
> `mode-line-format'-variable and semantics can be developed.
> 
> What is your input on this?

Using FORMAT to just print (in contrast to PRESENT) some string seems
to be the wrong idea for a CLIM application. The contents of the info-pane
should be PRESENTed as the appropriate PRESENTATION TYPES. Consider the
following patch:

 -- zipp --

Index: gui.lisp
===================================================================
RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v
retrieving revision 1.191
diff -a -u -r1.191 gui.lisp
--- gui.lisp    13 Oct 2005 09:34:12 -0000      1.191
+++ gui.lisp    21 Oct 2005 16:43:12 -0000
@@ -143,6 +143,17 @@
         minibuffer)))
   (:top-level (esa-top-level)))
 
+(define-presentation-translator climacs-buffer-to-pathname-translator
+    (climacs-buffer pathname global-climacs-table
+       :gesture :select
+       :tester ((object)
+                (filepath object))
+       :tester-definitive t
+       :documentation ((object stream)
+                       (format stream "Select pathname ~a" (namestring (filepath object)))))
+    (object)
+  (filepath object))
+
 (defun current-window ()
   (car (windows *application-frame*)))
 
@@ -187,7 +198,8 @@
        (formatting-cell (pane :min-width '(25 :character))
          (princ "  " pane)
          (with-text-face (pane :bold)
-           (princ (name buffer) pane)))
+            (with-output-as-presentation (pane buffer 'climacs-buffer)
+              (princ (name buffer) pane))))
        (formatting-cell (pane :min-width '(5 :character))
          (princ (cond ((and (mark= size bot)
                             (mark= 0 top))
cvs server: Diffing Doc
cvs server: Diffing Persistent
cvs server: Diffing cl-automaton
cvs server: Diffing testing

 -- zapp --

The name of the buffer will now be presented as a presentation of type
CLIMACS-BUFFER, therefore it will be highlighted as suitable input whenever
a climacs command wants a climacs buffer as a parameter, e.g. if you fire
up Switch To Buffer (CLIMACS-GUI::COM-SWITCH-TO-BUFFER).

Not only this but as there is a PRESENTATION TRANSLATOR from the type
CLIMACS-BUFFER to PATHNAME this piece of screen space will also be
highlighted and selectable if you fire up Find File
(CLIMACS-GUI::COM-SWITCH-TO-BUFFER), but only if the buffer is
actually associated with a file on the disk (hence the :TESTER for the
PRESENTATION TRANSLATOR).

Bye, Max

-- 
Max-Gerd Retzlaff <m.retzlaff at gmx.net>

For your amusement:
How many surrealists does it take to screw in a lightbulb?

One to hold the giraffe and one to fill the bathtub with brightly colored
power tools.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051021/7ba28738/attachment.sig>

From strandh at labri.fr  Fri Oct 21 18:14:32 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 21 Oct 2005 20:14:32 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <871x2eri6z.fsf@sigkill.dk>
References: <871x2eri6z.fsf@sigkill.dk>
Message-ID: <17241.12296.727488.750153@serveur5.labri.fr>

Troels Henriksen writes:
 > The display-function for the info-pane/modeline,
 > climacs-gui::display-info, is very simple, and seems to be a bit
 > hackish as well (as far as I can see, text for overwrite-mode,
 > fill-mode and isearch-mode is hard-coded in the function). 

You are right. 

 > Is this
 > simplicity by design, or is it merely a placeholder until something
 > more flexible can be put in place? 

It is definitely not by design.  

 > If the latter is the case, is
 > anyone working on it? 

Probably not.  I seem to recall that Dave Murray had some ideas, but I
am not sure about that. 

 > If not, I might be able to lend a hand, since it
 > doesn't seem to require all kinds of arcane knowledge about CLIM. :-)

That would be great!  

 > It should be simple enough to implement some kind of format-string
 > system, where the order (and amount) of information in the pane can be
 > customized by changing the string, until something like GNU Emacs'
 > `mode-line-format'-variable and semantics can be developed.
 > 
 > What is your input on this?

Hard to say.  I thing Max-Gerd Retzlaff has the right idea that
PRESENT should be used.  But that excludes a general format string it
seems.  A special version of a very restricted version of format that
uses PRESENT is a possibility.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From athas at sigkill.dk  Fri Oct 21 18:22:22 2005
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 21 Oct 2005 20:22:22 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <20051021165641.GA7601@mgr.home> (Max-Gerd Retzlaff's message
	of "Fri, 21 Oct 2005 18:56:41 +0200")
References: <871x2eri6z.fsf@sigkill.dk> <20051021165641.GA7601@mgr.home>
Message-ID: <87wtk6pw69.fsf@sigkill.dk>

Max-Gerd Retzlaff <m.retzlaff at gmx.net> writes:

> Using FORMAT to just print (in contrast to PRESENT) some string seems
> to be the wrong idea for a CLIM application.

I agree, but that was not what I had in mind anyway. I merely objected
to the very static nature of DISPLAY-INFO, where it is not possible to
change the format of the information of the display pane, unless you
change the DISPLAY-INFO function itself. I don't think a format-string
(not as in "a string passed to FORMAT," but "a string containing
tokens that are replaced by the relevant data") based approach would
prevent the usage of PRESENT. If we imagine a format-string permitting
the same commands as GNU Emacs' `mode-line-format', "%b" would output
the name of the buffer - this name could be PRESENTed or anything else
appropiate to the situation.

-- 
Troels "Athas" Henriksen


From strandh at labri.fr  Fri Oct 21 18:27:02 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 21 Oct 2005 20:27:02 +0200
Subject: [climacs-devel] A few questions about Climacs
In-Reply-To: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>
References: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>
Message-ID: <17241.13046.803050.45925@serveur5.labri.fr>

Hello, 

Brad Beveridge writes:
 > Hi all, I have a few questions about Climacs, some that might be a
 > little heretical ;)
 > Firstly, from what I have read Climacs sounds like an interesting
 > project - well done!

Thank you!  

 > So now the heretical part :)
 > I like Vim (ssshh) rather than Emacs.  I imagine that it shouldn't be
 > too hard to add an input system that is Vim like - can I please get a
 > few tips on where to start looking to make these changes?

Hmm.  I know very little about Vim, but if it is something like VI you
would need new command tables to replace the ones currently used, or
at least the ones that contain the key bindings.  Then you would have
to create a bunch of set-key forms to bind the new key sequences in
the new tables. 

 > The reason that I would like to make a Vim like editor in Lisp is that
 > I think it would be nice for Vim lovers to have an editor that is
 > closely integrated with Lisp, preferably able to integrate with
 > Slime/Swank so that the final editor is a nice IDE.

Sure, I can see that. 

 > Is Slime integration an eventual goal of Climacs?

Some people would like that.  Especially for things like remote
editing.  Personally, I can see that it would be useful to use SWANK,
but less so to use SLIME.  The direct integration of Climacs into the
Lisp image means that communication with the Lisp system does not have
to be stream based.

 > Finally, how usable is Climacs as an editor right now?

It is quite usable.  It is a bit frustrating for Emacs experts who
expect everything to work the same, but for others it is fine.  It can
be a bit slow on huge Lisp files, but it is tolerable.  There are also
some quirks like the scrollbars not working, etc.  But there are
people who use it in their daily job now. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From brad.beveridge at gmail.com  Fri Oct 21 18:45:48 2005
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Fri, 21 Oct 2005 11:45:48 -0700
Subject: [climacs-devel] A few questions about Climacs
In-Reply-To: <17241.13046.803050.45925@serveur5.labri.fr>
References: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>
	<17241.13046.803050.45925@serveur5.labri.fr>
Message-ID: <de95dc6f0510211145q1009a04eua52852b8fa8a97e7@mail.gmail.com>

On 10/21/05, Robert Strandh <strandh at labri.fr> wrote:
> Hmm.  I know very little about Vim, but if it is something like VI you
> would need new command tables to replace the ones currently used, or
> at least the ones that contain the key bindings.  Then you would have
> to create a bunch of set-key forms to bind the new key sequences in
> the new tables.
Which file are the keybindings in?  I am new to Lisp, so although I've
scanned some of the code I didn't spot anything that looked like
keybindings to me.

>  > Is Slime integration an eventual goal of Climacs?
>
> Some people would like that.  Especially for things like remote
> editing.  Personally, I can see that it would be useful to use SWANK,
> but less so to use SLIME.  The direct integration of Climacs into the
> Lisp image means that communication with the Lisp system does not have
> to be stream based.
I'm showing my Slime/SWANK ignorance in that question - but you got the idea :)

Brad


From strandh at labri.fr  Fri Oct 21 18:56:55 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 21 Oct 2005 20:56:55 +0200
Subject: [climacs-devel] A few questions about Climacs
In-Reply-To: <de95dc6f0510211145q1009a04eua52852b8fa8a97e7@mail.gmail.com>
References: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>
	<17241.13046.803050.45925@serveur5.labri.fr>
	<de95dc6f0510211145q1009a04eua52852b8fa8a97e7@mail.gmail.com>
Message-ID: <17241.14839.497944.787246@serveur5.labri.fr>

Brad Beveridge writes:
 > On 10/21/05, Robert Strandh <strandh at labri.fr> wrote:
 > 
 > Which file are the keybindings in?  I am new to Lisp, so although I've
 > scanned some of the code I didn't spot anything that looked like
 > keybindings to me.

Do a grep set-key *.lisp and you will see. 

They are mostly in gui.lisp but the idea is probably to have them
either close to the corresponding command definition or to group them
into meaningful units based on a concept similar to an Emacs "mode".  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From amoroso at mclink.it  Fri Oct 21 19:50:43 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 21 Oct 2005 21:50:43 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <17241.12296.727488.750153@serveur5.labri.fr> (Robert Strandh's
	message of "Fri, 21 Oct 2005 20:14:32 +0200")
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
Message-ID: <87irvq644s.fsf@plato.moon.paoloamoroso.it>

Robert Strandh <strandh at labri.fr> writes:

> Hard to say.  I thing Max-Gerd Retzlaff has the right idea that
> PRESENT should be used.  But that excludes a general format string it
> seems.  A special version of a very restricted version of format that
> uses PRESENT is a possibility.  

What about WITH-OUTPUT-AS-PRESENTATION?


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From strandh at labri.fr  Fri Oct 21 19:56:32 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 21 Oct 2005 21:56:32 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <87irvq644s.fsf@plato.moon.paoloamoroso.it>
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
	<87irvq644s.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17241.18416.818470.339942@serveur5.labri.fr>

Paolo Amoroso writes:
 > Robert Strandh <strandh at labri.fr> writes:
 > 
 > > Hard to say.  I thing Max-Gerd Retzlaff has the right idea that
 > > PRESENT should be used.  But that excludes a general format string it
 > > seems.  A special version of a very restricted version of format that
 > > uses PRESENT is a possibility.  
 > 
 > What about WITH-OUTPUT-AS-PRESENTATION?

Sure, but, I think the point is that there are several pieces of
information in the info pane, and each one could have a different
presentation type.  Since format calls ordinary print functions, it
won't do. 
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From brad.beveridge at gmail.com  Fri Oct 21 18:59:46 2005
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Fri, 21 Oct 2005 11:59:46 -0700
Subject: [climacs-devel] A few questions about Climacs
In-Reply-To: <17241.14839.497944.787246@serveur5.labri.fr>
References: <de95dc6f0510202241g52264e63t5e5e25af637eab68@mail.gmail.com>
	<17241.13046.803050.45925@serveur5.labri.fr>
	<de95dc6f0510211145q1009a04eua52852b8fa8a97e7@mail.gmail.com>
	<17241.14839.497944.787246@serveur5.labri.fr>
Message-ID: <de95dc6f0510211159j68a69693m2ec23d30acc8cdbb@mail.gmail.com>

Fantastic - thanks.
I'll do some poking around before I ask anymore dumb questions :)

Brad

On 10/21/05, Robert Strandh <strandh at labri.fr> wrote:
> Brad Beveridge writes:
>  > On 10/21/05, Robert Strandh <strandh at labri.fr> wrote:
>  >
>  > Which file are the keybindings in?  I am new to Lisp, so although I've
>  > scanned some of the code I didn't spot anything that looked like
>  > keybindings to me.
>
> Do a grep set-key *.lisp and you will see.
>
> They are mostly in gui.lisp but the idea is probably to have them
> either close to the corresponding command definition or to group them
> into meaningful units based on a concept similar to an Emacs "mode".
>
> --
> Robert Strandh
>
> ---------------------------------------------------------------------
> Greenspun's Tenth Rule of Programming: any sufficiently complicated C
> or Fortran program contains an ad hoc informally-specified bug-ridden
> slow implementation of half of Common Lisp.
> ---------------------------------------------------------------------
>


From athas at sigkill.dk  Fri Oct 21 20:25:13 2005
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 21 Oct 2005 22:25:13 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <17241.18416.818470.339942@serveur5.labri.fr> (Robert Strandh's
	message of "Fri, 21 Oct 2005 21:56:32 +0200")
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
	<87irvq644s.fsf@plato.moon.paoloamoroso.it>
	<17241.18416.818470.339942@serveur5.labri.fr>
Message-ID: <87pspypqhi.fsf@sigkill.dk>

Robert Strandh <strandh at labri.fr> writes:

> Sure, but, I think the point is that there are several pieces of
> information in the info pane, and each one could have a different
> presentation type.  Since format calls ordinary print functions, it
> won't do. 

A subset of FORMAT could be implemented (it should be relatively easy,
as the more tricky looping and logic constructs are not really
needed), that PRESENTs, instead of printing. An
info-pane-format-string of "~B" could then PRESENT the name of the
current buffer, and so forth.

-- 
Troels "Athas" Henriksen


From strandh at labri.fr  Fri Oct 21 21:15:08 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 21 Oct 2005 23:15:08 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <87pspypqhi.fsf@sigkill.dk>
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
	<87irvq644s.fsf@plato.moon.paoloamoroso.it>
	<17241.18416.818470.339942@serveur5.labri.fr>
	<87pspypqhi.fsf@sigkill.dk>
Message-ID: <17241.23132.307696.670767@serveur5.labri.fr>

Troels Henriksen writes:
 > A subset of FORMAT could be implemented (it should be relatively easy,
 > as the more tricky looping and logic constructs are not really
 > needed), that PRESENTs, instead of printing. An
 > info-pane-format-string of "~B" could then PRESENT the name of the
 > current buffer, and so forth.

Yep
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From athas at sigkill.dk  Fri Oct 21 22:59:53 2005
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 22 Oct 2005 00:59:53 +0200
Subject: [climacs-devel] Question about the info-pane display function
In-Reply-To: <17241.23132.307696.670767@serveur5.labri.fr> (Robert Strandh's
	message of "Fri, 21 Oct 2005 23:15:08 +0200")
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
	<87irvq644s.fsf@plato.moon.paoloamoroso.it>
	<17241.18416.818470.339942@serveur5.labri.fr>
	<87pspypqhi.fsf@sigkill.dk>
	<17241.23132.307696.670767@serveur5.labri.fr>
Message-ID: <87ll0mpjbq.fsf@sigkill.dk>

I have refactored the structure of the info-pane into a separate
variable, and changed `display-info' to use it. Not a big change, but
it's a beginning, I think. Please excuse the quality of the code, I
only have 6 months of experience with Common Lisp and CLIM. A patch is
attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gui.lisp.patch
Type: text/x-patch
Size: 4291 bytes
Desc: Patch to gui.lisp
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051022/94a63e19/attachment.bin>
-------------- next part --------------

-- 
Troels "Athas" Henriksen

From splittist at yahoo.com  Mon Oct 24 08:48:06 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Mon, 24 Oct 2005 08:48:06 +0000 (UTC)
Subject: [climacs-devel] Re: Question about the info-pane display function
References: <871x2eri6z.fsf@sigkill.dk>
	<17241.12296.727488.750153@serveur5.labri.fr>
	<87irvq644s.fsf@plato.moon.paoloamoroso.it>
	<17241.18416.818470.339942@serveur5.labri.fr>
	<87pspypqhi.fsf@sigkill.dk>
	<17241.23132.307696.670767@serveur5.labri.fr>
	<87ll0mpjbq.fsf@sigkill.dk>
Message-ID: <loom.20051024T103226-827@post.gmane.org>

Troels Henriksen <athas <at> sigkill.dk> writes:

> 
> I have refactored the structure of the info-pane into a separate
> variable, and changed `display-info' to use it. Not a big change, but
> it's a beginning, I think.

I agree that something like this needs doing. I had held off doing it because 
I was waiting for a more general user-variables facility. Since that doesn't 
seem to be magically appearing, there is no reason not to work with this now.

In my opinion, a format string is the wrong way to go. I would prefer to see a 
set of methods that could be variously composed (:progn, anyone?), :around-
ed, :after-ed etc. This would have some chance of allowing all the various 
parties that want to influence the printing of the info-pane (user, syntax, 
view, 'mode' etc.) to do so without stepping on each others' toes. It also 
seems to play to CL's strengths, and allow use of the presentation facility in 
more creative ways.

I don't actually have any concrete counter-proposal beyond this hand-waving 
stuff, and I'm the last person to discourage anyone to work on Climacs (!), 
but I thought I'd butt in with these thoughts.

Slightly more concretely, what modifications to the info-pane display do 
people want to make?

JQS




From csr21 at cam.ac.uk  Tue Oct 25 15:16:26 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 25 Oct 2005 16:16:26 +0100
Subject: [climacs-devel] climacs scribbling permission
Message-ID: <sqpsptbp9x.fsf@cam.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

As some may already know, I have colleagues who do interesting stuff;
David has been working with me on the tablature editor, which uses
Climacs as its intelligent text editor; Marcus has implemented a
prolog->paiprolog translator.  Would it be OK to give them CVS commit
privileges to climacs, so that I don't end up as the bottleneck?

Relatedly, would it be reasonable to rearrange the directory layout
for climacs?  I enviseage putting syntaxes into subdirectories, so
that instead of the current flat layout, we'd have Prolog, Lisp,
Slidemacs subdirectories.

Cheers,

Christophe

(PS: would kill for per-pane / per-syntax keybindings :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDXkxGhMXieFLWjfIRAt3bAJ0W+ad7RBMDa4KRbzdCD56RxkWKZACgxQIp
n6lEU3/A/vS3nzzzcrw7/NE=
=v3mZ
-----END PGP SIGNATURE-----


From strandh at labri.fr  Tue Oct 25 20:23:59 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 25 Oct 2005 22:23:59 +0200
Subject: [climacs-devel] climacs scribbling permission
In-Reply-To: <sqpsptbp9x.fsf@cam.ac.uk>
References: <sqpsptbp9x.fsf@cam.ac.uk>
Message-ID: <17246.37983.28119.910290@serveur5.labri.fr>

Christophe Rhodes writes:

 > Would it be OK to give them CVS commit
 > privileges to climacs, so that I don't end up as the bottleneck?

Fine with me. 

 > Relatedly, would it be reasonable to rearrange the directory layout
 > for climacs?  I enviseage putting syntaxes into subdirectories, so
 > that instead of the current flat layout, we'd have Prolog, Lisp,
 > Slidemacs subdirectories.

Sure, go ahead.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Wed Oct 26 04:53:35 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Wed, 26 Oct 2005 05:53:35 +0100
Subject: [climacs-devel] Re: climacs scribbling permission
In-Reply-To: <sqpsptbp9x.fsf@cam.ac.uk>
References: <sqpsptbp9x.fsf@cam.ac.uk>
Message-ID: <435F0BCF.30103@yahoo.com>

Christophe Rhodes wrote:

> Would it be OK to give them CVS commit
> privileges to climacs, so that I don't end up as the bottleneck?

FWIW, I think David and Marcus would be fine additions to the team.

> Relatedly, would it be reasonable to rearrange the directory layout
> for climacs? 

Knock yourselves out, although I'm not sure what it gains. Note the 
capitalization of directory names issues some OSes have. Perhaps an 
'experimental' directory might be in order, too. Could I also ask that a 
brief explanation of the reasoning behind any structure is added to an 
appropriate file (the README?) for future extensions.

> (PS: would kill for per-pane / per-syntax keybindings :-)

No need to go that far! Since your group is the first real multi-syntax 
group, you should feel free to go ahead and implement whatever works for 
you. :after (and potentially :before) methods on (setf syntax) and (setf 
buffer) that call something appropriate specialised on syntax should do 
for now. And then we might learn whether swapping command-tables is as 
easy as we hope!

JQS

PS: practically speaking, I'm not going to have a lot of time for 
finishing the buffer->pane paradigm shift in the next few weeks, I'm afraid.


From csr21 at cam.ac.uk  Wed Oct 26 11:21:38 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 26 Oct 2005 12:21:38 +0100
Subject: [climacs-devel] Re: climacs scribbling permission
In-Reply-To: <435F0BCF.30103@yahoo.com> (John Q. Splittist's message of "Wed, 
	26 Oct 2005 05:53:35 +0100")
References: <sqpsptbp9x.fsf@cam.ac.uk> <435F0BCF.30103@yahoo.com>
Message-ID: <sqll0go75p.fsf@cam.ac.uk>

John Q Splittist <splittist at yahoo.com> writes:

> Christophe Rhodes wrote:
>
>> (PS: would kill for per-pane / per-syntax keybindings :-)
>
> No need to go that far! 

Well, you are on the list for termination anyway:
<http://www.sethf.com/essays/major/killlawyers.php> :-)

> Since your group is the first real multi-syntax 
> group, you should feel free to go ahead and implement whatever works for 
> you. :after (and potentially :before) methods on (setf syntax) and (setf 
> buffer) that call something appropriate specialised on syntax should do 
> for now. And then we might learn whether swapping command-tables is as 
> easy as we hope!

Mm.  My initial experiments indicate that it's not quite as easy as we
hope; there's some detail in the other esa-using project's mail
archives:
<http://common-lisp.net/pipermail/gsharp-devel/2005-September/000071.html>.

It's possible that I understand a little bit more about how this is
meant to work at the moment, but before I start hacking maybe I should
confirm that understanding... the command-table slot of the first
window of the application frame should contain the command-table which
we want to be active.  This implies that running commands, _including_
running commands from keyboard gestures (currently read and processed
with PROCESS-GESTURES) need (a) to be able to change that command
table and (b) to notice that it's been changed.  Also, if the 'active'
command table is changed, the input context needs to be re-established
for mouse gestures, because new commands may make new presentations /
translators applicable.

Is this right?  If so, it will involve a certain amount of
restructuring of ESA-TOP-LEVEL, but otherwise shouldn't be terribly
arduous.

Cheers,

Christophe


From csr21 at cam.ac.uk  Wed Oct 26 12:23:51 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 26 Oct 2005 13:23:51 +0100
Subject: [climacs-devel] Re: climacs scribbling permission
In-Reply-To: <sqll0go75p.fsf@cam.ac.uk> (Christophe Rhodes's message of "Wed, 
	26 Oct 2005 12:21:38 +0100")
References: <sqpsptbp9x.fsf@cam.ac.uk> <435F0BCF.30103@yahoo.com>
	<sqll0go75p.fsf@cam.ac.uk>
Message-ID: <sqhdb4o4a0.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Mm.  My initial experiments indicate that it's not quite as easy as we
> hope; there's some detail in the other esa-using project's mail
> archives:
> <http://common-lisp.net/pipermail/gsharp-devel/2005-September/000071.html>.
>
> It's possible that I understand a little bit more about how this is
> meant to work at the moment, but before I start hacking maybe I should
> confirm that understanding... the command-table slot of the first
> window of the application frame should contain the command-table which
> we want to be active.  This implies that running commands, _including_
> running commands from keyboard gestures (currently read and processed
> with PROCESS-GESTURES) need (a) to be able to change that command
> table and (b) to notice that it's been changed.  Also, if the 'active'
> command table is changed, the input context needs to be re-established
> for mouse gestures, because new commands may make new presentations /
> translators applicable.
>
> Is this right?  If so, it will involve a certain amount of
> restructuring of ESA-TOP-LEVEL, but otherwise shouldn't be terribly
> arduous.

If I'm right, then the attached is what we want, I think.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: esa.diff
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051026/733f30fd/attachment.ksh>
-------------- next part --------------

I've only lightly tested this, and only in gsharp.

Cheers,

Christophe

From csr21 at cam.ac.uk  Sun Oct 30 15:39:07 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sun, 30 Oct 2005 15:39:07 +0000
Subject: [climacs-devel] Re: climacs scribbling permission
In-Reply-To: <435F0BCF.30103@yahoo.com> (John Q. Splittist's message of "Wed, 
	26 Oct 2005 05:53:35 +0100")
References: <sqpsptbp9x.fsf@cam.ac.uk> <435F0BCF.30103@yahoo.com>
Message-ID: <sqr7a3ggkk.fsf@cam.ac.uk>

John Q Splittist <splittist at yahoo.com> writes:

> Christophe Rhodes wrote:
>> (PS: would kill for per-pane / per-syntax keybindings :-)
>
> No need to go that far! Since your group is the first real multi-syntax 
> group, you should feel free to go ahead and implement whatever works for 
> you. :after (and potentially :before) methods on (setf syntax) and (setf 
> buffer) that call something appropriate specialised on syntax should do 
> for now. And then we might learn whether swapping command-tables is as 
> easy as we hope!
>
> JQS
>
> PS: practically speaking, I'm not going to have a lot of time for 
> finishing the buffer->pane paradigm shift in the next few weeks, I'm afraid.

OK.  Attached is a completely minimal patch that I think restores
workingness to the slidemacs GUI mode.  It is unlikely to compile from
scratch -- I wrote it in exploratory mode -- and additionally it's
clearly not scalable.  It also ties syntaxes and buffers and panes
together in ways that I think are not great.  On the other hand,
absent a great reorganization I'm not sure what to suggest for a
cleaned-up version of this patch, other than perhaps a protocol
function
  NOTE-PANE-BUFFER-SYNTAX-CHANGED pane buffer syntax
on which the user (syntax designer) can hook a method with their own
syntax.  The default method would set PANE's command-table to
GLOBAL-CLIMACS-TABLE; slidemacs-gui's would look like
  (defmethod n-p-b-s-c (pane buffer (syntax slidemacs-gui-syntax))
    (setf (command-table pane) 'slidemacs-table))
and this would be called from :around methods, probably, on (setf
syntax) and (setf buffer).  I think this would offer enough
flexibility for we tabcoders and prologers to play with UI stuff.

How does this sound?  (Again, please ignore the ugliness of the patch
below; I attach it mostly in case anyone wants something to read...)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: slidemacs.diff
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051030/b95b7e24/attachment.ksh>
-------------- next part --------------

Cheers,

Christophe

From csr21 at cam.ac.uk  Mon Oct 31 21:53:43 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 31 Oct 2005 21:53:43 +0000
Subject: [climacs-devel] Re: climacs scribbling permission
In-Reply-To: <sqr7a3ggkk.fsf@cam.ac.uk> (Christophe Rhodes's message of "Sun, 
	30 Oct 2005 15:39:07 +0000")
References: <sqpsptbp9x.fsf@cam.ac.uk> <435F0BCF.30103@yahoo.com>
	<sqr7a3ggkk.fsf@cam.ac.uk>
Message-ID: <sqfyqhqro8.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

>   NOTE-PANE-BUFFER-SYNTAX-CHANGED pane buffer syntax
> on which the user (syntax designer) can hook a method with their own
> syntax.

I merged something along those lines, along with the necessary changes
in slidemacs-gui.  Things appear to work, but please shout if things
seem wrong.

(I did notice that the modeline / info pane was behaving oddly today;
I don't know if that's my fault)

Cheers,

Christophe