From strandh at labri.fr Sun Jan 1 00:14:31 2006 From: strandh at labri.fr (Robert Strandh) Date: Sun, 1 Jan 2006 01:14:31 +0100 Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings In-Reply-To: <43B6EB3E.4000905@yahoo.com> References: <43B3BB46.8010807@yahoo.com> <43B64C87.8090202@yahoo.com> <17334.55700.645758.226250@serveur5.labri.fr> <43B6EB3E.4000905@yahoo.com> Message-ID: <17335.7911.830490.830431@serveur5.labri.fr> John Q Splittist writes: > > (a) "An implementation is permitted to discard documentation strings at > any time for implementation-defined reasons." and Fair enough. Do we know of any implementation we care about that does that? > (b) Having our own mechanism allows us to do what Brian suggested, and > have a function that knows how to render the information onto a given > pane/stream (we might what to throw an &allow-other-keys in there > somewhere, too). OK, 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 Sun Jan 1 00:15:14 2006 From: strandh at labri.fr (Robert Strandh) Date: Sun, 1 Jan 2006 01:15:14 +0100 Subject: [climacs-devel] More ideas for gardeners In-Reply-To: <20051231210511.66965.qmail@web34602.mail.mud.yahoo.com> References: <20051231111321.A24792@eskimo.com> <20051231210511.66965.qmail@web34602.mail.mud.yahoo.com> Message-ID: <17335.7954.432100.77537@serveur5.labri.fr> Aleksandar Bakic writes: > Hi all, > Hello Alex, and a happy new year to you too. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From amoroso at mclink.it Mon Jan 2 15:33:08 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 02 Jan 2006 16:33:08 +0100 Subject: [climacs-devel] Making Climacs ASDF-INSTALLable Message-ID: <87vex2hcgb.fsf@plato.moon.paoloamoroso.it> What about making Climacs ASDF-INSTALLable? This CLiki page explains how to do it (see section "Making your package downloadable with asdf-install"): http://www.cliki.net/asdf-install In the case of Climacs, step #1 would involve making available a tarball with the latest CVS snapshot at a fixed location. Also, ASDF-INSTALL requires that all .asd files be in the toplevel directory of the source tree. It would be necessary to move cl-automaton/automaton.asd up one level, or add the `automaton' system definition to climacs.asd (I can provide such changes if there is interest). As for step #4, Climacs already has a CLiki page. More importantly, it would also be necessary to make Flexichain ASDF-INSTALLABLE. Flexichain already has the required .asd file at the proper place. But the library is currently a Gsharp CVS module and it would be necessary--and useful in itself--to distribute it independently, and provide a tarball at a web site. The CLiki page is already in place. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From strandh at labri.fr Mon Jan 2 18:24:03 2006 From: strandh at labri.fr (Robert Strandh) Date: Mon, 2 Jan 2006 19:24:03 +0100 Subject: [climacs-devel] Making Climacs ASDF-INSTALLable In-Reply-To: <87vex2hcgb.fsf@plato.moon.paoloamoroso.it> References: <87vex2hcgb.fsf@plato.moon.paoloamoroso.it> Message-ID: <17337.28611.407624.593350@serveur5.labri.fr> Hello Paolo, Paolo Amoroso writes: > What about making Climacs ASDF-INSTALLable? Sure. > In the case of Climacs, step #1 would involve making available a > tarball with the latest CVS snapshot at a fixed location. That seems fairly straightforward. > Also, ASDF-INSTALL requires that all .asd files be in the toplevel > directory of the source tree. It would be necessary to move > cl-automaton/automaton.asd up one level, or add the `automaton' system > definition to climacs.asd (I can provide such changes if there is > interest). I'll let Alex decide what is more appropriate. cl-automaton is large enough that it might merit its own system and cl.net project. > More importantly, it would also be necessary to make Flexichain > ASDF-INSTALLABLE. Flexichain already has the required .asd file at > the proper place. But the library is currently a Gsharp CVS module > and it would be necessary--and useful in itself--to distribute it > independently, and provide a tarball at a web site. The CLiki page is > already in place. Yes, I am now convinced that Flexichain should have its own cl.net project. It is even better if it is asdf-installable as well. If anyone creates such a project, I would like to have commit privileges as well. -- 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 Mon Jan 2 19:10:36 2006 From: strandh at labri.fr (Robert Strandh) Date: Mon, 2 Jan 2006 20:10:36 +0100 Subject: [climacs-devel] Making Climacs ASDF-INSTALLable In-Reply-To: <17337.28611.407624.593350@serveur5.labri.fr> References: <87vex2hcgb.fsf@plato.moon.paoloamoroso.it> <17337.28611.407624.593350@serveur5.labri.fr> Message-ID: <17337.31404.778859.884247@serveur5.labri.fr> Robert Strandh writes: > Yes, I am now convinced that Flexichain should have its own cl.net > project. It is even better if it is asdf-installable as well. If > anyone creates such a project, I would like to have commit privileges > as well. I am pleased to announce that Marty Kreuter (kreuter at progn.net) has accepted to create a cl.net project for Flexichain and to make it asdf-installable. Thanks Marty! -- 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 Tue Jan 3 00:20:42 2006 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Mon, 2 Jan 2006 16:20:42 -0800 (PST) Subject: [climacs-devel] Making Climacs ASDF-INSTALLable In-Reply-To: <17337.28611.407624.593350@serveur5.labri.fr> Message-ID: <20060103002042.5257.qmail@web34605.mail.mud.yahoo.com> > > Also, ASDF-INSTALL requires that all .asd files be in the toplevel > > directory of the source tree. It would be necessary to move > > cl-automaton/automaton.asd up one level, or add the `automaton' system > > definition to climacs.asd (I can provide such changes if there is > > interest). > > I'll let Alex decide what is more appropriate. cl-automaton is large > enough that it might merit its own system and cl.net project. At the moment, to work around the problem, either of the above options is fine with me. Alex __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From amoroso at mclink.it Tue Jan 3 13:43:30 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 03 Jan 2006 14:43:30 +0100 Subject: [climacs-devel] Making Climacs ASDF-INSTALLable In-Reply-To: <20060103002042.5257.qmail@web34605.mail.mud.yahoo.com> (Aleksandar Bakic's message of "Mon, 2 Jan 2006 16:20:42 -0800 (PST)") References: <20060103002042.5257.qmail@web34605.mail.mud.yahoo.com> Message-ID: <871wzpjukd.fsf@plato.moon.paoloamoroso.it> Aleksandar Bakic writes: >> > Also, ASDF-INSTALL requires that all .asd files be in the toplevel >> > directory of the source tree. It would be necessary to move >> > cl-automaton/automaton.asd up one level, or add the `automaton' system >> > definition to climacs.asd (I can provide such changes if there is >> > interest). >> >> I'll let Alex decide what is more appropriate. cl-automaton is large >> enough that it might merit its own system and cl.net project. > > At the moment, to work around the problem, either of the above options is fine > with me. In case it's useful, I include below an automaton.asd file modified in the hypothesis that it is kept in the toplevel directory of the Climacs source tree. If cl-automaton is distributed as a separate system, its current automaton.asd can be used as is. I have also added a package definition for the automaton system. Paolo ----------------------------------------------------------------- ;;; -*- mode: lisp -*- ;;; ;;; (c) copyright 2005 by Aleksandar Bakic (a_bakic at yahoo.com) ;;; (defpackage #:automaton-system (:use #:common-lisp #:asdf)) (in-package #:automaton-system) (defsystem #:automaton :depends-on ("rt") :pathname (merge-pathnames (make-pathname :directory '(:relative "cl-automaton")) (make-pathname :directory (pathname-directory (pathname *load-truename*)))) :components ((:file "automaton-package") (:file "eqv-hash" :depends-on ("automaton-package")) (:file "state-and-transition" :depends-on ("eqv-hash")) (:file "automaton" :depends-on ("state-and-transition" "eqv-hash")) (:file "regexp" :depends-on ("automaton")))) ----------------------------------------------------------------- -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From nicolas.sceaux at free.fr Thu Jan 5 21:57:07 2006 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Thu, 05 Jan 2006 22:57:07 +0100 Subject: [climacs-devel] grammar definition Message-ID: Hello, I've been experimenting a bit with various ways of defining a grammar like lisp-syntax' one for the LR parser, but I'm not really satisfied and I'm sure gurus here have some better thoughts about it. (define-grammar lisp-syntax (some options) ;; Expand to define-parser-state ;; ( => ) ;; Expand to define-new-parser-state: ;; ( => ) ;; Expand to defclass of nonterminals: ;; ( -> ) ;; Expand to define-action: ;; ( -> ) ;;;;;;; List (form -> list-form) (list-form -> complete-list-form) (complete-list-form -> |( form* ) | t :reduce-until-type left-parenthesis-lexeme) (lexer-list-state => |( form* |) (form-may-follow => |( form* |) (parser-state => |( form* ) |) (lexer-toplevel-state => |( form* ) |) (|( form* | => form-may-follow left-parenthesis-lexeme) (|( form* | => |( form* | form) (|( form* | => |( form* | comment) (|( form* ) | => |( form* | right-parenthesis-lexeme) (list-form -> incomplete-list-form) (incomplete-form-mixin -> incomplete-list-form) (incomplete-list-form -> |( form* | nil :reduce-until-type left-parenthesis-lexeme)) But I'm not sure what kind of utility people expect. I'd be glad to be put on the right track. nicolas From nicolas.sceaux at free.fr Sat Jan 7 14:53:26 2006 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Sat, 07 Jan 2006 15:53:26 +0100 Subject: [climacs-devel] grammar definition In-Reply-To: (Nicolas Sceaux's message of "Thu, 05 Jan 2006 22:57:07 +0100") References: Message-ID: Nicolas Sceaux writes: > Hello, > > I've been experimenting a bit with various ways of defining a grammar > like lisp-syntax' one for the LR parser, but I'm not really satisfied and > I'm sure gurus here have some better thoughts about it. Here is a patch where this DEFINE-GRAMMAR macro is implemented and called in lisp-syntax.lisp. Some parts are not really neat, particularly the way (throw 'done nil) actions are defined, or parser-state inheritance declarations... Suggestions and comments are most welcome. nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: lr.patch Type: text/x-patch Size: 47356 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lr-syntax.lisp URL: From athas at sigkill.dk Tue Jan 10 22:08:56 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 10 Jan 2006 23:08:56 +0100 Subject: [climacs-devel] Unicode support in Climacs Message-ID: <871wzfspl3.fsf@sigkill.dk> Being Danish, I care a lot about being able to use Danish special characters (??????) in a text editor. Some of you may have seen my posts about Unicode-support in McCLIM on mcclim-devel, but it turned out that the hack I used did not work in Climacs. As far as I can see, Climacs' Unicode-support lives in unicode-commands.lisp. I have attached a patch permitting the use of Danish special characters (and only those, this patch is meant as a demonstration) in Climacs, provided you have enabled them in McCLIM, for example using the method outlined at the bottom of http://mcclim.cliki.net/Tip. The fix involved removing parts of the gesture (for example "(:dead--tilde :shift)") and replacing the (placeholder?) character with the true Unicode character. Would this method used on all characters listed in unicode-commands.lisp be a proper solution, or does my approach break something else? If this is really the proper way to go, then the hardest part will be tracking down the characters to put in the file. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode-commands.lisp.patch Type: text/x-patch Size: 2257 bytes Desc: not available URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From athas at sigkill.dk Wed Jan 11 20:05:32 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 11 Jan 2006 21:05:32 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <871wzfspl3.fsf@sigkill.dk> (Troels Henriksen's message of "Tue, 10 Jan 2006 23:08:56 +0100") References: <871wzfspl3.fsf@sigkill.dk> Message-ID: <87zmm24jjn.fsf@sigkill.dk> Troels Henriksen writes: > The fix involved removing parts of the gesture (for example > "(:dead--tilde :shift)") and replacing the (placeholder?) character > with the true Unicode character. I just found another way to do it. Apparently, once the special characters have been enabled in CLX, they can be added as keystrokes for Climacs' `com-self-insert'-command: (loop for code in '(230 198 248 216 229 197) do ;; The charcodes fpr ??????. (esa::set-key `(climacs-gui::com-self-insert ,clim::*numeric-argument-marker*) 'climacs-gui::self-insert-table (list (list (code-char code))))) gui.lisp contains a loop that loops across all ASCII characters and register them as keystrokes to `com-self-insert', but country-specific characters are left out. This approach is probably cleaner than mucking around in unicode-commands.lisp, at least until an official solution has been developed. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From strandh at labri.fr Thu Jan 12 02:28:22 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 12 Jan 2006 03:28:22 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <87zmm24jjn.fsf@sigkill.dk> References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> Message-ID: <17349.48838.229859.969658@serveur5.labri.fr> > > The fix involved removing parts of the gesture (for example > > "(:dead--tilde :shift)") and replacing the (placeholder?) character > > with the true Unicode character.=20 > > I just found another way to do it. Apparently, once the special > characters have been enabled in CLX, they can be added as keystrokes > for Climacs' `com-self-insert'-command: > > (loop for code in '(230 198 248 216 229 197) do ;; ... > (esa::set-key `(climacs-gui::com-self-insert ,clim::*numeric-argument-marker*) > 'climacs-gui::self-insert-table > (list (list (code-char code))))) > > gui.lisp contains a loop that loops across all ASCII characters and > register them as keystrokes to `com-self-insert', but country-specific > characters are left out. > > This approach is probably cleaner than mucking around in > unicode-commands.lisp, at least until an official solution has been > developed. Right. Your second approach is valid when what comes from X is a real Unicode character, for instance, if you already have a keyboard that generates those characters. The first one is valid when you use a keyboard with dead keys. The two approaches are complementary and can be used simultaneously. In fact, it would be better if Climacs would systematically test for real Unicode characters as opposed to having them entered explicitly. The problem is, I am not sure how to test that. Perhaps everything above 127 with only a Shift modifier is such a real Unicode character? -- 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 Thu Jan 12 05:18:00 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 12 Jan 2006 06:18:00 +0100 Subject: [climacs-devel] grammar definition In-Reply-To: References: Message-ID: <17349.59016.550160.748669@serveur5.labri.fr> Hello Nicolas, Sorry about the late answer. I am trying to cope with some email backlog, and I am now just staring to catch up. Nicolas Sceaux writes: > > I've been experimenting a bit with various ways of defining a grammar > like lisp-syntax' one for the LR parser, but I'm not really satisfied and > I'm sure gurus here have some better thoughts about it. > > (define-grammar lisp-syntax (some options) You may want to start with a protocol (in the sense of Keene) for manipulating grammars; then you can define syntax to simplify common cases. For instance, you most likely would want the grammar to be able to evolve programmatically. There should be some examples of `add-rule' in the other syntax modules that show this idea. > ;; Expand to define-parser-state > ;; ( => ) > > ;; Expand to define-new-parser-state: > ;; ( => ) > > ;; Expand to defclass of nonterminals: > ;; ( -> ) > > ;; Expand to define-action: > ;; ( -> ) > > ;;;;;;; List > (form -> list-form) > (list-form -> complete-list-form) > (complete-list-form -> |( form* ) | t > :reduce-until-type left-parenthesis-lexeme) > > (lexer-list-state => |( form* |) > (form-may-follow => |( form* |) > (parser-state => |( form* ) |) > (lexer-toplevel-state => |( form* ) |) > (|( form* | => form-may-follow left-parenthesis-lexeme) > (|( form* | => |( form* | form) > (|( form* | => |( form* | comment) > (|( form* ) | => |( form* | right-parenthesis-lexeme) > > (list-form -> incomplete-list-form) > (incomplete-form-mixin -> incomplete-list-form) > (incomplete-list-form -> |( form* | nil > :reduce-until-type left-parenthesis-lexeme)) > > But I'm not sure what kind of utility people expect. I'd be glad to be > put on the right track. I am actually not too sure myself what to do about this, and I am not sure I follow your notation. On the one hand, there is standard notation for specifying grammar rules (that are pretty much followed in the syntax modules that use the Earley parser, but it has been extended). On the other hand, that notation does not allow for specifying lexer states and parser states. Perhaps a compromise would be to specify a rule pretty much the standard way, but to allow for a state name to be inserted between two parser symbols, for instance: (list -> left-parenthesis-lexeme {the-state-we-want-to-be-in} ...) or something like that. This kind of practice will sometimes create conflicts when you submit such rules to an LR parser generator. For that reason, I would like to use a Tomita parser instead, which can deal with such conflicts. Again, on the other hand, I don't know how to make a Tomita parser incremental, but I guess it is a straightforward (albeit messy) extension of the incremental LR algorithm. I am sorry that I can't be of much more help here and now. Parsing is still an important issue that is on my back burner (and I have a near-finished implementation of a Tomita parser), but I make very slow progress. 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 athas at sigkill.dk Thu Jan 12 14:55:35 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 12 Jan 2006 15:55:35 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <17349.48838.229859.969658@serveur5.labri.fr> (Robert Strandh's message of "Thu, 12 Jan 2006 03:28:22 +0100") References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> Message-ID: <87ek3d4hso.fsf@sigkill.dk> Robert Strandh writes: > In fact, it would be better if Climacs would systematically test for > real Unicode characters as opposed to having them entered explicitly. > The problem is, I am not sure how to test that. Perhaps everything > above 127 with only a Shift modifier is such a real Unicode > character? How does other programs handle it? One obvious, if rather crude and non-scaleable, method would be to have a long file containing calls to `set-key' for each relevant Unicode character. Registering *every* possible Unicode character as possible input would probably be immense overkill, especially since there are so many of them. I find it most important to support the range of characters defined in ISO-8859-1, since they are the ones most likely to be used. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From jch.helary at free.fr Thu Jan 12 15:33:43 2006 From: jch.helary at free.fr (JC Helary) Date: Fri, 13 Jan 2006 00:33:43 +0900 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <87ek3d4hso.fsf@sigkill.dk> References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> <87ek3d4hso.fsf@sigkill.dk> Message-ID: > overkill, especially since there are so many of them. I find it most > important to support the range of characters defined in ISO-8859-1, > since they are the ones most likely to be used. :) I type in Japanese all day, as well as French, and English, and I can tell you that in 2006, any text editor that does not support Unicode for at least the 10 biggest languages in the world is not going to go very far. And that has to be intuitive too. If possible with no need to set obscure parameters hidden in the GUI (a la Mule), with no need to install separate input systems (a la X11) etc. Everything from input to display to file saving/opening has to be relatively smooth otherwise the application is useless. I read somewhere that the only Common Lisp that supports Unicode fully is CLISP, it is a pity the other are either not "compliant" or default on latin-1. It is about time people understand that "text" in "text editor" is not anymore synonymous with "ascii"... :) Regards, Jean-Christophe Helary From athas at sigkill.dk Thu Jan 12 16:32:04 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 12 Jan 2006 17:32:04 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: (JC Helary's message of "Fri, 13 Jan 2006 00:33:43 +0900") References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> <87ek3d4hso.fsf@sigkill.dk> Message-ID: <878xtl4dbv.fsf@sigkill.dk> JC Helary writes: > I type in Japanese all day, as well as French, and English, and I can > tell you that in 2006, any text editor that does not support Unicode > for at least the 10 biggest languages in the world is not going to go > very far. Of course support for the characters defined in ISO-8859-1 is not the optimal solution, but it is probably what would bring the most value for the least effort. Some major languages require exotic mechanisms such as sophisticated font handling and bidirectional input, features that are quite a bit more difficult to implement than the western European characters. > Everything from input to display to file saving/opening has to be > relatively smooth otherwise the application is useless. I agree completely, no-one should have to care about character sets anymore (apart from implementors obviously). > I read somewhere that the only Common Lisp that supports Unicode > fully is CLISP, it is a pity the other are either not "compliant" or > default on latin-1. Is there any work ongoing to solve this issue? I am afraid that task is quite beyond my own abilities at this point. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From jch.helary at free.fr Thu Jan 12 16:59:46 2006 From: jch.helary at free.fr (JC Helary) Date: Fri, 13 Jan 2006 01:59:46 +0900 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <878xtl4dbv.fsf@sigkill.dk> References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> <87ek3d4hso.fsf@sigkill.dk> <878xtl4dbv.fsf@sigkill.dk> Message-ID: <804AD4C7-8C2E-4F02-8EE0-4D429AE0DA11@free.fr> Troels, Thank you for your answer. > for the least effort. Some major languages require exotic mechanisms > such as sophisticated font handling and bidirectional input, features > that are quite a bit more difficult to implement than the western > European characters. Definitely, especially when it is about re-inventing the wheel in common lisp ;) Kidding set aside, input can be handled on the X11 side and display in the terminal side, so what really matters is proper handling of at least one character set big enough that a lot of people are happy. Plus, if you want to appeal to non latin developers... >> I read somewhere that the only Common Lisp that supports Unicode >> fully is CLISP, it is a pity the other are either not "compliant" or >> default on latin-1. > > Is there any work ongoing to solve this issue? I am afraid that task > is quite beyond my own abilities at this point. I have no idea. I am struggling with Emacs on OSX to get a reasonably satisfying default behavior... Sorry, I can't help... Jean-Christophe From strandh at labri.fr Thu Jan 12 17:13:00 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 12 Jan 2006 18:13:00 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <87ek3d4hso.fsf@sigkill.dk> References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> <87ek3d4hso.fsf@sigkill.dk> Message-ID: <17350.36380.846609.30210@serveur5.labri.fr> Troels Henriksen writes: > Robert Strandh writes: > > > In fact, it would be better if Climacs would systematically test for > > real Unicode characters as opposed to having them entered explicitly. > > The problem is, I am not sure how to test that. Perhaps everything > > above 127 with only a Shift modifier is such a real Unicode > > character? > > How does other programs handle it? One obvious, if rather crude and > non-scaleable, method would be to have a long file containing calls to > `set-key' for each relevant Unicode character. Registering *every* > possible Unicode character as possible input would probably be immense > overkill, especially since there are so many of them. I find it most > important to support the range of characters defined in ISO-8859-1, > since they are the ones most likely to be used. I think my suggested solution is better: any character that does not have an explicit key binding and that has no modifier other than shift could be inserted. That way, we will automatically handle any code points that might come along. -- 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 Thu Jan 12 17:43:48 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 12 Jan 2006 18:43:48 +0100 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: References: <871wzfspl3.fsf@sigkill.dk> <87zmm24jjn.fsf@sigkill.dk> <17349.48838.229859.969658@serveur5.labri.fr> <87ek3d4hso.fsf@sigkill.dk> Message-ID: <17350.38228.264431.817196@serveur5.labri.fr> JC Helary writes: > tell you that in 2006, any text editor that does not support Unicode > for at least the 10 biggest languages in the world is not going to go > very far. > > And that has to be intuitive too. If possible with no need to set > obscure parameters hidden in the GUI (a la Mule), with no need to > install separate input systems (a la X11) etc. There are two cases, one easy and one hard. The easy one is when the keyboard and X11 are configured to send the right events. Then, all Climacs has to do is insert the corresponding Unicode character. The hard one is when you need to type characters that do not appeaar on your keyboard. In my opinion, though, this should not be dealt with at the level of Climacs, but globally in CLIM, or perhaps the X11 backend, or even by X11 itself (for consistency between applications). > Everything from input to display to file saving/opening has to be > relatively smooth otherwise the application is useless. > > I read somewhere that the only Common Lisp that supports Unicode > fully is CLISP, it is a pity the other are either not "compliant" or > default on latin-1. I think SBCL fully supports Unicode as well. > It is about time people understand that "text" in "text editor" is > not anymore synonymous with "ascii"... :) I agree. It was for that reason Climacs was designed from the start so that the buffer can contain any Unicode character, and in fact, any CL object. -- 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 dcaune at majormode.com Sat Jan 14 05:17:37 2006 From: dcaune at majormode.com (Daniel CAUNE) Date: Sat, 14 Jan 2006 00:17:37 -0500 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <17350.38228.264431.817196@serveur5.labri.fr> Message-ID: <0IT0005E9MPENZB0@VL-MO-MR004.ip.videotron.ca> > JC Helary writes: > > tell you that in 2006, any text editor that does not support Unicode > > for at least the 10 biggest languages in the world is not going to go > > very far. > > > > And that has to be intuitive too. If possible with no need to set > > obscure parameters hidden in the GUI (a la Mule), with no need to > > install separate input systems (a la X11) etc. > > There are two cases, one easy and one hard. The easy one is when the > keyboard and X11 are configured to send the right events. Then, all > Climacs has to do is insert the corresponding Unicode character. The > hard one is when you need to type characters that do not appeaar on > your keyboard. In my opinion, though, this should not be dealt with > at the level of Climacs, but globally in CLIM, or perhaps the X11 > backend, or even by X11 itself (for consistency between > applications). > Yes, I think you are right. For instance, such a keyboard abstraction, aka Input Method Editor (IME), is integrated in operating systems such as Windows and MacOS X. Translation from scan code tuples to Unicode characters are hidden to the GUI developer (not sure for the Windows developer!). > > Everything from input to display to file saving/opening has to be > > relatively smooth otherwise the application is useless. > > > > I read somewhere that the only Common Lisp that supports Unicode > > fully is CLISP, it is a pity the other are either not "compliant" or > > default on latin-1. > > I think SBCL fully supports Unicode as well. > SBCL supports Unicode characters, but I don't know so far whether SBCL is fully compliant with Unicode standard (Java is not, for instance). But is that a big deal? Full compliance can be managed by Climacs itself for the moment. > > It is about time people understand that "text" in "text editor" is > > not anymore synonymous with "ascii"... :) > > I agree. It was for that reason Climacs was designed from the start > so that the buffer can contain any Unicode character, and in fact, any > CL object. > My next comment might be a bit out of purpose. Anyway it could be interesting to have the identification of the language stored within the character, or, more specifically, any identification of the IME used to enter that character. For which usage would it be interesting? Spelling purpose, automatic IME switch when character cursor moves around, text search, etc.. I have no clear idea if such information should be managed by the character layer (buffer layer?), or by any other higher text layer. Just my two cents. -- Daniel CAUNE From jch.helary at free.fr Fri Jan 13 08:52:22 2006 From: jch.helary at free.fr (JC Helary) Date: Fri, 13 Jan 2006 17:52:22 +0900 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <0IT0005E9MPENZB0@VL-MO-MR004.ip.videotron.ca> References: <0IT0005E9MPENZB0@VL-MO-MR004.ip.videotron.ca> Message-ID: <56E44C89-6627-49C0-BADE-A4AAD89E4B8E@free.fr> On 2006/01/14, at 14:17, Daniel CAUNE wrote: > My next comment might be a bit out of purpose. Anyway it could be > interesting to have the identification of the language stored > within the character, or, more specifically, any identification of > the IME used to enter that character. For which usage would it be > interesting? Spelling purpose, automatic IME switch when character > cursor moves around, text search, etc.. I have no clear idea if > such information should be managed by the character layer (buffer > layer?), or by any other higher text layer. Just my two cents. In the case of CJK languages that would not be practical since the Han unification makes in difficult to identify whether a character is Chinese/Japanese or Korean. I think Unicode takes automatically care of that since languages are pretty much grouped in planes so a character belonging to a plane is very likely to correspond to a specific language/language group/input mechanism etc. I am not at all a unicode specialist so that has to be confirmed (the unicode at unicode.org list is the perfect place for that if necessary). Jean-Christophe Helary From dcaune at majormode.com Sat Jan 14 13:05:16 2006 From: dcaune at majormode.com (Daniel CAUNE) Date: Sat, 14 Jan 2006 08:05:16 -0500 Subject: [climacs-devel] Unicode support in Climacs In-Reply-To: <56E44C89-6627-49C0-BADE-A4AAD89E4B8E@free.fr> Message-ID: <0IT10034O8CTDYB0@VL-MO-MR003.ip.videotron.ca> > > My next comment might be a bit out of purpose. Anyway it could be > > interesting to have the identification of the language stored > > within the character, or, more specifically, any identification of > > the IME used to enter that character. For which usage would it be > > interesting? Spelling purpose, automatic IME switch when character > > cursor moves around, text search, etc.. I have no clear idea if > > such information should be managed by the character layer (buffer > > layer?), or by any other higher text layer. Just my two cents. > > In the case of CJK languages that would not be practical since the > Han unification makes in difficult to identify whether a character is > Chinese/Japanese or Korean. You said it. It's difficult to identify the language which a character corresponds to (cf. Latin based scripts such as English French, Spanish, Vietnamese, and so on). But if you have that information, i.e. whatever identification of the IME used when that character was entered, you will be able to differentiate those languages and adapt the context to the current character. > I think Unicode takes automatically care of that since languages are > pretty much grouped in planes so a character belonging to a plane is > very likely to correspond to a specific language/language group/input > mechanism etc. > Actually several languages share some same planes as the Latin script based languages. For instance Vietnamese takes its characters from 5 different planes. -- Daniel CAUNE From nicolas.sceaux at free.fr Fri Jan 13 17:50:12 2006 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Fri, 13 Jan 2006 18:50:12 +0100 Subject: [climacs-devel] grammar definition In-Reply-To: <17349.59016.550160.748669@serveur5.labri.fr> (Robert Strandh's message of "Thu, 12 Jan 2006 06:18:00 +0100") References: <17349.59016.550160.748669@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Perhaps a compromise would be to specify a rule pretty much the > standard way, but to allow for a state name to be inserted between two > parser symbols, for instance: > > (list -> left-parenthesis-lexeme {the-state-we-want-to-be-in} ...) > > or something like that. > > This kind of practice will sometimes create conflicts when you submit > such rules to an LR parser generator. For that reason, I would like > to use a Tomita parser instead, which can deal with such conflicts. > Again, on the other hand, I don't know how to make a Tomita parser > incremental, but I guess it is a straightforward (albeit messy) > extension of the incremental LR algorithm. > > I am sorry that I can't be of much more help here and now. Parsing is > still an important issue that is on my back burner (and I have a > near-finished implementation of a Tomita parser), but I make very slow > progress. Thank you for your answer. I'll experiment with defining rules the way you sketched in your message with the current LR parser implementation. Even if it's going nowhere, it's still interesting (to me), and I'll report progress, if any. Best regards, nicolas From strandh at labri.fr Fri Jan 13 19:23:37 2006 From: strandh at labri.fr (Robert Strandh) Date: Fri, 13 Jan 2006 20:23:37 +0100 Subject: [climacs-devel] grammar definition In-Reply-To: References: <17349.59016.550160.748669@serveur5.labri.fr> Message-ID: <17351.65081.523918.755392@serveur5.labri.fr> Nicolas Sceaux writes: > Thank you for your answer. I'll experiment with defining rules the way > you sketched in your message with the current LR parser implementation. > Even if it's going nowhere, it's still interesting (to me), and I'll > report progress, if any. Yes, definitely let us know about any progress. -- 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 Jan 17 10:21:29 2006 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 17 Jan 2006 10:21:29 +0000 (UTC) Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings References: <43B3BB46.8010807@yahoo.com> <43B64C87.8090202@yahoo.com> <17334.55700.645758.226250@serveur5.labri.fr> <43B6EB3E.4000905@yahoo.com> <17335.7911.830490.830431@serveur5.labri.fr> Message-ID: Robert Strandh labri.fr> writes: > > (a) "An implementation is permitted to discard documentation strings at > > any time for implementation-defined reasons." and > > Do we know of any implementation we care about that does > that? Having done a super-quick test, no. So, to summarise this discussion: * An interesting thing to do would be to provide commands with documenting functions, that would know how to render themselves onto a supplied stream/view. This would allow for maximum flexibility and the use of the full power of the clim system (text styles, presentations etc). * In the mean time, just adding a docstring to the define-command form works. Creighton, as Robert suggested, the best thing is probably to send diffs to this list. That way people will have their chance of editorial intervention prior to my (or Robert) committing them (a chance they will have to be quick to grasp...). JQS From athas at sigkill.dk Tue Jan 17 17:27:10 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 17 Jan 2006 18:27:10 +0100 Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings In-Reply-To: (John Q. Splittist's message of "Tue, 17 Jan 2006 10:21:29 +0000 (UTC)") References: <43B3BB46.8010807@yahoo.com> <43B64C87.8090202@yahoo.com> <17334.55700.645758.226250@serveur5.labri.fr> <43B6EB3E.4000905@yahoo.com> <17335.7911.830490.830431@serveur5.labri.fr> Message-ID: <87d5iq3gup.fsf@sigkill.dk> John Q Splittist writes: > * In the mean time, just adding a docstring to the define-command > form works. I think I can do this as well (and for the record, I believe that using, or improving, CLIM's own documentation system is the best approach). -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From splittist at yahoo.com Tue Jan 17 12:00:42 2006 From: splittist at yahoo.com (John Q) Date: Tue, 17 Jan 2006 04:00:42 -0800 (PST) Subject: [climacs-devel] Latest Progress Message-ID: <20060117120043.6912.qmail@web33510.mail.mud.yahoo.com> Dear list-members, This is the semi-annual [ahem - must do better...] update on progress for those who don't follow climacs-cvs closely. Since the last report there have been a number of developments, not the least of which are reports of actual users who are not also climacs developers. This has come about partly as a result of Dwight Holman's clim-desktop project, which enables users to build an image containing an integrated set of clim-based applications, including, of course, climacs. The other parts of clim-desktop are Clouseau (an inspector), the Listener, a debugger, Closure (a web browser), Beirc (an IRC client) and Swine, which extends climacs to use swank (the Slime backend) to provide some slime-like functionality. Clim-desktop adds the following commands and functionality: Eval Last Expression C-c C-e Macroexpand 1 C-c C-m Macroexpand All C-c M-m Eval Region C-c C-r Compile Definition C-c C-c Compile And Load File C-c C-k Compile File C-c M-k Edit Definition M-. Return From Definition M-, (together with compiler note and cross reference display and navigation) Hyperspec Lookup C-c C-d h (using Closure) Arglist Lookup C-c C-d a Swine Completion M-Tab Swine Fuzzy Completion C-c M-i (arglists shown in minibuffer on #\Space) Inspect Buffer C-c C-d C-b Inspect Window C-c C-d C-w (using Clouseau) And, of course, COMMON-LISP:ED will open climacs! Other user-visible changes to climacs include: * Mouse left-click positions the cursor, right-click copies, and middle-click pastes * Describe Key Briefly C-h c, Where Is C-h w, Describe Bindings C-h b * Splitting and resizing windows is prettier (Dwight Holman again) * The package of a lisp file is detected and displayed in the info-pane * The beginnings of a User Manual (Robert Strandh) And Marcus Pearce has added significant functionality by tying together Christophe Rhodes' prolog-sytax to his (Christophe's) paiprolog, an expansion and ISOfication of the sexp-based Prolog from Norvig's 'Paradigms of Artificial Intelligence Programming' (PAIP). Behind the scenes there was a proliferation of command-tables and command-containing files, Christophe and David Lewis helped implement per-syntax commands, and Max-Gerd Retzlaff tidied up some pathname and pane-naming issues. In terms of infrastructure, the refactoring of certain functionality into the ESA ('Emacs Style Application') system seems to have worked, with ESA now being used in Gsharp and newcomer Ftd; Aleksandar Bakic (with the assistance of Derek Peschel) continued his work on cl-automaton. As to future directions Creighton Hogg will be progressively adding documentation to the commands in-program, and Nicholas Sceaux is working on the abstraction of the LR-parser functionality used in lisp-syntax. So this announcement marks the point at which climacs became genuinely useful to lisp developers: Robert reports that developing Gsharp in climacs (using clim-desktop) is a real pleasure, not least because, being lisp all the way down, nits in the development environment are only a M-., edit and C-c C-c away from being fixed. There is still a long way to go (and it is the essence of a programmable development environment that it is never finished), but future is looking good. Best regards, JQS __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From root at common-lisp.net Wed Jan 18 16:23:21 2006 From: root at common-lisp.net (root) Date: Wed, 18 Jan 2006 10:23:21 -0600 (CST) Subject: [climacs-devel] Auto-nag: climacs link verifier failed Message-ID: <20060118162321.6BA4AE0E8@common-lisp.net> You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at admin at common-lisp.net Thanks! From splittist at yahoo.com Wed Jan 18 20:51:18 2006 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 18 Jan 2006 21:51:18 +0100 Subject: [climacs-devel] Re: Auto-nag: climacs link verifier failed In-Reply-To: <20060118162321.6BA4AE0E8@common-lisp.net> References: <20060118162321.6BA4AE0E8@common-lisp.net> Message-ID: <43CEAA46.5090908@yahoo.com> root wrote: > You are being nagged on because... you are > either pointing to a broken link The broken link is: http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/StrandhVilleneuveMoore.pdf Where should we be pointing? JQS From athas at sigkill.dk Wed Jan 18 16:19:56 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 18 Jan 2006 17:19:56 +0100 Subject: [climacs-devel] GNU Emacs-style find-file defaults (patch) Message-ID: <87wtgxpkyb.fsf@sigkill.dk> McCLIM supports the :insert-default argument to `accept' now, so I've written a patch that adds GNU Emacs-style defaults to the various find-file commands. -------------- next part -------------- A non-text attachment was scrubbed... Name: file-commands.lisp.patch Type: text/x-patch Size: 2906 bytes Desc: not available URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From athas at sigkill.dk Wed Jan 18 16:19:56 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 18 Jan 2006 17:19:56 +0100 Subject: [climacs-devel] GNU Emacs-style find-file defaults (patch) Message-ID: <87wtgxpkyb.fsf@sigkill.dk> McCLIM supports the :insert-default argument to `accept' now, so I've written a patch that adds GNU Emacs-style defaults to the various find-file commands. -------------- next part -------------- A non-text attachment was scrubbed... Name: file-commands.lisp.patch Type: text/x-patch Size: 2906 bytes Desc: not available URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From m.retzlaff at gmx.net Thu Jan 19 20:20:56 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 19 Jan 2006 21:20:56 +0100 Subject: [climacs-devel] Re: Auto-nag: climacs link verifier failed In-Reply-To: <43CEAA46.5090908@yahoo.com> References: <20060118162321.6BA4AE0E8@common-lisp.net> <43CEAA46.5090908@yahoo.com> Message-ID: <20060119202056.GA32222@mgr.home> Hello On Wed, Jan 18, 2006 at 09:51:18PM +0100, John Q Splittist wrote: > root wrote: > >You are being nagged on because... you are > >either pointing to a broken link > > The broken link is: > > http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/StrandhVilleneuveMoore.pdf > > Where should we be pointing? To http://p-cos.net/lisp-ecoop/submissions/StrandhVilleneuveMoore.pdf Hah, only on last Sunday when I wanted to add a page about that workshop to the cliki I had to search quite some time for the new location. :-) Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet. -- Michael Jackson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From splittist at yahoo.com Sat Jan 21 20:44:48 2006 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 21 Jan 2006 21:44:48 +0100 Subject: [climacs-devel] Re: GNU Emacs-style find-file defaults (patch) In-Reply-To: <87wtgxpkyb.fsf@sigkill.dk> References: <87wtgxpkyb.fsf@sigkill.dk> Message-ID: <43D29D40.9010706@yahoo.com> Troels Henriksen wrote: > McCLIM supports the :insert-default argument to `accept' now, so I've > written a patch that adds GNU Emacs-style defaults to the various > find-file commands. Thanks. Committed. Keep'em coming! JQS From nicolas.sceaux at free.fr Sun Jan 22 13:40:37 2006 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Sun, 22 Jan 2006 14:40:37 +0100 Subject: [climacs-devel] grammar definition In-Reply-To: <17349.59016.550160.748669@serveur5.labri.fr> (Robert Strandh's message of "Thu, 12 Jan 2006 06:18:00 +0100") References: <17349.59016.550160.748669@serveur5.labri.fr> Message-ID: Robert Strandh writes: > You may want to start with a protocol (in the sense of Keene) for > manipulating grammars; then you can define syntax to simplify common > cases. For instance, you most likely would want the grammar to be > able to evolve programmatically. There should be some examples of > `add-rule' in the other syntax modules that show this idea. An attempt to write protocol for LR syntax, as defined in lisp-syntax.lisp today (the descriptions, when they are mine, are, hm, minimal): lr-syntax [protocol class] Base class for syntaxes using a LR parser. parser-symbol [protocol class] Base class for parse trees, including lexemes. * Lexer lexer-state [protocol class] These states are used to determine how the lexer should behave. define-lexer-state name superclasses &body body [macro] Define a lexer-state subclass (lexer-state is prepended to the superclass list). skip-inter syntax state scan [generic function] Advance scan until the beginning of a new lexeme. Return T if one can be found and NIL otherwise. lexeme [class] ... lex syntax state scan [generic function] Return the next lexeme starting at scan. * Parser parser-state [protocol class] Base class for LR parser states. define-parser-state name superclasses &body body [macro] Define a parser-state subclass and a singleton instance with the same name. (Side question: shouldn't parser-state be added to the superclass list by the macro, rather than by the user? as is done in define-lexer-state) action syntax parser-state lexeme [generic function] This function is called after the lexer has returned a lexeme to the parser, which current state is parser-state. It returns a parser-symbol. define-action syntax (parser-state lexeme) body [macro] Define an action method for syntax, parser-state and lexeme. reduce-fixed-number [macro] ... reduce-until-type [macro] ... reduce-all [macro] ... NOTE: I see that SYNTAX is used in there expansion, without introducing a binding for it. Isn't that a problem? done [tag] ... new-state syntax parser-state parser-symbol [generic function] This function is called after the parser, which current state is parser-state, has reached parser-symbol, and return the new parser state. define-new-state syntax (parser-state parser-symbol) new-parser-state Define what the new state of the parser should be when it reaches parser-symbol while its current state is parser-state. * Display display-parse-tree parse-symbol syntax pane ... > Perhaps a compromise would be to specify a rule pretty much the > standard way, but to allow for a state name to be inserted between two > parser symbols, for instance: > > (list -> left-parenthesis-lexeme {the-state-we-want-to-be-in} ...) > > or something like that. add-rule syntax (nonterminal -> &rest arguments) [macro] Create a parser rule for syntax. arguments should look like: initial-state [symbol next-state]+ [:EOF]? :EOF is used to signal that the reduction to nonterminal applies when the end of buffer is reached. nonterminal -> initial-state symbol1 state1 symbol2 state2 ... symboln staten means that starting from the parser state initial-state, when symbol1 is reached, the parser changes to state state1; then, being in state state1, if symbol2 is reached, the parser changes to state state2, etc. Finally, the parse tree is reduced to nonterminal. The parser is then in state staten. (reading myself, I do realize that I'm not really clear) (add-rule lisp-syntax (complete-list-form -> form-may-follow left-parenthesis-lexeme |( form* | comment |( form* | form |( form* | right-parenthesis-lexeme |( form* ) |)) ==> (PROGN (DEFINE-NEW-STATE LISP-SYNTAX (FORM-MAY-FOLLOW LEFT-PARENTHESIS-LEXEME) |( form* |) (DEFINE-NEW-STATE LISP-SYNTAX (|( form* | COMMENT) |( form* |) (DEFINE-NEW-STATE LISP-SYNTAX (|( form* | FORM) |( form* |) (DEFINE-NEW-STATE LISP-SYNTAX (|( form* | RIGHT-PARENTHESIS-LEXEME) |( form* ) |) (DEFINE-ACTION LISP-SYNTAX (|( form* ) | T) (REDUCE-UNTIL-TYPE COMPLETE-LIST-FORM LEFT-PARENTHESIS-LEXEME))) (add-rule lisp-syntax (incomplete-list-form -> form-may-follow left-parenthesis-lexeme |( form* | comment |( form* | form |( form* | :EOF)))) ==> (PROGN (DEFINE-NEW-STATE LISP-SYNTAX (FORM-MAY-FOLLOW LEFT-PARENTHESIS-LEXEME) |( form* |) (DEFINE-NEW-STATE LISP-SYNTAX (|( form* | COMMENT) |( form* |) (DEFINE-NEW-STATE LISP-SYNTAX (|( form* | FORM) |( form* |) (DEFINE-ACTION LISP-SYNTAX (|( form* | (EQL NIL)) (REDUCE-UNTIL-TYPE INCOMPLETE-LIST-FORM LEFT-PARENTHESIS-LEXEME))) That would cover most of the rules in lisp-syntax (ie, all of them, except the error and top-level ones). nicolas From root at common-lisp.net Mon Jan 23 08:15:10 2006 From: root at common-lisp.net (root) Date: Mon, 23 Jan 2006 02:15:10 -0600 (CST) Subject: [climacs-devel] Auto-nag: climacs link verifier failed Message-ID: <20060123081510.6F08C1E1DD@common-lisp.net> You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at clo-devel at common-lisp.net Thanks! From csr21 at cam.ac.uk Mon Jan 23 09:21:08 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Jan 2006 09:21:08 +0000 Subject: [climacs-devel] Auto-nag: climacs link verifier failed In-Reply-To: <20060123081510.6F08C1E1DD@common-lisp.net> (root@common-lisp.net's message of "Mon, 23 Jan 2006 02:15:10 -0600 (CST)") References: <20060123081510.6F08C1E1DD@common-lisp.net> Message-ID: root at common-lisp.net (root) writes: > You are being nagged on because your project's This should be fixed now. Cheers, Christophe From athas at sigkill.dk Fri Jan 27 16:15:53 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 27 Jan 2006 17:15:53 +0100 Subject: [climacs-devel] `form-before-in-children' fix. Message-ID: <877j8l6406.fsf@sigkill.dk> Assume we have a Climacs buffer in Lisp syntax containing the following: ( foo bar ) ; I am a comment. If you put point just after the closing brace and press C-M-p (for Backward Expression) Climacs will signal an error. The cause of this error is `form-before-in-children' (meaning that it affects many things that manipulates expressions, such as the macro-expansion facilities in Swine). Attached is a patch that fixes this problem. As usual, this patch was written by me, and may thus cause defects in other parts of the system. :-) -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) -------------- next part -------------- A non-text attachment was scrubbed... Name: lisp-syntax.lisp.patch Type: text/x-patch Size: 1113 bytes Desc: not available URL: From athas at sigkill.dk Tue Jan 31 19:46:21 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 31 Jan 2006 20:46:21 +0100 Subject: [climacs-devel] `form-before-in-children' fix. In-Reply-To: <877j8l6406.fsf@sigkill.dk> (Troels Henriksen's message of "Fri, 27 Jan 2006 17:15:53 +0100") References: <877j8l6406.fsf@sigkill.dk> Message-ID: <87vew0i3jm.fsf@sigkill.dk> Attached is a slightly changed patch. This one will not have any adverse effects to other parts of Climacs, as it will only kick in when the result would otherwise be an error (ie. when `first-form' returns NIL). -------------- next part -------------- A non-text attachment was scrubbed... Name: lisp-syntax.lisp.patch Type: text/x-patch Size: 880 bytes Desc: not available URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)