From splittist at yahoo.com Wed Aug 3 15:50:42 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 03 Aug 2005 16:50:42 +0100 Subject: [climacs-devel] Key Binding Proposals Message-ID: <42F0E7D2.7020902@yahoo.com> I've put up a table of existing climacs commands and bindings, together with a comparison to [Gnu] Emacs and [TI Explorer] Zmacs. See it here: http://perso.wanadoo.fr/a.d.m/climacs-commands.html This exercise leads me to propose the following: 1. Remove 'Backward Expression' from M-b (keep M-C-b) 2. Remove 'Forward Expression' from M-e (keep M-C-f) 3. Remove 'Load File' from C-x l (lowercase-region in Gnu Emacs) 4. Move 'Beginning Of Paragraph' from M-C-a to M-{ and rename to 'Backward Paragraph' 5. Move 'End Of Paragraph' from M-C-e to M-} and rename to 'Forward Paragraph' 6. Rename 'Cut Out' (C-w) to 'Kill Region' 7. Rename 'Copy Out' (M-w) to 'Copy Region' Objections, further suggestions, commentary etc. welcome! JQS From splittist at yahoo.com Wed Aug 3 18:47:05 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 03 Aug 2005 19:47:05 +0100 Subject: [climacs-devel] Re: Key Binding Proposals In-Reply-To: <42F0E7D2.7020902@yahoo.com> References: <42F0E7D2.7020902@yahoo.com> Message-ID: <42F11129.6010600@yahoo.com> John Q Splittist wrote: > 1. Remove 'Backward Expression' from M-b (keep M-C-b) As has been pointed out, this should be M-a. 1.1. Move backward sentence functionality to 'Backward Sentence' on M-a. > 2. Remove 'Forward Expression' from M-e (keep M-C-f) 2.1 Move forward sentence functionality to 'Forward Sentence' on M-e. (It may be useful to do both in a single syntax e.g. editing comments in Kont...) JQS From strandh at labri.fr Wed Aug 3 22:53:29 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 4 Aug 2005 00:53:29 +0200 Subject: [climacs-devel] Key Binding Proposals In-Reply-To: <42F0E7D2.7020902@yahoo.com> References: <42F0E7D2.7020902@yahoo.com> Message-ID: <17137.19177.959420.584336@serveur5.labri.fr> John Q Splittist writes: > I've put up a table of existing climacs commands and bindings, together > with a comparison to [Gnu] Emacs and [TI Explorer] Zmacs. See it here: > http://perso.wanadoo.fr/a.d.m/climacs-commands.html impressive! I did not realize you were in .fr. > This exercise leads me to propose the following: > > 1. Remove 'Backward Expression' from M-b (keep M-C-b) OK with me. > 2. Remove 'Forward Expression' from M-e (keep M-C-f) OK > 3. Remove 'Load File' from C-x l (lowercase-region in Gnu Emacs) OK. Perhaps add it to C-c C-l, which is load-file in Emacs? > 4. Move 'Beginning Of Paragraph' from M-C-a to M-{ and rename to > 'Backward Paragraph' OK, provided it is doing the same thing. Like is there not a difference as to what happens when already at the beginning of a paragraph? > 5. Move 'End Of Paragraph' from M-C-e to M-} and rename to 'Forward > Paragraph' Idem. > 6. Rename 'Cut Out' (C-w) to 'Kill Region' Sure. > 7. Rename 'Copy Out' (M-w) to 'Copy Region' Sure. -- 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 strandh at labri.fr Wed Aug 3 22:54:54 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 4 Aug 2005 00:54:54 +0200 Subject: [climacs-devel] Re: Key Binding Proposals In-Reply-To: <42F11129.6010600@yahoo.com> References: <42F0E7D2.7020902@yahoo.com> <42F11129.6010600@yahoo.com> Message-ID: <17137.19262.725085.653332@serveur5.labri.fr> John Q Splittist writes: > John Q Splittist wrote: > > 1. Remove 'Backward Expression' from M-b (keep M-C-b) > > As has been pointed out, this should be M-a. > > 1.1. Move backward sentence functionality to 'Backward Sentence' on M-a. > > > 2. Remove 'Forward Expression' from M-e (keep M-C-f) > > 2.1 Move forward sentence functionality to 'Forward Sentence' on M-e. > > (It may be useful to do both in a single syntax e.g. editing comments in > Kont...) sounds good -- 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 hober0 at gmail.com Thu Aug 4 00:23:26 2005 From: hober0 at gmail.com (Edward O'Connor) Date: Wed, 03 Aug 2005 17:23:26 -0700 Subject: [climacs-devel] Re: Key Binding Proposals References: <42F0E7D2.7020902@yahoo.com> <17137.19177.959420.584336@serveur5.labri.fr> Message-ID: >> 3. Remove 'Load File' from C-x l (lowercase-region in Gnu Emacs) > > OK. Perhaps add it to C-c C-l, which is load-file in Emacs? Hmm. My Emacs says C-c C-l is undefined. Perhaps this is a binding in your .emacs file? Ted -- Edward O'Connor hober0 at gmail.com Ense petit placidam sub libertate quietem. From strandh at labri.fr Thu Aug 4 01:17:20 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 4 Aug 2005 03:17:20 +0200 Subject: [climacs-devel] Re: Key Binding Proposals In-Reply-To: References: <42F0E7D2.7020902@yahoo.com> <17137.19177.959420.584336@serveur5.labri.fr> Message-ID: <17137.27808.287798.653660@serveur5.labri.fr> Edward O'Connor writes: > >> 3. Remove 'Load File' from C-x l (lowercase-region in Gnu Emacs) > > > > OK. Perhaps add it to C-c C-l, which is load-file in Emacs? > > Hmm. My Emacs says C-c C-l is undefined. Perhaps this is a binding in > your .emacs file? No, but it is probably SLIME specific. -- 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 Thu Aug 4 09:05:47 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 04 Aug 2005 10:05:47 +0100 Subject: [climacs-devel] Re: Key Binding Proposals In-Reply-To: <17137.19177.959420.584336@serveur5.labri.fr> References: <42F0E7D2.7020902@yahoo.com> <17137.19177.959420.584336@serveur5.labri.fr> Message-ID: <42F1DA6B.3030007@yahoo.com> Robert Strandh wrote: > John Q Splittist writes: > > http://perso.wanadoo.fr/a.d.m/climacs-commands.html > > I did not realize you were in .fr. I _was_ in .fr; now I'm in .uk, but I get back to .fr regularly, so I've kept my Wanadoo connection. (Much cheaper than Rip-Off Britain(R), BTW...) See patch for changes: > > 1. Remove 'Backward Expression' from M-a (keep M-C-b) Done. Backward Sentence now on M-a. > > 2. Remove 'Forward Expression' from M-e (keep M-C-f) Done. Forward Sentence now on M-e. > > 3. Remove 'Load File' from C-x l (lowercase-region in Gnu Emacs) Done. > OK. Perhaps add it to C-c C-l, which is load-file in Emacs? In SLIME... The next exercise is to do a SLIME/Zmacs/climacs comparison. > > 4. Move 'Beginning Of Paragraph' from M-C-a to M-{ and rename to > > 'Backward Paragraph' Done. > OK, provided it is doing the same thing. Like is there not a > difference as to what happens when already at the beginning of a > paragraph? Repeated invocations move the point ie. two Beginning Of Paragraphs move the point to the start of the paragraph before the one in which the point was originally (if you see what I mean). So the 'Backward/Forward' names work. > > 5. Move 'End Of Paragraph' from M-C-e to M-} and rename to 'Forward > > Paragraph' Done. > > 6. Rename 'Cut Out' (C-w) to 'Kill Region' Done. > > 7. Rename 'Copy Out' (M-w) to 'Copy Region' Done. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keys.patch URL: From splittist at yahoo.com Thu Aug 4 20:07:28 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 04 Aug 2005 21:07:28 +0100 Subject: [climacs-devel] Keybindings - WIP Message-ID: <42F27580.2040700@yahoo.com> Just to avoid duplication of work, I've done, or changed names or keybindings for, and will soon make available, the following: * 'Kill Word' (M-d) and 'Backward Kill Word' (M-Backspace) (replacements for 'Delete Word' and 'Backward Delete Word' that save the words to the kill-ring) * 'Mark Definition' (M-C-h) * 'Not Modified' (M-~) * 'Backward Sentence' (M-a), 'Forward Sentence' (M-e) * 'Backward Paragraph' (M-{), 'Forward Paragraph' (M-}) * 'Backward Page' (C-x [), 'Forward Page' (C-x ]) * 'Count Lines Page' (C-x l) * 'Set Fill Column' (C-s f) * 'Beginning of Definition' (M-C-a), 'End of Definition' (M-C-e) * Changed 'Goto Line' to be 1-based rather than 0-based Comments welcome, although you'll probably want to see the code first (: JQS From strandh at labri.fr Fri Aug 5 03:01:07 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 5 Aug 2005 05:01:07 +0200 Subject: [climacs-devel] Keybindings - WIP In-Reply-To: <42F27580.2040700@yahoo.com> References: <42F27580.2040700@yahoo.com> Message-ID: <17138.54899.63716.43901@serveur5.labri.fr> John Q Splittist writes: > Just to avoid duplication of work, I've done, or changed names or > keybindings for, and will soon make available, the following: > > * 'Kill Word' (M-d) and 'Backward Kill Word' (M-Backspace) (replacements > for 'Delete Word' and 'Backward Delete Word' that save the words to the > kill-ring) > > * 'Mark Definition' (M-C-h) > > * 'Not Modified' (M-~) > > * 'Backward Sentence' (M-a), 'Forward Sentence' (M-e) > > * 'Backward Paragraph' (M-{), 'Forward Paragraph' (M-}) > > * 'Backward Page' (C-x [), 'Forward Page' (C-x ]) > > * 'Count Lines Page' (C-x l) > > * 'Set Fill Column' (C-s f) > > * 'Beginning of Definition' (M-C-a), 'End of Definition' (M-C-e) > > * Changed 'Goto Line' to be 1-based rather than 0-based > > Comments welcome, although you'll probably want to see the code first (: Looks good. No need to show the code first. We'll just yell at you afterwards if the code is bad. :-) -- 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 Tue Aug 9 07:48:33 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 09 Aug 2005 08:48:33 +0100 Subject: [climacs-devel] Re: spaces in directory or filenames under MacOS In-Reply-To: <85de97ed0c5434b50fc1f9d278563a1e@soi.city.ac.uk> References: <85de97ed0c5434b50fc1f9d278563a1e@soi.city.ac.uk> Message-ID: <42F85FD1.906@yahoo.com> David Lewis wrote: > I've run into a problem running climacs on a mac: the space character > in directory or file names seems to break the pathname input Does anyone object to removing #\Space as a partial-completer for accepting completable-pathnames? JQS From splittist at yahoo.com Tue Aug 9 07:57:47 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 09 Aug 2005 08:57:47 +0100 Subject: [climacs-devel] Commands and documentation Message-ID: <42F861FB.5000806@yahoo.com> Folks, In adding a bunch of little commands it strikes me that, in the presence of prefix arguments, it is not always obvious how a particular command might have been implemented. To take an example, C-k seems to act subtly differently under various editors. We all know documentation will have to be added eventually, but I'm thinking now, when we're actually writing the commands, would be the time to at least add a few docstrings that might form the basis of the 'self-documenting' part of the emacsness of climacs. There is no need to actually do anything with the docstrings at the moment, but do people have any ideas as to a natural and flexible way to set things out? The DEFINE-NAMED-COMMAND macro seems as good a place as any, but while we're fiddling with that, should we also be thinking about a natural way to express a desire to add a command to a particular command table? JQS PS. I know the stuff I've added recently needs refactoring, not least to make the functionality in various commands available to other function/command writers. From strandh at labri.fr Tue Aug 9 19:58:16 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 21:58:16 +0200 Subject: [climacs-devel] Re: spaces in directory or filenames under MacOS In-Reply-To: <42F85FD1.906@yahoo.com> References: <85de97ed0c5434b50fc1f9d278563a1e@soi.city.ac.uk> <42F85FD1.906@yahoo.com> Message-ID: <17145.2776.57488.46172@serveur5.labri.fr> John Q Splittist writes: > David Lewis wrote: > > I've run into a problem running climacs on a mac: the space character > > in directory or file names seems to break the pathname input > > Does anyone object to removing #\Space as a partial-completer for > accepting completable-pathnames? It's OK with me. -- 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 strandh at labri.fr Tue Aug 9 20:03:18 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 22:03:18 +0200 Subject: [climacs-devel] Commands and documentation In-Reply-To: <42F861FB.5000806@yahoo.com> References: <42F861FB.5000806@yahoo.com> Message-ID: <17145.3078.561347.691883@serveur5.labri.fr> Hello, John Q Splittist writes: > > We all know documentation will have to be added eventually, but I'm > thinking now, when we're actually writing the commands, would be the > time to at least add a few docstrings that might form the basis of the > 'self-documenting' part of the emacsness of climacs. Seems like a good idea. > There is no need to actually do anything with the docstrings at the > moment, but do people have any ideas as to a natural and flexible way to > set things out? The DEFINE-NAMED-COMMAND macro seems as good a place as > any, but while we're fiddling with that, should we also be thinking > about a natural way to express a desire to add a command to a particular > command table? Yes, be careful with DEFINE-NAMED-COMMAND. Together with Dan Barlow, I have started thinking about associating commands and their key bindings with say a specific syntax. Most likely, DEFINE-NAMED-COMMAND would then have to change so that the specific command table will be mentioned. Though I guess putting docstrings in there would do no harm even if the definition of macro changes. -- 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 asf at boinkor.net Sun Aug 14 13:37:04 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 14 Aug 2005 15:37:04 +0200 Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/gui.lisp In-Reply-To: <20050814121121.0BDB288032@common-lisp.net> References: <20050814121121.0BDB288032@common-lisp.net> Message-ID: <87oe80vdvj.wl%asf@boinkor.net> Today, Dave Murray wrote: > Update of /project/climacs/cvsroot/climacs > In directory common-lisp.net:/tmp/cvs-serv24094 > > Modified Files: > gui.lisp > Log Message: > Added com-backward-kill-expression (M-C-Backspace), Eek. Control-Alt-Backspace is a default key combination in XFree86 and Xorg used to kill an X server. Could this be bound to another gesture? -- Andreas Fuchs, , asf at jabber.at, antifuchs From splittist at yahoo.com Sun Aug 14 15:39:03 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 14 Aug 2005 16:39:03 +0100 Subject: [climacs-devel] Re: M-C-Backspace and other commands In-Reply-To: <87oe80vdvj.wl%asf@boinkor.net> References: <20050814121121.0BDB288032@common-lisp.net> <87oe80vdvj.wl%asf@boinkor.net> Message-ID: <42FF6597.8090203@yahoo.com> Andreas Fuchs wrote: >>Added com-backward-kill-expression (M-C-Backspace), > > Eek. Control-Alt-Backspace is a default key combination in XFree86 and > Xorg used to kill an X server. Could this be bound to another gesture? Certainly. Hopefully this will act as a spur to those working on the new keybinding/command-table infrastructure. (Not that I'm suggesting they need a spur, or that they are in any way remiss in what they have done and are doing.) This is probably as good a place to mention that the whole expression-navigation thing is still slightly funky, having trouble at the moment (2005-08-14 16:38 BST) with handling things when the cursor is in the middle of a non-list compound forms (such as #'function, #P "Pathname", 'quote etc. Just so you know I know, and I'm working on it (: . Suggestions for other useful list/expression-hacking commands gratefully recieved, even if not immediately implemented... JQS From hober0 at gmail.com Sun Aug 14 18:25:19 2005 From: hober0 at gmail.com (Edward O'Connor) Date: Sun, 14 Aug 2005 11:25:19 -0700 Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/gui.lisp References: <20050814121121.0BDB288032@common-lisp.net> <87oe80vdvj.wl%asf@boinkor.net> Message-ID: >> Added com-backward-kill-expression (M-C-Backspace), > > Eek. Control-Alt-Backspace is a default key combination in XFree86 and > Xorg used to kill an X server. Could this be bound to another gesture? This binding is simply being consistent with the Emacs binding of `backward-kill-sexp'. And yes, it being the same as XFree86's kill switch has been the source of much pain. Ted -- Edward O'Connor hober0 at gmail.com Ense petit placidam sub libertate quietem. From csr21 at cam.ac.uk Tue Aug 16 11:39:28 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 16 Aug 2005 12:39:28 +0100 Subject: [climacs-devel] lisp syntax bug Message-ID: Hi, Start climacs, type "((defun foo)" (without the quotes), put point on the second open paren, and press backspace. The first paren is correctly deleted without trouble. Now do the same in a fresh buffer in Lisp syntax. I observe that the display is wrong: all that happens is that the cursor moves back one position, but the paren is not displayed as deleted. (The buffer clearly thinks of it as deleted, though: pressing delete at this point has the visual effect of deleting both open parens). Cheers, Christophe From earljwagner at alum.mit.edu Tue Aug 16 16:13:22 2005 From: earljwagner at alum.mit.edu (Earl J. Wagner) Date: Tue, 16 Aug 2005 11:13:22 -0500 Subject: [climacs-devel] lisp-syntax and parse tables Message-ID: Hi all, I've been looking at how to automatically generate the lisp-syntax parser from BNF descriptions like S -> form*, etc. To do this, I'm integrating a modified version of Mark Johnson's LALR parse table generator linked to from here: http://www.cog.brown.edu/~mj/Software.htm I have a few questions however 1) What's the rationale behind representing parse states as CLOS objects, as opposed to just numbers? On the one hand this is a little easier to understand when parsing breaks, but my intuition is that it introduces a lot of overhead. 2) Is it necessary to interleave lexing and parsing? It's conventional to have a lexing stage then a parsing stage, but because of C's macros and other reasons for C++, that doesn't work for those languages. Correct me if I'm wrong, but Lisp seems uniform enough that even if you introduce macros or additional syntax, the lexer should be able to function independently of the parser. My inclination is to split current-state into a lexer state and parse state. Lexer state will be identified symbolically as is done now and the parse state will be represented by state-ids. -Earl From ewagner at cs.northwestern.edu Tue Aug 16 16:07:48 2005 From: ewagner at cs.northwestern.edu (Earl J. Wagner) Date: Tue, 16 Aug 2005 11:07:48 -0500 Subject: [climacs-devel] lisp-syntax and parse tables Message-ID: Hi all, I've been looking at how to automatically generate the lisp-syntax parser from BNF descriptions like S -> form*, etc. To do this, I'm integrating a modified version of Mark Johnson's LALR parse table generator linked to from here: http://www.cog.brown.edu/~mj/Software.htm I have a few questions however 1) What's the rationale behind representing parse states as CLOS objects, as opposed to just numbers? On the one hand this is a little easier to understand when parsing breaks, but my intuition is that it introduces a lot of overhead. 2) Is it necessary to interleave lexing and parsing? It's conventional to have a lexing stage then a parsing stage, but because of C's macros and other reasons for C++, that doesn't work for those languages. Correct me if I'm wrong, but Lisp seems uniform enough that even if you introduce macros or additional syntax, the lexer should be able to function independently of the parser. My inclination is to split current-state into a lexer state and parse state. Lexer state will be identified symbolically as is done now and the parse state will be represented by state-ids. -Earl From strandh at labri.fr Wed Aug 17 00:18:34 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 17 Aug 2005 02:18:34 +0200 Subject: [climacs-devel] lisp-syntax and parse tables In-Reply-To: References: Message-ID: <17154.33370.441261.937730@serveur5.labri.fr> Hello, Earl J. Wagner writes: > > I have a few questions however > 1) What's the rationale behind representing parse states as CLOS > objects, as opposed to just numbers? > On the one hand this is a little easier to understand when parsing > breaks, but my intuition is that it introduces a lot of overhead. My thinking was that one might want to put :before and :after methods on the parser actions. Also, the traditional table compressions algorithms seem to boil down to actually defining the equivalent of my CLOS classes. Finally, lines in the parse tables are often related by subset, which suggest that they are related much like a class hierarchy. On the other hand, one can probably define quite a few syntax modules with only numbers. > 2) Is it necessary to interleave lexing and parsing? > It's conventional to have a lexing stage then a parsing stage, but > because of C's macros and other reasons for C++, that doesn't work > for those languages. Correct me if I'm wrong, but Lisp seems uniform > enough that even if you introduce macros or additional syntax, the > lexer should be able to function independently of the parser. Here, my thinking was to introduce the possibility of nesting different languages, that might require different lexers. A simple example would be to grammar check comments and strings in a language such as Common Lisp. A more interesting one would be SQL embedded in C or PHP in HTML. This is another reason I wanted the parser states to be CLOS classes so that one could use a mixin class to tell the lexer how to behave. > My inclination is to split current-state into a lexer state and parse > state. Lexer state will be identified symbolically as is done now and > the parse state will be represented by state-ids. I am not sure what the consequences would be. Perhaps you should test it on something non-critical such as HTML syntax and see what happens. If it works out, it could then be introduced in something like Lisp syntax which is important enough that I would like to avoid breaking it. Take care, -- 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 Aug 17 15:13:59 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 17 Aug 2005 16:13:59 +0100 Subject: [climacs-devel] Marks, Buffers and Panes Message-ID: <43035437.3040101@yahoo.com> I am rewriting some of the commands to be available more generally as functions, for the building up of further functions and commands. My idea was that, instead of taking the GNU Emacs approach of having every function operating on the current buffer, only to wrap it later in something that dynamically changes what the 'current buffer' is, functions should be passed a mark, and operate on the relevant buffer etc from information gained from the mark. In general this works very well - com-foo calls foo with (point (current-window)), com-bar (numarg) calls bar with point and count, and so on. Where it doesn't work is if foo or bar need to know what the current syntax for a buffer is, because, for example, they call end-of-definition, which specializes on syntax. The problem is that from a supplied mark, the function foo can only access the implementation buffer, not the enclosing delegating buffer, which is where the syntax is. One answer would be to put a slot on delagatee buffers which points back at their delegates. While convenient, I fear this breaks some part of the abstraction. So I ask for comments. JQS From strandh at labri.fr Wed Aug 17 18:21:24 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 17 Aug 2005 20:21:24 +0200 Subject: [climacs-devel] Marks, Buffers and Panes In-Reply-To: <43035437.3040101@yahoo.com> References: <43035437.3040101@yahoo.com> Message-ID: <17155.32804.732963.917653@serveur5.labri.fr> Hello, John Q Splittist writes: > In general this works very well - com-foo calls foo with (point > (current-window)), com-bar (numarg) calls bar with point and count, and > so on. Where it doesn't work is if foo or bar need to know what the > current syntax for a buffer is, because, for example, they call > end-of-definition, which specializes on syntax. The problem is that from > a supplied mark, the function foo can only access the implementation > buffer, not the enclosing delegating buffer, which is where the syntax is. > > One answer would be to put a slot on delagatee buffers which points back > at their delegates. While convenient, I fear this breaks some part of > the abstraction. So I ask for comments. I don't see why it would. You could conveniently hide this in an methods (syntax buffer) and (setf (syntax buffer)) that call themselves on the delegate. -- 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 strandh at labri.fr Wed Aug 17 18:43:36 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 17 Aug 2005 20:43:36 +0200 Subject: [climacs-devel] Marks, Buffers and Panes In-Reply-To: <17155.32804.732963.917653@serveur5.labri.fr> References: <43035437.3040101@yahoo.com> <17155.32804.732963.917653@serveur5.labri.fr> Message-ID: <17155.34136.121054.392171@serveur5.labri.fr> Robert Strandh writes: > Hello, > > > One answer would be to put a slot on delagatee buffers which points back > > at their delegates. While convenient, I fear this breaks some part of > > the abstraction. So I ask for comments. > > I don't see why it would. Well, I do see why it would break the general idea that a buffer should not know that it has a delegate at all. If you are worried about that, you could always use a weak hash table that translates from buffers to delegates instead. -- 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 a_bakic at yahoo.com Thu Aug 18 08:06:33 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 18 Aug 2005 01:06:33 -0700 (PDT) Subject: [climacs-devel] Marks, Buffers and Panes In-Reply-To: <43035437.3040101@yahoo.com> Message-ID: <20050818080633.22762.qmail@web40626.mail.yahoo.com> Hi, I sent a reply yesterday, but it did not seem to pass through. Since (1) you want to pass a mark instead of climacs-buffer, and (2) the implementation buffer (accessible via the mark) knows nothing about the syntax, we have a problem of the kind I found sometime in February, when I proposed adding layers of abstractions instead of lumping together all kinds of functionalities in the same buffer class. I agree with you that the implementation buffer ideally should not know about one that has the syntax slot. Now, if you still do not want to pass buffers to your functions, perhaps you can pass them a different kind of mark, say delegation-mark (or climacs-mark, with even more information), which has information both about the climacs-buffer and the regular mark. This is also an opportunity to classify the functions based on the functionality and information they need. Just a hint, perhaps you will come up with something simpler and cleaner. Alex --- John Q Splittist wrote: > I am rewriting some of the commands to be available more generally as > functions, for the building up of further functions and commands. My > idea was that, instead of taking the GNU Emacs approach of having every > function operating on the current buffer, only to wrap it later in > something that dynamically changes what the 'current buffer' is, > functions should be passed a mark, and operate on the relevant buffer > etc from information gained from the mark. > > In general this works very well - com-foo calls foo with (point > (current-window)), com-bar (numarg) calls bar with point and count, and > so on. Where it doesn't work is if foo or bar need to know what the > current syntax for a buffer is, because, for example, they call > end-of-definition, which specializes on syntax. The problem is that from > a supplied mark, the function foo can only access the implementation > buffer, not the enclosing delegating buffer, which is where the syntax is. > > One answer would be to put a slot on delagatee buffers which points back > at their delegates. While convenient, I fear this breaks some part of > the abstraction. So I ask for comments. > > JQS > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Wed Aug 24 22:45:02 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Wed, 24 Aug 2005 15:45:02 -0700 Subject: [climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer) Message-ID: <20050824154501.A18435@eskimo.com> Hi everybody, I've been looking through the syntax classes but it's a lot to learn at once (especially when I'm learning about CLOS and brushing up on my LISP at the same time). I know that display-parse-tree gets called for every node in the tree. Can that handle anything like Emacs's text properties or overlays? In the most general case, they apply to characters and not parse-tree items, so the character-by-character formatting of the overlay would have to be mixed with the formatting of the parse item. Right now, the only thing on the screen that has X-Y coordinates derived from a text location seems to be the cursor. And I've edited LISP files with strings (displayed in a larger italic font) and the cursor can go to the wrong place in the window, so I suspect the syntax machinery is not being used. Ultimately I'm dreaming of an evaluation package that would replace the teletype mentality of the traditional top-level loop. With my package, the user would highlight text to act on (evaluate, macro expand, etc.), either using unstructured commands (move by character and line) or structured ones (mark defun around point). The results might be substituted for the original text or the package might keep a history of the computation. I can't decide much more about the design until I have a prototype. (I tried a few experiments with Emacs and its structured navigation functions are far too inaccurate to be useful.) Thanks, -- Derek From strandh at labri.fr Thu Aug 25 04:34:46 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 25 Aug 2005 06:34:46 +0200 Subject: [climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer) In-Reply-To: <20050824154501.A18435@eskimo.com> References: <20050824154501.A18435@eskimo.com> Message-ID: <17165.19046.514630.474322@serveur5.labri.fr> Hello, Derek Peschel writes: > > I know that display-parse-tree gets called for every node in the tree. Sort of. It gets called for every parse tree that is at least partially on display in a window. > Can that handle anything like Emacs's text properties or overlays? > In the most general case, they apply to characters and not parse-tree items, > so the character-by-character formatting of the overlay would have to be > mixed with the formatting of the parse item. If you do want overlays, you probably would have to do essentially what emacs does, as a mechanism separate from that of displaying parse trees. You could also exploit the fact that a Climacs buffer can contain any Common Lisp object. You could for instance convert a sequence of characters to an object of type S-expression and then have a PRESENT method on it that makes it display in a different way. > Right now, the only thing on the screen that has X-Y coordinates derived > from a text location seems to be the cursor. And I've edited LISP files > with strings (displayed in a larger italic font) and the cursor can go to > the wrong place in the window, so I suspect the syntax machinery is not > being used. Right, the way the position of the cursor is currently computed is bogus. > Ultimately I'm dreaming of an evaluation package that would replace the > teletype mentality of the traditional top-level loop. With my package, > the user would highlight text to act on (evaluate, macro expand, etc.), > either using unstructured commands (move by character and line) or > structured ones (mark defun around point). The results might be substituted > for the original text or the package might keep a history of the computation. > I can't decide much more about the design until I have a prototype. (I tried > a few experiments with Emacs and its structured navigation functions are > far too inaccurate to be useful.) For the structured part, you could highlight a parse tree (say) by entering it in a hash table of parse trees to be highlighted in particular ways, and then use an :around method to turn on and off highlighting. Clicking on some text could select that parse tree, or you could use specific commands for that. For the unstructured commands, I am not sure. It seems to me like you might want to indicate a certain parse tree by putting point there, but you probably would not want arbitrary sequences of characters to be selected. At least not in this particular application. -- 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 dpeschel at eskimo.com Thu Aug 25 16:35:18 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Thu, 25 Aug 2005 09:35:18 -0700 Subject: [climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer) In-Reply-To: <17165.19046.514630.474322@serveur5.labri.fr>; from strandh@labri.fr on Thu, Aug 25, 2005 at 06:34:46AM +0200 References: <20050824154501.A18435@eskimo.com> <17165.19046.514630.474322@serveur5.labri.fr> Message-ID: <20050825093518.A16434@eskimo.com> On Thu, Aug 25, 2005 at 06:34:46AM +0200, Robert Strandh wrote: > Sort of. It gets called for every parse tree that is at least > partially on display in a window. Does the caller of display-parse-tree keep track of what's on display, say by tracking the parse item in the upper left corner of the window? What's the sequence of events when you scroll the window? > > Can that handle anything like Emacs's text properties or overlays? > > In the most general case, they apply to characters and not parse-tree items, > > so the character-by-character formatting of the overlay would have to be > > mixed with the formatting of the parse item. > > If you do want overlays, you probably would have to do essentially > what emacs does, as a mechanism separate from that of displaying parse > trees. But I assume Emacs merges the overlay information into a data structure holding characters, while I would need to work with characters and parse state. > > Right now, the only thing on the screen that has X-Y coordinates derived > > from a text location seems to be the cursor. And I've edited LISP files > > with strings (displayed in a larger italic font) and the cursor can go to > > the wrong place in the window, so I suspect the syntax machinery is not > > being used. > > Right, the way the position of the cursor is currently computed is > bogus. So I won't use the cursor code as an example. :) But I mentioned it because it would have to deal with the same issues I've been thinking about. I can think of two ways to do it, and there may be better ones: - treat all chars. as monospaced -- keep cursor location in line and character coordinates -- attach pixel coordinates to each parse item, or each character of each parse item -- when cursor moves, find new pixel coordinates from new line/character coordinates (using various data structures) -- use pixel coordinates to display the cursor - treat buffer as a series of lines containing non-monospaced chars., so that the goal column is a pixel coordinate rather than a character offset in the line -- the data structures are probably the same as the first method, actually If you could explain how Emacs places the cursor, that might help me think about Climacs's design. > For the structured part, you could highlight a parse tree (say) by > entering it in a hash table of parse trees to be highlighted in > particular ways, and then use an :around method to turn on and off > highlighting. Clicking on some text could select that parse tree, or > you could use specific commands for that. The simple-minded approach would add a state field to every syntax item; display-parse-tree would check the state field and choose a presentation style. Your :around method would set the state to "highlighted" at some node in the tree, and the tree structure would propagate the state to the subtrees of the node and thus the correct block of text, and then the :around method would set the state back to "unhighlighted" when the appropriate tree had been traversed. Right? You also mentioned a PRESENT method. How might that help the implementation? > For the unstructured commands, I am not sure. It seems to me like you > might want to indicate a certain parse tree by putting point there, > but you probably would not want arbitrary sequences of characters to > be selected. At least not in this particular application. In fact I did mean "arbitrary sequences of characters" but you're right, it does violate the abstraction and I can't think of a good reason when evaluating LISP code. Still, restricting the marking to entire parse items may be a problem for other applications. That's why it's worth thinking about marking characters too. Even for LISP, it may be useful to mark snippets of code in strings or comments, or evaluate part of a variable name. For those you'd need to look inside parse items. -- Derek From strandh at labri.fr Thu Aug 25 18:20:50 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 25 Aug 2005 20:20:50 +0200 Subject: [climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer) In-Reply-To: <20050825093518.A16434@eskimo.com> References: <20050824154501.A18435@eskimo.com> <17165.19046.514630.474322@serveur5.labri.fr> <20050825093518.A16434@eskimo.com> Message-ID: <17166.3074.798047.229312@serveur5.labri.fr> Hello, Derek Peschel writes: > On Thu, Aug 25, 2005 at 06:34:46AM +0200, Robert Strandh wrote: > > Sort of. It gets called for every parse tree that is at least > > partially on display in a window. > > Does the caller of display-parse-tree keep track of what's on display, > say by tracking the parse item in the upper left corner of the window? No, there is an :around method that checks whether part of the parse tree is on display, if so, it does (call-next-method). We guarantee that the leaf parse trees (lexemes) do not span newlines, so no need to take care of partially-displayed lexemes. The rest is done by CLIM. We use updating-output and CLIM figures out if things were already on display, and if it can optimize the redisplay. As far as Climacs is concerned, it just displays everything that is visible. > What's the sequence of events when you scroll the window? Noting particular. It goes through the same thing, except that this time, the :around method will (call-next-method) on a different set of parse trees. If some of them are the same as last time, CLIM will try to optimize. > > If you do want overlays, you probably would have to do essentially > > what emacs does, as a mechanism separate from that of displaying parse > > trees. > > But I assume Emacs merges the overlay information into a data structure > holding characters, while I would need to work with characters and parse > state. I don't think I would organize that in this way at all. I would keep the overlays in a data structure (interval tree?) that could be interrogated by the display-parse-tree function so that when an object is to be presented, its visual aspects could be modified accordingly. > > Right, the way the position of the cursor is currently computed is > > bogus. > > So I won't use the cursor code as an example. :) But I mentioned it because > it would have to deal with the same issues I've been thinking > about. You think so? I got the impression that overlays were based not on XY coordinates but on buffer positions. Maybe I'm wrong. > I can > think of two ways to do it, and there may be better ones: > > - treat all chars. as monospaced -- keep cursor location in line > and character coordinates -- attach pixel coordinates to each > parse item, or each character of each parse item -- when cursor > moves, find new pixel coordinates from new line/character > coordinates (using various data structures) -- use pixel > coordinates to display the cursor This does not sound right at all. In particular because that information would have to be recomputed in every command-loop iteration in case scrolling has happened. > - treat buffer as a series of lines containing non-monospaced > chars., so that the goal column is a pixel coordinate rather > than a character offset in the line -- the data structures > are probably the same as the first method, actually Actually, probably the best way to go is to interrogate the output record in which the cursor is located as to its position. and then, based on the contents of that output record, compute the exact location of the cursor. > If you could explain how Emacs places the cursor, that might help me think > about Climacs's design. Sorry, I do not know that. > > For the structured part, you could highlight a parse tree (say) by > > entering it in a hash table of parse trees to be highlighted in > > particular ways, and then use an :around method to turn on and off > > highlighting. Clicking on some text could select that parse tree, or > > you could use specific commands for that. > > The simple-minded approach would add a state field to every syntax item; > display-parse-tree would check the state field and choose a presentation > style. Your :around method would set the state to "highlighted" at some > node in the tree, and the tree structure would propagate the state to the > subtrees of the node and thus the correct block of text, and then the :around > method would set the state back to "unhighlighted" when the appropriate > tree had been traversed. Right? Yep > You also mentioned a PRESENT method. How might that help the > implementation? Anything that should be highlighted or clickable should use PRESENT so that it can be used by ACCEPT in other contexts than the exact one you have been thinking of. > > For the unstructured commands, I am not sure. It seems to me like you > > might want to indicate a certain parse tree by putting point there, > > but you probably would not want arbitrary sequences of characters to > > be selected. At least not in this particular application. > > In fact I did mean "arbitrary sequences of characters" but you're right, > it does violate the abstraction and I can't think of a good reason when > evaluating LISP code. Still, restricting the marking to entire parse > items may be a problem for other applications. That's why it's worth > thinking about marking characters too. OK, I'll let you think about it some more then :-) Personally, I think that for these "other applications", we should have a different grammar so that the parse trees look different, and so that as a consequence, highlighting and selection will be appropriate for the particular syntax of that application. This could be individual characters in some applications of course. > Even for LISP, it may be useful to mark snippets of code in strings or > comments, or evaluate part of a variable name. For those you'd need to > look inside parse items. Again, I'll let you think about that some more. While it could be useful, I am not willing to put it huge amounts of kludgey code unless there is a real need. -- 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 csr21 at cam.ac.uk Thu Aug 25 18:48:35 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 25 Aug 2005 19:48:35 +0100 Subject: [climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer) In-Reply-To: <17166.3074.798047.229312@serveur5.labri.fr> (Robert Strandh's message of "Thu, 25 Aug 2005 20:20:50 +0200") References: <20050824154501.A18435@eskimo.com> <17165.19046.514630.474322@serveur5.labri.fr> <20050825093518.A16434@eskimo.com> <17166.3074.798047.229312@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Hello, > > Derek Peschel writes: > > On Thu, Aug 25, 2005 at 06:34:46AM +0200, Robert Strandh wrote: > > > Sort of. It gets called for every parse tree that is at least > > > partially on display in a window. > > > > Does the caller of display-parse-tree keep track of what's on display, > > say by tracking the parse item in the upper left corner of the window? > > No, there is an :around method that checks whether part of the parse > tree is on display, if so, it does (call-next-method). We guarantee > that the leaf parse trees (lexemes) do not span newlines, so no need > to take care of partially-displayed lexemes. Just to add to that -- that's only sometimes true. Prolog syntax, for instance, allows lexemes to have embedded newlines; its DISPLAY-PARSE-TREE method for prolog tokens is consequently more complicated. (The newlines in the lexer are at least partly motivated by making the Prolog syntax implementation very close to the ISO specification document, but I believe that not doing so adds much extra complexity to the parsing stage in Prolog's case). Cheers, Christophe From dpeschel at eskimo.com Sat Aug 27 18:39:14 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 27 Aug 2005 11:39:14 -0700 Subject: [climacs-devel] I can't get the Automaton system to load Message-ID: <20050827113914.A26261@eskimo.com> Although I've set up the .asd files (hopefully correctly) ASDF keeps complaining about the component "rt" which is the testing/rt.lisp file. I'm running SBCL 0.9.0 on Mac OS 10.3.7. Inside my home directory I have .sbcl/systems which contains all the .asd files as symbolic links. The link targets are absolute pathnames inside my copy of the CVS tree. I've tried fiddling around in several ways -- splitting the two defsystem calls into two separate .asd files, changing the name of the climacs.tests pacakge to climacs-tests (in case ASDF's rules for generating file names cause it to chop off the ".tests" and think it's dealing with the climacs package a second time), and other miscellaneous ideas. The rt.lisp file gets compiled but something is still failing. What I really need is better diagnostics from ASDF. The manual doesn't say much on that subject. Does anyone have experience diagnosing and fixing this kind of problem? Thanks, -- Derek From a_bakic at yahoo.com Sat Aug 27 19:43:04 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 27 Aug 2005 12:43:04 -0700 (PDT) Subject: [climacs-devel] I can't get the Automaton system to load In-Reply-To: <20050827113914.A26261@eskimo.com> Message-ID: <20050827194304.78268.qmail@web40601.mail.yahoo.com> Hi, I am using SBCL 0.9.3.32 on x86_64 GNU/Linux, and asdf revision 1.87 (can't remember where I got it from). I just checked out a fresh climacs CVS copy, and added Flexichain in the climacs top directory (can't remember where I got Flexichain either). My build.lisp file contains: (require :asdf) (push "HOMEDIR/cvsprojects/systems/" asdf:*central-registry*) (asdf:oos 'asdf:load-op :climacs) #+cmu (defun start () (mp::init-multi-processing) (mp:make-process #'climacs-gui::climacs :name "climacs-thread") (mp::idle-process-loop)) #+cmu(start) and HOMEDIR/cvsprojects/systems/ contains flexichain.asd -> ../climacs/Flexichain/flexichain.asd mcclim.asd -> SOMEDIR/cvsprojects/mcclim/mcclim.asd clx.asd -> SOMEDIR/cvsprojects/clx/clx.asd So when I start SBCL and (load "build"), I get everything built. Perhaps it could help if you sent your SBCL output. Regards, Alex __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From dpeschel at eskimo.com Sat Aug 27 20:23:54 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 27 Aug 2005 13:23:54 -0700 Subject: [climacs-devel] I can't get the Automaton system to load In-Reply-To: <20050827194304.78268.qmail@web40601.mail.yahoo.com>; from a_bakic@yahoo.com on Sat, Aug 27, 2005 at 12:43:04PM -0700 References: <20050827113914.A26261@eskimo.com> <20050827194304.78268.qmail@web40601.mail.yahoo.com> Message-ID: <20050827132354.A915@eskimo.com> On Sat, Aug 27, 2005 at 12:43:04PM -0700, Aleksandar Bakic wrote: > I am using SBCL 0.9.3.32 on x86_64 GNU/Linux, and asdf revision 1.87 (can't > remember where I got it from). I just checked out a fresh climacs CVS copy, and > added Flexichain in the climacs top directory (can't remember where I got > Flexichain either). My build.lisp file contains: The version of ASDF that comes with SBCL is much older, 1.11 I think. I'll try the things you have in build.lisp, and try a new version of ASDF, and get back to you. I looked at the dependency tree and created a file with a bunch of (load) commands. It works fine. So ASDF's bookkeeping seems to be at fault. -- Derek From dpeschel at eskimo.com Sat Aug 27 21:47:20 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 27 Aug 2005 14:47:20 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method Message-ID: <20050827144719.A2240@eskimo.com> A regexp object may temporarily have a KIND slot of nil, but the print-object method can't handle that case. In normal use this doesn't matter, but when tracing the parsing functions, the debugger tries to call print-object on fresly-created regexp objects. So I've taken a stab at a patch, copied below. It may be a good idea to create a similar case in the REGEXP-AUTOMATON method but I don't know what the action of the case should be. It may also be a good idea to have an output syntax that can't be mistaken for any legal input. The real Perl engine, and many clones, first try to read a quantifier when they see a left brace. If the read fails they reread the "quantifier" as a string of literal characters. If Automaton ever copied that dubious feature, then my current syntax would become legal input. So is it best to just choose a new "magic" character or string now? Or perhaps objects should be intiialized so they print out as "()" or "#" (without the quotes). -- Derek *** regexp.lisp Sat Aug 27 13:50:55 2005 --- regexp.lisp.new Sat Aug 27 14:39:25 2005 *************** *** 54,59 **** --- 54,65 ---- ;;; non-negative decimal integers and include both end points, and if ;;; n and m have the same number of digits, then the conforming ;;; strings must have that length (i.e. prefixed by 0's). + ;;; + ;;; The printout "{nilkind}" denotes a regexp object whose KIND slot + ;;; has not been initialized by the parsing routines. Debugging or + ;;; tracing can cause such objects to be printed. The language has + ;;; no syntax for uninitialized regexp objects and the "{nilkind}" + ;;; notation was designed to cause a syntax error when read. (in-package :automaton) *************** *** 162,167 **** --- 168,175 ---- (defmethod print-object ((r regexp) s) (ecase (kind r) + ((nil) + (princ "{nilkind}" s)) (:union (princ "(" s) (print-object (exp1 r) s) From csr21 at cam.ac.uk Sat Aug 27 22:02:15 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 27 Aug 2005 23:02:15 +0100 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050827144719.A2240@eskimo.com> (Derek Peschel's message of "Sat, 27 Aug 2005 14:47:20 -0700") References: <20050827144719.A2240@eskimo.com> Message-ID: Derek Peschel writes: > A regexp object may temporarily have a KIND slot of nil, but the print-object > method can't handle that case. In normal use this doesn't matter, but when > tracing the parsing functions, the debugger tries to call print-object > on fresly-created regexp objects. So I've taken a stab at a patch, copied > below. I don't know what's the rationale behind the print-object method here, but wouldn't one solution be to print those regexps which aren't meant to be subsequently readable with PRINT-UNREADABLE-OBJECT? Cheers, Christophe From dpeschel at eskimo.com Sat Aug 27 22:51:08 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 27 Aug 2005 15:51:08 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: ; from csr21@cam.ac.uk on Sat, Aug 27, 2005 at 11:02:15PM +0100 References: <20050827144719.A2240@eskimo.com> Message-ID: <20050827155108.A4644@eskimo.com> On Sat, Aug 27, 2005 at 11:02:15PM +0100, Christophe Rhodes wrote: > I don't know what's the rationale behind the print-object method here, > but wouldn't one solution be to print those regexps which aren't meant > to be subsequently readable with PRINT-UNREADABLE-OBJECT? The way SBCL does tracing, the printouts are a mixture of LISP syntax and the syntax generated by regexp's print-object method. Here's the beginning of a trace log. "{nilkind}" is produced by my patch. ------------------------------------------------------------------------------ 0: (STRING-REGEXP "a") 1: (PARSE-UNION-EXP {nilkind}) 2: (PARSE-INTERSECTION-EXP {nilkind}) 3: (PARSE-CONCATENATION-EXP {nilkind}) 4: (PARSE-REPEAT-EXP {nilkind}) 5: (PARSE-COMPLEMENT-EXP {nilkind}) 6: (CHECK {nilkind} 2) 6: CHECK returned T ------------------------------------------------------------------------------ You can see that LISP syntax is mixed with regexp parser syntax. I assume PRINT-UNREADABLE-OBJECT uses LISP's #<...> syntax. That may be a _legal_ regexp input because # may refer to the empty language and <...> may refer to a named automaton. ("May" because you can change some parser options and thus the input syntax.) So you wouldn't want to have #<...> appear where legal parser input now appears. And to make things worse, if the syntax is designed to be illegal on reading, it should be illegal whenever the object appears sa a part of some larger expression, e.g., inside a character class or after an operator. The syntax should also be illegal regardless of how you have configured the parser. My current notation is legal inside a character class. Perhaps the real solution is to print all regexp objects in LISP read syntax. But even that has to be done carefully, because regexp objects can include other regexp objects. I would hope to see the fewest possible nested #<...> constructs. And if you allow the LISP reader to read and complain about illegal regexp objects, you should allow it to read and accept legal regexp objects. I don't know enough about good LISP style to design that. A reader macro? Some kind of CLOS input syntax? Printing objcts as calls to LISP functions that can recreate them? -- Derek From a_bakic at yahoo.com Sat Aug 27 23:49:26 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 27 Aug 2005 16:49:26 -0700 (PDT) Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: Message-ID: <20050827234926.79825.qmail@web40624.mail.yahoo.com> > I don't know what's the rationale behind the print-object method here, > but wouldn't one solution be to print those regexps which aren't meant > to be subsequently readable with PRINT-UNREADABLE-OBJECT? The origin of the print-object is Java's ToString (in the original code). I thought it's more useful this way, and I used it for debugging purposes, without having a greater goal in mind. Is there a good reason to make something more powerful out of it? (If unsure, print-unreadable-object might be enough for debugging purposes.) Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Sun Aug 28 15:50:15 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sun, 28 Aug 2005 08:50:15 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050827234926.79825.qmail@web40624.mail.yahoo.com>; from a_bakic@yahoo.com on Sat, Aug 27, 2005 at 04:49:26PM -0700 References: <20050827234926.79825.qmail@web40624.mail.yahoo.com> Message-ID: <20050828085015.A11611@eskimo.com> On Sat, Aug 27, 2005 at 04:49:26PM -0700, Aleksandar Bakic wrote: > The origin of the print-object is Java's ToString (in the original code). I > thought it's more useful this way, and I used it for debugging purposes, > without having a greater goal in mind. Is there a good reason to make something > more powerful out of it? (If unsure, print-unreadable-object might be enough > for debugging purposes.) Would you change anything about my patch? As I said to Christophe, I'm still looking for a syntax that produces the same results whenever it's read back. And my original post has some other questions which no one's addressed yet. -- Derek From a_bakic at yahoo.com Sun Aug 28 18:21:41 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 28 Aug 2005 11:21:41 -0700 (PDT) Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050828085015.A11611@eskimo.com> Message-ID: <20050828182141.40896.qmail@web40602.mail.yahoo.com> Hi, > Would you change anything about my patch? I looked at the Java code again: it does not print anything when kind is nil, so perhaps we could do that, too. I am willing to change something triggered by your patch (so that errors are not signalled when tracing the parsing process), but I am not sure what that something is yet. An empty output would trigger a syntax error in a similar way the {nilkind} would (unless it, actually, can be parsed). > As I said to Christophe, I'm still looking for a syntax that produces the > same results whenever it's read back. And my original post has some other > questions which no one's addressed yet. I'll try to address them (let me know if I missed something): > It may be a good idea to create a similar case in the REGEXP-AUTOMATON method > but I don't know what the action of the case should be. I am not sure either, perhaps an empty output, too. Like with the above issue, I haven't thought about possible uses of this functionality. I just wrote the same (to the extent I understood it) functionality that was present in the Java code. > It may also be a good idea to have an output syntax that can't be mistaken > for any legal input. The real Perl engine, and many clones, first try to > read a quantifier when they see a left brace. If the read fails they reread > the "quantifier" as a string of literal characters. If Automaton ever copied > that dubious feature, then my current syntax would become legal input. > So is it best to just choose a new "magic" character or string now? If the purpose of the magic character/string is to cause a syntax error, why is empty string not good enough? You would get an "unexpected end of string" error. > Or perhaps objects should be intiialized so they print out as "()" or "#" > (without the quotes). I am not sure that is correct, because an incomplete regexp object should accept neither an empty string nor the empty language. > You can see that LISP syntax is mixed with regexp parser syntax. > I assume PRINT-UNREADABLE-OBJECT uses LISP's #<...> syntax. That may be a > _legal_ regexp input because # may refer to the empty language and <...> > may refer to a named automaton. ("May" because you can change some parser > options and thus the input syntax.) So you wouldn't want to have #<...> > appear where legal parser input now appears. I assume the #<...> syntax would include the address of a regexp object, so it would hardly be parsable (you'd get something like "undefined subautomaton" error). > And to make things worse, if the syntax is designed to be illegal on reading, > it should be illegal whenever the object appears sa a part of some larger > expression, e.g., inside a character class or after an operator. The syntax > should also be illegal regardless of how you have configured the parser. > My current notation is legal inside a character class. If the #<...> is illegal as argued above, it is illegal in nested regexps, too. > And if you allow the LISP reader to read and complain about illegal regexp > objects, you should allow it to read and accept legal regexp objects. > I don't know enough about good LISP style to design that. A reader macro? > Some kind of CLOS input syntax? Printing objcts as calls to LISP functions > that can recreate them? You could just use string-regexp. If you define a reader macro to call string-regexp, you would prepend a macro dispatch character unambiguously. To wrap up: the empty printout, like in the original code, or something that causes a syntax error. The print-unreadable-object is probably the standard way to do this. I hope this suffices. I'd like to hear pros and cons for the above two options. Thank you for your original email, you have clearly found an issue (that perhaps was not there in the original code, but I introduced it for some reason or none). Regards, Alex __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From a_bakic at yahoo.com Sun Aug 28 19:03:18 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 28 Aug 2005 12:03:18 -0700 (PDT) Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050828182141.40896.qmail@web40602.mail.yahoo.com> Message-ID: <20050828190318.45968.qmail@web40602.mail.yahoo.com> I played a bit with the real code, so there are some news. > An empty output would trigger a syntax error in a similar way the {nilkind} would (unless it, > actually, can be parsed). > I assume the #<...> syntax would include the address of a regexp object, so > it would hardly be parsable (you'd get something like "undefined subautomaton" > error). Surprise! We are talking about string-regexp, where both "{nilkind}" and "#<...>" are parsable. It's in regexp-automaton that the latter may not be accepted. > If the #<...> is illegal as argued above, it is illegal in nested regexps, too. Actually, this may or may not be true (hopefully it is). Similarly for the empty printout. > You could just use string-regexp. If you define a reader macro to call > string-regexp, you would prepend a macro dispatch character unambiguously. Note that the external representation of a regexp is not a string. You would have to print it to a string. > To wrap up: the empty printout, like in the original code, or something that > causes a syntax error. The print-unreadable-object is probably the standard > way to do this. BTW, with the currenct code, in SBCL debugger's backtrace you get: 1: (AUTOMATON::CHECK #) 2: (AUTOMATON::PARSE-COMPLEMENT-EXP #) 3: (AUTOMATON::PARSE-REPEAT-EXP #) 4: (AUTOMATON::PARSE-CONCATENATION-EXP #) 5: (AUTOMATON::PARSE-INTERSECTION-EXP #) 6: (AUTOMATON::PARSE-UNION-EXP #) which seems fine to me. Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Sun Aug 28 22:01:04 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sun, 28 Aug 2005 15:01:04 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050828182141.40896.qmail@web40602.mail.yahoo.com>; from a_bakic@yahoo.com on Sun, Aug 28, 2005 at 11:21:41AM -0700 References: <20050828085015.A11611@eskimo.com> <20050828182141.40896.qmail@web40602.mail.yahoo.com> Message-ID: <20050828150104.B25101@eskimo.com> On Sun, Aug 28, 2005 at 11:21:41AM -0700, Aleksandar Bakic wrote: > but I am not sure what that something is yet. An empty output would trigger a > syntax error in a similar way the {nilkind} would (unless it, actually, can be > parsed). The trace log doesn't put any quotation marks around the results of print- object, so an empty output would probably only show up as extra space. That's not convenient. > > It may be a good idea to create a similar case in the REGEXP-AUTOMATON method > > but I don't know what the action of the case should be. > > I am not sure either, perhaps an empty output, too. Like with the above issue, > I haven't thought about possible uses of this functionality. I just wrote the > same (to the extent I understood it) functionality that was present in the Java > code. Is "output" the right word? REGEXP-AUTOMATON takes a regexp object (a tree created from STRING-REGEXP) and returns an automaton to parse the regexp. I don't know what automaton would correspond to the uninitialized regexp object. > > It may also be a good idea to have an output syntax that can't be mistaken > > for any legal input. The real Perl engine, and many clones, first try to > > read a quantifier when they see a left brace. If the read fails they reread > > the "quantifier" as a string of literal characters. If Automaton ever copied > > that dubious feature, then my current syntax would become legal input. > > So is it best to just choose a new "magic" character or string now? > > If the purpose of the magic character/string is to cause a syntax error, why is > empty string not good enough? You would get an "unexpected end of string" > error. For simple cases, yes, you would get an error. But say you have a regexp object that's a sequence of three others: character "a", uninitialized object, character "b". Then you would print "a", the empty string, and "b". This gives "ab" which is indistinguishable from character "a" followed by character "b". Your uninitialized object has disappeared from the printout and you also wouldn't see an error if you read in the printout. > > Or perhaps objects should be intiialized so they print out as "()" or "#" > > (without the quotes). > > I am not sure that is correct, because an incomplete regexp object should > accept neither an empty string nor the empty language. Good point. The problem is that these uninitialized objects don't fit into the language, you never want to accept them, and you always want to see them (to accurately debug code). To me that strengthens the case for using a visible character or string. > I assume the #<...> syntax would include the address of a regexp object, so it > would hardly be parsable (you'd get something like "undefined subautomaton" > error). That dpeends on what can go into the name of an automaton. To me, an error that says "you have tried to read in an uninitialized boject" is better than an error that says "you have an illegal automaton name" or "you have a brace followed by a letter" and just happens to mean "you have tried to read in an uninitialized object". My current "{nilkind}" notation doesn't produce an accurate error. > If the #<...> is illegal as argued above, it is illegal in nested regexps, too. True. The point about being illegal by accident also holds for nested regexps. > You could just use string-regexp. If you define a reader macro to call > string-regexp, you would prepend a macro dispatch character unambiguously. That would work -- then the trace logs would show #R"" or whatever (with the quote marks). But you still have the problem of a legal expression including an uninitialized object inside. If the #R macro reads strings, by convention it doesn't look for #<...> syntax inside them, right? > Thank you for your original email, you have clearly found an issue (that > perhaps was not there in the original code, but I introduced it for some reason > or none). You're welcome. Eventually I want to understand the syntax, fix the grammar, create a Climacs syntax file for the grammar, and get Climacs to use the syntax file to color the echo area while you're entering a search expression. But that's another subject. -- Derek From dpeschel at eskimo.com Sun Aug 28 22:14:50 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sun, 28 Aug 2005 15:14:50 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050828190318.45968.qmail@web40602.mail.yahoo.com>; from a_bakic@yahoo.com on Sun, Aug 28, 2005 at 12:03:18PM -0700 References: <20050828182141.40896.qmail@web40602.mail.yahoo.com> <20050828190318.45968.qmail@web40602.mail.yahoo.com> Message-ID: <20050828151450.C25101@eskimo.com> On Sun, Aug 28, 2005 at 12:03:18PM -0700, Aleksandar Bakic wrote: > Surprise! We are talking about string-regexp, where both "{nilkind}" and > "#<...>" are parsable. It's in regexp-automaton that the latter may not be > accepted. You're right. Wow, I was sure the code would reject a letter after a brace. But it does parse it. Inside a character class it definitely parses it since braces aren't special there. > BTW, with the currenct code, in SBCL debugger's backtrace you get: > > 1: (AUTOMATON::CHECK #) > 2: (AUTOMATON::PARSE-COMPLEMENT-EXP #) > 3: (AUTOMATON::PARSE-REPEAT-EXP #) > 4: (AUTOMATON::PARSE-CONCATENATION-EXP #) > 5: (AUTOMATON::PARSE-INTERSECTION-EXP #) > 6: (AUTOMATON::PARSE-UNION-EXP #) > > which seems fine to me. By "current" do you mean without the patch? Without the patch, I get the "#" sometimes, but when calling a traced function I get a debugger prompt. Then I ask to print the local variables, the debugger tries to print the object again, and I get a second debugger prompt. Very frustrating. I wouldn't say that seems fine. If this makes any difference, I loaded regexp.lisp after (declaim (optimize (debug 3) (safety 3) (speed 0))) With the patch and the optimize settings above, the trace logs don't enter the debugger. I assume the "#" printouts go away too but I haven't checked. -- Derek From dpeschel at eskimo.com Mon Aug 29 03:36:01 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sun, 28 Aug 2005 20:36:01 -0700 Subject: [climacs-devel] I can't get the Automaton system to load In-Reply-To: <20050827194304.78268.qmail@web40601.mail.yahoo.com>; from a_bakic@yahoo.com on Sat, Aug 27, 2005 at 12:43:04PM -0700 References: <20050827113914.A26261@eskimo.com> <20050827194304.78268.qmail@web40601.mail.yahoo.com> Message-ID: <20050828203601.A9530@eskimo.com> On Sat, Aug 27, 2005 at 12:43:04PM -0700, Aleksandar Bakic wrote: > So when I start SBCL and (load "build"), I get everything built. Perhaps it > could help if you sent your SBCL output. Does your build file load climacs-tests or automaton or automaton-test? I've gotten the latest release version of ASDF (1.78, not 1.87 as you mentioned) and put it in /usr/local/lib/sbcl. I'm still getting weird results. I think it's best to set up a fresh copy of everything before I send you output. -- Derek From a_bakic at yahoo.com Mon Aug 29 06:19:35 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 28 Aug 2005 23:19:35 -0700 (PDT) Subject: [climacs-devel] I can't get the Automaton system to load In-Reply-To: <20050828203601.A9530@eskimo.com> Message-ID: <20050829061935.15197.qmail@web40612.mail.yahoo.com> > Does your build file load climacs-tests or automaton or automaton-test? No, currently I type (asdf::oos 'asdf:load-op :climacs.tests) to load them. > I've gotten the latest release version of ASDF (1.78, not 1.87 as you > mentioned) and put it in /usr/local/lib/sbcl. Mine is 1.87. The CVS access is: cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/cclan ;;; This is asdf: Another System Definition Facility. $Revision: 1.87 $ Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Mon Aug 29 07:47:59 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Mon, 29 Aug 2005 00:47:59 -0700 Subject: [climacs-devel] I can't get the Automaton system to load In-Reply-To: <20050829061935.15197.qmail@web40612.mail.yahoo.com>; from a_bakic@yahoo.com on Sun, Aug 28, 2005 at 11:19:35PM -0700 References: <20050828203601.A9530@eskimo.com> <20050829061935.15197.qmail@web40612.mail.yahoo.com> Message-ID: <20050829004759.A20102@eskimo.com> On Sun, Aug 28, 2005 at 11:19:35PM -0700, Aleksandar Bakic wrote: > > I've gotten the latest release version of ASDF (1.78, not 1.87 as you > > mentioned) and put it in /usr/local/lib/sbcl. > > Mine is 1.87. The CVS access is: > > cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/cclan Just to clarify: I included the option "-r RELEASE", which is what I meant by "gotten the latest release version". It looks like you're getting the development version, and it's natural mine would lag behind. -- Derek From splittist at yahoo.com Mon Aug 29 18:39:02 2005 From: splittist at yahoo.com (John Q Splittist) Date: Mon, 29 Aug 2005 19:39:02 +0100 Subject: [climacs-devel] latest progress In-Reply-To: <17147.53436.131130.821037@serveur5.labri.fr> References: <17147.53436.131130.821037@serveur5.labri.fr> Message-ID: <43135646.4060900@yahoo.com> Dear list members, There has been considerable progress since the last update. Not least of which is that we have arranged for Robert to be transferred to an isolated location on the other side of the planet where he will have nothing to do but think about single-address operating systems and improve climacs' mcclim infrastructure. (That is, Robert is on sabbatical in Auckland, NZ, for a year.) Significant developments include: * Robert has factored out some base climacs functionality into a separate ESA (for 'Emacs-Style Application') package, which should make building applications using emacs/climacs interaction (a combination of key-chords and minibuffer commands) relatively simple. An example is included in the esa.lisp file. Among the goodies you get for free by using ESA are keyboard macros and nested command tables. * In preparation for buffer/syntax/view-customized commands pane-specific command tables have been introduced. * Aleksandar Bakic has added cl-automaton (derived from dk.brics.automaton by Anders M?ller) as a basis for regular expression searching. New commands Regex Search Forward and Regex Search Backward should allow you to experiment with this. See the comments at the beginning of cl-automaton/regexp.lisp for an explanation of the regex syntax, which can be subtly different from Emacs or Perl regexps, and which includes some intriguing new constructs. * Robert's LR lisp parser (used in the 'Lisp', as opposed to the old 'Common Lisp', syntax) has been filled out a bit, and some preliminary use made to exploit the parse. For example lisp tokens are now presented as symbols and strings (enabling you to click to choose strings for, say M-% Query Replace) and inapplicable reader-conditionalized forms are now greyed out (there is a *climacs-features* variable to customize this). Try M-x Accept String and mousing around in the buffer; now press the Meta key while mousing - note the different treatment of double-quote-delimited strings. * But one of the big uses of the lisp parse is in indentation. Based on Robert's indentation infrastructure a large number of lisp forms are now indented correctly (many thanks to Christophe Rhodes), in a number of cases far better than emacs. By basing indentation on syntactic rather than textual structure things like ignoring comments are fairly easy. Check out the code towards the end of lisp-syntax.lisp and add indentation for your own favourite forms! * There is a new 'Fundamental' syntax destined to replace the unfortunately-named 'Basic' syntax. * The climacs.asd system definition has been reworked to reflect real dependencies by Andreas Fuchs (with Taylor R. Campbell diagnosing an issue with slidemacs). * A number of new commands have been added, including: Zap to Character and Zap to Object (thanks to Dwight Holman), Mark Word, Mark Whole Buffer, Mark Expression, Comment Region, Uncomment Region, Beginning of Definition, End of Definition, Backward Sentence, Forward Sentence, Not Modified, Set Fill Column, Kill Word, Backward Kill Word, Forward Page, Backward Page, Count Lines Page, Count Lines Region, What Cursor Position, Delete Horizontal Space, Scroll Other Window, Kill Sentence, Backward Kill Sentence, Mark Page, Forward List, Backward List, Up List, Backward Up List, Down List, Backward Kill Expression, Kill Expression, Just One Space, Scroll Other Window Up, Append Next Kill, Set Visited File Name and Revert Buffer. These are, in general, bound to the usual emacs keys. Some commands have had numeric argument handling additions, and some have been renamed (eg. Cut Out -> Kill Region) for consistency with emacs practice. A comparison of some climacs, Gnu Emacs, TI Explorer Zmacs, Hemlock and TECO EMACS commands is available at http://perso.wanadoo.fr/a.d.m/climacs-commands.html . Less significant developments include: * A simple backups feature has been added (when saving a file, an existing file will be renamed with an appended '~'). * Read-only buffers have been added, with Find File Read Only and Toggle Read Only to act on them. * The display cursor functionality has been factored out of each syntax (so cursors are now drawn the same everywhere), and the ability to display the mark has been added - use Toggle Visible Mark to make the mark appear and disappear. The future holds the possibility of (yet) another parsing infrastructure, making it even simpler to add certain types of syntaxes to climacs; a help system; interaction with swank; and (further out, perhaps) interaction with other (Mc)Clim applications. Best regards, JQS/a.d.m From a_bakic at yahoo.com Mon Aug 29 22:02:34 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Mon, 29 Aug 2005 15:02:34 -0700 (PDT) Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050828151450.C25101@eskimo.com> Message-ID: <20050829220234.76318.qmail@web40611.mail.yahoo.com> > Without the patch, I get the "#" sometimes, but when > calling a traced function I get a debugger prompt. I am getting the following behaviors: =-=-= cmucl: * (in-package :automaton) # * (trace make-regexp parse-union-exp parse-concatenation-exp) (MAKE-REGEXP PARSE-UNION-EXP PARSE-CONCATENATION-EXP) * (string-regexp "foo") 0: (PARSE-UNION-EXP #) 1: (PARSE-CONCATENATION-EXP #) 2: (PARSE-CONCATENATION-EXP #) 3: (PARSE-CONCATENATION-EXP #) 3: PARSE-CONCATENATION-EXP returned \o 2: PARSE-CONCATENATION-EXP returned "oo" 1: PARSE-CONCATENATION-EXP returned "foo" 0: PARSE-UNION-EXP returned "foo" "foo" * sbcl: * (string-regexp "foo") debugger invoked on a SB-KERNEL:CASE-FAILURE in thread #: NIL fell through ECASE expression. Wanted one of (:INTERVAL :AUTOMATON :ANYSTRING :STRING :EMPTY :ANYCHAR :CHAR-RANGE :CHAR :COMPLEMENT :REPEAT-MINMAX :REPEAT-MIN :REPEAT ...). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD PRINT-OBJECT (REGEXP T)) #) 0] =-=-= Perhaps Christophe can comment on the difference. Could SBCL be asked to behave like CMUCL in this regard? If it could, would that solve the original problem? Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Mon Aug 29 22:36:23 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Mon, 29 Aug 2005 15:36:23 -0700 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050829220234.76318.qmail@web40611.mail.yahoo.com>; from a_bakic@yahoo.com on Mon, Aug 29, 2005 at 03:02:34PM -0700 References: <20050828151450.C25101@eskimo.com> <20050829220234.76318.qmail@web40611.mail.yahoo.com> Message-ID: <20050829153622.B21516@eskimo.com> On Mon, Aug 29, 2005 at 03:02:34PM -0700, Aleksandar Bakic wrote: > debugger invoked on a SB-KERNEL:CASE-FAILURE in thread # thread" {9003431}>: > NIL fell through ECASE expression. > Wanted one of (:INTERVAL :AUTOMATON > :ANYSTRING > :STRING > :EMPTY > :ANYCHAR > :CHAR-RANGE > :CHAR > :COMPLEMENT > :REPEAT-MINMAX > :REPEAT-MIN > :REPEAT > ...). Yup, that's what I get. Though, as I said, SBCL will also print "#" somtimes, say in backtraces once I'm in the debugger. It will be interesting to see if Christophe has any advice. -- Derek From csr21 at cam.ac.uk Tue Aug 30 06:29:31 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 30 Aug 2005 07:29:31 +0100 Subject: [climacs-devel] Case missing from class regexp's print-object method In-Reply-To: <20050829220234.76318.qmail@web40611.mail.yahoo.com> (Aleksandar Bakic's message of "Mon, 29 Aug 2005 15:02:34 -0700 (PDT)") References: <20050829220234.76318.qmail@web40611.mail.yahoo.com> Message-ID: Aleksandar Bakic writes: > Perhaps Christophe can comment on the difference. Could SBCL be asked to behave > like CMUCL in this regard? Below. This looks like a reasonable request. Cheers, Christophe Index: src/code/ntrace.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/ntrace.lisp,v retrieving revision 1.39 diff -u -r1.39 ntrace.lisp --- src/code/ntrace.lisp 5 Aug 2005 21:14:32 -0000 1.39 +++ src/code/ntrace.lisp 30 Aug 2005 06:28:15 -0000 @@ -265,7 +265,8 @@ ;; with DEFVAR. (locally (declare (special basic-definition arg-list)) - (prin1 `(,(trace-info-what info) , at arg-list))) + (prin1 `(,(trace-info-what info) + ,@(mapcar #'ensure-printable-object arg-list)))) (print-frame-call frame *standard-output*)) (terpri) (trace-print frame (trace-info-print info)) @@ -308,7 +309,7 @@ (dolist (v *trace-values*) (write-char #\space) (pprint-newline :linear) - (prin1 v))) + (prin1 (ensure-printable-object v)))) (terpri) (trace-print frame (trace-info-print-after info)) (write-sequence (get-output-stream-string *standard-output*) From splittist at yahoo.com Tue Aug 30 18:13:37 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 30 Aug 2005 19:13:37 +0100 Subject: [climacs-devel] Command Tables Message-ID: <4314A1D1.8020108@yahoo.com> Folks, I've just committed a patch reworking the key-binding bits to use esa:set-key instead of the various global-set-key/c-x-set-key forms. The key-bindings for commands are now distributed throughout the code next to the command definitions. (The magic of set-key is that it takes care of prefix (and dead-escape) command tables for you: if you want a command on 'C-x 4 d M-e w' it'll create all the intermediate steps just by specifying '((#\x :control)(#\4)(#\d)(#\e :meta)(#\w)) as the gesture form. Of course, it's your fault if you clobber anything in the process, and God help your users...) At the moment all the keys-bindings are in the global-climacs-table. It is intended that they be partitioned among a logical set of tables that can be composed as desired by ... whoever ends up using bespoke command tables. Some groupings of bindings might be: self-inserted keys; movement; mark-related (C-Space, C-x C-x etc.); deletion; dabbrev ... Your thoughts are requested on such matters! (Also, could people with furrin' keyboards with :dead--acute, :dead--tilde etc. please check that I haven't broken the unicode stuff.) JQS From m.retzlaff at gmx.net Wed Aug 31 02:05:56 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 31 Aug 2005 04:05:56 +0200 Subject: [climacs-devel] a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick Message-ID: <20050831020555.GA31183@mgr.home> Hello, The COMPLETABLE-PATHNAME class This patch mainly removes the class COMPLETABLE-PATHNAME. There is nothing special about those pathnames that make them completable. They are just ordinary pathnames (no offence meant). The only difference to the normal PATHNAME presentation-type is that there are different ACCEPT and PRESENT methods for it. (This ACCEPT offers completion over pathnames, and the PRESENT just calls NAMESTRING on the pathname before presenting it.) This is better done by specialization on the VIEW keyword and not by subclassing PATHNAME. This patch changes Climacs to the former behaviour. The VIEW subclass on which the methods specialize with this patch is CLIMACS-TEXTUAL-VIEW. It has already bean created in pane.lisp but was not yet used anywhere, therefore I just took it. Is it intended for something else that prohibits the use in this context? To be able to use it as a specializer in lambda-lists the variable climacs-pane:+climacs-textual-view+ has been added, it hold an instance of the class climacs-pane:climacs-textual-view, just as there are such variables for the standard view classes (see clim spec 23.6). Both symbols, #:climacs-textual-view and #:+climacs-textual-view+, of the package CLIMACS-PANE are exported. +climacs-textual-view+ is also the :default-view for the class CLIMACS-GUI::CLIMACS-MINIBUFFER-PANE now, so that the aforementioned ACCEPT and PRESENT methods for pathnames are used in the minibuffer. (See at the beginning of gui.lisp.) Is there a special reason why the :DEFAULT-VIEW for the class CLIMACS-PANE:CLIMACS-PANE is not specified in the same way, but in the :AFTER method of (initialize-instance (pane climacs-pane)) via the line: (setf (stream-default-view pane) (make-instance 'climacs-textual-view)) I propose to change this as well, but this patch doesn't do this yet. As the :DEFAULT-VIEW of the minibuffer is now changed, all the calls to (accept 'completable-pathname :prompt "..") are now substituted by just (accept 'pathname :prompt "..") without the need for explicit specification by use of the :VIEW keyword. All these calls are changed, even the one in slidemacs-gui.lisp. We should think about to moving this ACCEPT method for pathnames (or something like it) into the McCLIM code, and making it the default ACCEPT method for the TEXTUAL-VIEW class. Completion for pathnames is always nice, isn't it? While we are at PRESENTing pathames: It would nice if in the climacs-info-pane (aka modeline) the name of the buffer would be presented via something like: (let ((name (name buffer)) (filepath (filepath buffer))) (if filepath (with-output-as-presentation (pane filepath 'pathname) (princ name pane)) (princ name pane))) and not printed in this huge FORMAT of CLIMACS-GUI::DISPLAY-INFO. The function CLIMACS-GUI:CLIMACS I added the keywords NEW-PROCESS and PROCESS-NAME to the lambda-list and the correspondent construct. You can now do (climacs-gui:climacs :new-process t) Just as it is possible with Clouseau and the Climacs-Listener. I think this construct should be provided by McCLIM as an exported macro. I've seen it in the Listener, Clouseau, the Beagle-Backend (in Glimpse), and I use it in my own CLIM applications... Well, this belogs to mcclim-devel. CLIMACS-GUI:CLIMACS is also exported now. Why wasn't it before? Okay, that's all. Only one question left: Why is the variable in the DEFINE-APPLICATION-FRAME form that holds the minibuffer-pane called "int"? What is the meaning of "int"? I don't get it. Bye, Max PS: A gimmick for your entertainment, as you've come to the end of this rather long mail: Substitute +climacs-textual-view+ in the slot :default-view for the class definition of CLIMACS-MINIBUFFER-PANE by +gadget-view+, apply http://bl0rg.net/~mgr/flux/CLIM-Listener.patch to the Clim-Listener in your McCLIM source tree (cd mcclim/Apps/Listener/; patch -p 1 < CLIM-Listener.patch) (will soon be commited), download and load http://bl0rg.net/~mgr/flux/file-selector.lisp (version 1.1!), and fire up FIND FILE in Climacs. You'll get: http://bl0rg.net/~mgr/flux/File-Selector-as-Find-File-of-Climacs.png (I prefer the none gadget-view for the minibuffer, though..) -- Max-Gerd Retzlaff For your amusement: The secret of healthy hitchhiking is to eat junk food. -------------- next part -------------- Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.183 diff -a -u -r1.183 gui.lisp --- gui.lisp 25 Aug 2005 08:43:55 -0000 1.183 +++ gui.lisp 31 Aug 2005 00:30:12 -0000 @@ -47,7 +47,8 @@ (defclass climacs-minibuffer-pane (minibuffer-pane) () (:default-initargs - :height 20 :max-height 20 :min-height 20)) + :height 20 :max-height 20 :min-height 20 + :default-view +climacs-textual-view+)) (defparameter *with-scrollbars* t "If T, classic look and feel. If NIL, stripped-down look (:") @@ -98,11 +99,15 @@ (loop for buffer in buffers do (clear-modify buffer)))) -(defun climacs (&key (width 900) (height 400)) +(defun climacs (&key new-process (process-name "Climacs") + (width 900) (height 400)) "Starts up a climacs session" - (let ((frame (make-application-frame - 'climacs :width width :height height))) - (run-frame-top-level frame))) + (let ((frame (make-application-frame 'climacs :width width :height height))) + (flet ((run () + (run-frame-top-level frame))) + (if new-process + (clim-sys:make-process #'run :name process-name) + (run))))) (defun display-info (frame pane) (declare (ignore frame)) @@ -556,10 +561,6 @@ (possibly-fill-line) (setf (offset point) (offset point-backup))))) -(eval-when (:compile-toplevel :load-toplevel) - (define-presentation-type completable-pathname () - :inherit-from 'pathname)) - (defun filename-completer (so-far mode) (flet ((remove-trail (s) (subseq s 0 (let ((pos (position #\/ s :from-end t))) @@ -628,15 +629,12 @@ collect (list (subseq (namestring name) length nil) name)))))))) -(define-presentation-method present (object (type completable-pathname) - stream (view textual-view) - &key acceptably for-context-type) - (declare (ignore acceptably for-context-type)) +(define-presentation-method present (object (type pathname) + stream (view climacs-textual-view) &key) (princ (namestring object) stream)) -(define-presentation-method accept - ((type completable-pathname) stream (view textual-view) &key (default nil defaultp) - (default-type type)) +(define-presentation-method accept ((type pathname) stream (view climacs-textual-view) + &key (default nil defaultp) (default-type type)) (multiple-value-bind (pathname success string) (complete-input stream #'filename-completer @@ -711,8 +709,7 @@ buffer)))))) (define-named-command com-find-file () - (let* ((filepath (accept 'completable-pathname - :prompt "Find File"))) + (let* ((filepath (accept 'pathname :prompt "Find File"))) (find-file filepath))) (defun find-file-read-only (filepath) @@ -752,7 +749,7 @@ nil))))))) (define-named-command com-find-file-read-only () - (let ((filepath (accept 'completable-pathname :Prompt "Find file read only"))) + (let ((filepath (accept 'pathname :Prompt "Find file read only"))) (find-file-read-only filepath))) (define-named-command com-toggle-read-only () @@ -765,12 +762,11 @@ (needs-saving buffer) t)) (define-named-command com-set-visited-file-name () - (let ((filename (accept 'completable-pathname :prompt "New file name"))) + (let ((filename (accept 'pathname :prompt "New file name"))) (set-visited-file-name filename (buffer (current-window))))) (define-named-command com-insert-file () - (let ((filename (accept 'completable-pathname - :prompt "Insert File")) + (let ((filename (accept 'pathname :prompt "Insert File")) (pane (current-window))) (when (probe-file filename) (setf (mark pane) (clone-mark (point pane) :left)) @@ -818,8 +814,7 @@ (defun save-buffer (buffer) (let ((filepath (or (filepath buffer) - (accept 'completable-pathname - :prompt "Save Buffer to File")))) + (accept 'pathname :prompt "Save Buffer to File")))) (cond ((directory-pathname-p filepath) (display-message "~A is a directory." filepath) @@ -863,8 +858,7 @@ (call-next-method))) (define-named-command com-write-buffer () - (let ((filepath (accept 'completable-pathname - :prompt "Write Buffer to File")) + (let ((filepath (accept 'pathname :prompt "Write Buffer to File")) (buffer (buffer (current-window)))) (cond ((directory-pathname-p filepath) @@ -979,8 +973,7 @@ (beep)))))) (define-named-command com-load-file () - (let ((filepath (accept 'completable-pathname - :prompt "Load File"))) + (let ((filepath (accept 'pathname :prompt "Load File"))) (load-file filepath))) (define-named-command com-beginning-of-buffer () Index: packages.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/packages.lisp,v retrieving revision 1.79 diff -a -u -r1.79 packages.lisp --- packages.lisp 19 Aug 2005 09:12:48 -0000 1.79 +++ packages.lisp 31 Aug 2005 00:30:12 -0000 @@ -157,7 +157,8 @@ #:query-replace-mode #:mark-visible-p #:with-undo - #:url)) + #:url + #:climacs-textual-view #:+climacs-textual-view+)) (defpackage :climacs-fundamental-syntax (:use :clim-lisp :clim :climacs-buffer :climacs-base @@ -197,5 +198,5 @@ (defpackage :climacs-gui (:use :clim-lisp :clim :climacs-buffer :climacs-base :climacs-abbrev :climacs-syntax :climacs-kill-ring :climacs-pane :clim-extensions :undo :esa) - (:import-from :climacs-lisp-syntax :lisp-string)) - + (:import-from :climacs-lisp-syntax :lisp-string) + (:export :climacs)) Index: pane.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/pane.lisp,v retrieving revision 1.31 diff -a -u -r1.31 pane.lisp --- pane.lisp 28 Aug 2005 13:57:33 -0000 1.31 +++ pane.lisp 31 Aug 2005 00:30:13 -0000 @@ -222,6 +222,8 @@ (defclass climacs-textual-view (textual-view tabify-mixin) ()) +(defparameter +climacs-textual-view+ (make-instance 'climacs-textual-view)) + (defclass filepath-mixin () ((filepath :initform nil :accessor filepath))) Index: slidemacs-gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/slidemacs-gui.lisp,v retrieving revision 1.16 diff -a -u -r1.16 slidemacs-gui.lisp --- slidemacs-gui.lisp 22 Jun 2005 18:36:13 -0000 1.16 +++ slidemacs-gui.lisp 31 Aug 2005 00:30:13 -0000 @@ -556,5 +556,5 @@ (if (not (and (typep pane 'climacs-pane) (typep (syntax (buffer pane)) 'slidemacs-gui-syntax))) (beep) - (let ((file (accept 'climacs-gui::completable-pathname :prompt "Output to"))) - (postscript-print-pane pane file))))) \ No newline at end of file + (let ((file (accept 'pathname :prompt "Output to"))) + (postscript-print-pane pane file))))) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Wed Aug 31 06:43:04 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 31 Aug 2005 08:43:04 +0200 Subject: [climacs-devel] a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <20050831020555.GA31183@mgr.home> References: <20050831020555.GA31183@mgr.home> Message-ID: <17173.20856.991601.485894@serveur5.labri.fr> Hello, Max-Gerd Retzlaff writes: > > The COMPLETABLE-PATHNAME class > > This patch mainly removes the class COMPLETABLE-PATHNAME. There is > nothing special about those pathnames that make them completable. They > are just ordinary pathnames (no offence meant). The only difference to > the normal PATHNAME presentation-type is that there are different > ACCEPT and PRESENT methods for it. (This ACCEPT offers completion over > pathnames, and the PRESENT just calls NAMESTRING on the pathname > before presenting it.) > > This is better done by specialization on the VIEW keyword and not > by subclassing PATHNAME. This patch changes Climacs to the former > behaviour. Sounds good to me. > The VIEW subclass on which the methods specialize with this patch is > CLIMACS-TEXTUAL-VIEW. It has already bean created in pane.lisp but was > not yet used anywhere, therefore I just took it. Well done. I think it must have been meant for this kind of situation. > Is it intended for > something else that prohibits the use in this context? I don't thinks so. > To be able to > use it as a specializer in lambda-lists the variable > climacs-pane:+climacs-textual-view+ has been added, it hold an > instance of the class climacs-pane:climacs-textual-view, just as there > are such variables for the standard view classes (see clim spec 23.6). > Both symbols, #:climacs-textual-view and #:+climacs-textual-view+, of > the package CLIMACS-PANE are exported. Again, that sounds good. > +climacs-textual-view+ is also the :default-view for the class > CLIMACS-GUI::CLIMACS-MINIBUFFER-PANE now, so that the aforementioned > ACCEPT and PRESENT methods for pathnames are used in the minibuffer. > (See at the beginning of gui.lisp.) OK > Is there a special reason why the > :DEFAULT-VIEW for the class CLIMACS-PANE:CLIMACS-PANE is not specified > in the same way, but in the :AFTER method of (initialize-instance (pane > climacs-pane)) via the line: > > (setf (stream-default-view pane) (make-instance 'climacs-textual-view)) I would guess ignorance concerning the existence of :default-view > I propose to change this as well, but this patch doesn't do this yet. Please go ahead. > As the :DEFAULT-VIEW of the minibuffer is now changed, all the calls to > (accept 'completable-pathname :prompt "..") > are now substituted by just > (accept 'pathname :prompt "..") > without the need for explicit specification by use of the :VIEW > keyword. All these calls are changed, even the one in > slidemacs-gui.lisp. OK > We should think about to moving this ACCEPT method for pathnames (or > something like it) into the McCLIM code, and making it the default > ACCEPT method for the TEXTUAL-VIEW class. Completion for pathnames is > always nice, isn't it? I agree, yes. > While we are at PRESENTing pathames: It would nice if in the > climacs-info-pane (aka modeline) the name of the buffer would be > presented via something like: > > (let ((name (name buffer)) > (filepath (filepath buffer))) > (if filepath > (with-output-as-presentation (pane filepath 'pathname) > (princ name pane)) > (princ name pane))) > > and not printed in this huge FORMAT of CLIMACS-GUI::DISPLAY-INFO. yes, that would be an improvement. If you have time for that, please go ahead. It looks like you are going to need commit privileges to Climacs as well. I'll contact the cl.net admins. Keep up the good work! > The function CLIMACS-GUI:CLIMACS > > I added the keywords NEW-PROCESS and PROCESS-NAME to the lambda-list > and the correspondent construct. You can now do > (climacs-gui:climacs :new-process t) > Just as it is possible with Clouseau and the Climacs-Listener. Good. Even better would be to define a package CLIMACS so that one could omit the "-gui" in the package name. > I think this construct should be provided by McCLIM as an exported > macro. I've seen it in the Listener, Clouseau, the Beagle-Backend (in > Glimpse), and I use it in my own CLIM applications... Well, this > belogs to mcclim-devel. If you do that, you might want to put it in the clim-extensions package. > CLIMACS-GUI:CLIMACS is also exported now. Why wasn't it before? laziness. > Okay, that's all. Only one question left: Why is the variable in the > DEFINE-APPLICATION-FRAME form that holds the minibuffer-pane called > "int"? What is the meaning of "int"? I don't get it. *blush* it used to be for "interactor". Feel free to rename it. > Bye, > Max > > > PS: A gimmick for your entertainment, as you've come to the end > of this rather long mail: > > Substitute +climacs-textual-view+ in the slot :default-view for the > class definition of CLIMACS-MINIBUFFER-PANE by +gadget-view+, apply > http://bl0rg.net/~mgr/flux/CLIM-Listener.patch > to the Clim-Listener in your McCLIM source tree (cd mcclim/Apps/Listener/; > patch -p 1 < CLIM-Listener.patch) (will soon be commited), download and load > http://bl0rg.net/~mgr/flux/file-selector.lisp > (version 1.1!), and fire up FIND FILE in Climacs. You'll get: > > http://bl0rg.net/~mgr/flux/File-Selector-as-Find-File-of-Climacs.png Neat trick! -- 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 Aug 31 18:46:37 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 31 Aug 2005 19:46:37 +0100 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <17173.20856.991601.485894@serveur5.labri.fr> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> Message-ID: <4315FB0D.5050101@yahoo.com> Robert Strandh wrote: > Max-Gerd Retzlaff writes: > > While we are at PRESENTing pathames: It would nice if in the > > climacs-info-pane (aka modeline) the name of the buffer would be > > presented via something like: > > > > (let ((name (name buffer)) > > (filepath (filepath buffer))) > > (if filepath > > (with-output-as-presentation (pane filepath 'pathname) > > (princ name pane)) > > (princ name pane))) > > > > and not printed in this huge FORMAT of CLIMACS-GUI::DISPLAY-INFO. > > yes, that would be an improvement. If you have time for that, please > go ahead. I was slowly reworking the giant FORMAT so that it could be split up into various functions. In particular, I was about to: (a) have the syntax name given by a call to the syntax (ie. a method specialised on the syntax and buffer, so, eg. lisp-syntax could add the package like slime does); and (b) have the buffer name presented _as_a_buffer_, so we could have interesting and useful things done when one clicked on it. Other things in the info-pane (it would be nice to abolish all uses of the word 'mode' from climacs) could also usefully be presented for clicking (toggling modified status, read only status, auto-fill, overwrite...). Have you (MGR) given thought to how your file-selector could become a Dired application? Or, more modestly, a Bufed for climacs? JQS From strandh at labri.fr Wed Aug 31 20:29:31 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 31 Aug 2005 22:29:31 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <4315FB0D.5050101@yahoo.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> Message-ID: <17174.4907.8432.364494@serveur5.labri.fr> John Q Splittist writes: > I was slowly reworking the giant FORMAT so that it could be split up > into various functions. In particular, I was about to: > > (a) have the syntax name given by a call to the syntax (ie. a method > specialised on the syntax and buffer, so, eg. lisp-syntax could add the > package like slime does); and > > (b) have the buffer name presented _as_a_buffer_, so we could have > interesting and useful things done when one clicked on it. Both sound like good ideas to me. > Other things in the info-pane (it would be nice to abolish all uses of > the word 'mode' from climacs) could also usefully be presented for > clicking (toggling modified status, read only status, auto-fill, > overwrite...). Definitely. Personally, I have only begun to realize the potential of presentation types in Climacs. -- 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 ahefner at gmail.com Wed Aug 31 19:13:51 2005 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 31 Aug 2005 15:13:51 -0400 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <4315FB0D.5050101@yahoo.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> Message-ID: <31ffd3c4050831121332bc372c@mail.gmail.com> Isn't the prevailing bias of the climacs project anti-dired? On 8/31/05, John Q Splittist wrote: > Have you (MGR) given thought to how your file-selector could become a > Dired application? Or, more modestly, a Bufed for climacs?