From athas at sigkill.dk Fri Feb 3 15:55:18 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 03 Feb 2006 16:55:18 +0100 Subject: [climacs-devel] Issues with syntax-dependent command tables. Message-ID: <87zml81lp5.fsf@sigkill.dk> As far as I have experienced, Climacs currently has some rather serious issues with syntax-dependent command tables. Command tables that should be specialised to specific syntaxes, such as `lisp-table' are instead inherited by the global `global-climacs-table', which is then used to perform command-lookup, no matter the syntax of the active buffer (the mechanisms needed to select a specific command table based on the active buffer is available, in the form of `find-applicable-command-table' from gui.lisp, but the command-table slots in the syntax objects are not used, which causes the method to default to the `global-climacs-table'). This behavior manifests as a bug when one uses Climacs with Swine (from CLIM-desktop) loaded. Swine works by defining some commands in `lisp-table', one of the command tables inherited by `global-climacs-table'. One of these commands (`com-swine-space') is bound to the #\Space gesture, which means that every time the spacebar is pressed in a buffer using the `global-climacs-table' command table (which is most of them), the Swine-command will be run. This command assumes that the syntax of the current buffer is Lisp, and will thus signal an error when it attempts to access nonexistant slots in the buffers syntax object. This is obviously bad, as it seems to effectively disable the spacebar in any buffer that is not in Lisp syntax and which does not explicitly define a new command for the #\Space gesture. The problem seems to mainly be one of too tight integration of command tables to core Emacs code. gui.lisp defines several command tables one should expect to be defined in their respective files (`lisp-table' should be defined in lisp-syntax.lisp IMHO - of course, this raises another issue, as some commands in misc-commands.lisp refers to `lisp-table', but they could be moved into a more specific file). As an experiment, I have removed `global-climacs-table's dependency on `lisp-table' and instead made `lisp-table' depend on `global-climacs-table' (in order to get the basic navigation and editing commands). It seems to work properly, so I believe it should be trivial to perform a general cleanup of Climacs' command tables and their interdependencies. Commands such as `com-eval-defun', which is currently defined in misc-commands.lisp, could also be moved to lisp-syntax.lisp. Thoughts? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From athas at sigkill.dk Fri Feb 3 21:35:37 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 03 Feb 2006 22:35:37 +0100 Subject: [climacs-devel] Issues with syntax-dependent command tables. In-Reply-To: <87zml81lp5.fsf@sigkill.dk> (Troels Henriksen's message of "Fri, 03 Feb 2006 16:55:18 +0100") References: <87zml81lp5.fsf@sigkill.dk> Message-ID: <87slr015xy.fsf@sigkill.dk> Troels Henriksen writes: > As an experiment, I have removed `global-climacs-table's dependency > on `lisp-table' and instead made `lisp-table' depend on > `global-climacs-table' (in order to get the basic navigation and > editing commands). It seems to work properly, so I believe it should > be trivial to perform a general cleanup of Climacs' command tables > and their interdependencies. Apparently the command table issue was just a symptom of a bigger problem. It seems that the Climacs internals are fraught with confusing interdependencies, among other things, that the GUI-layer depends on the Lisp syntax module. Generally, gui.lisp seems to have become a bucket for all kinds of bits and pieces, containing a lot of very important functions, but not really exporting any of them. This makes it harder to properly divide responsibility among packages, so I've started to reorganize interdependencies and modules with the goal of making Climacs' internal structure a bit more logical. My immediate goal is to isolate the Lisp syntax in the `climacs-lisp-syntax' package and the files lisp-syntax.lisp and lisp-syntax-commands.lisp. Fortunately, the existing syntax module protocol lends itself well to modularity, so this should not be very hard. Unfortunately, this incompatible change will require modification of Swine for it to continue to function properly. Thoughts? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From earljwagner at alum.mit.edu Sat Feb 4 08:52:32 2006 From: earljwagner at alum.mit.edu (Earl J. Wagner) Date: Sat, 4 Feb 2006 02:52:32 -0600 Subject: [climacs-devel] incremental GLR and LR parser library Message-ID: Hi all, I've been following the discussion of parsers on and off and have something that might be useful to contribute. I packaged up some code that I have for creating incremental GLR and LR parser generators from BNF-style language descriptions. The GLR parser is based on Rekers' incremental algorithm with Farshi's modifications. It is robust and includes many tests. The LR parser is an implementation of the standard algorithm from the dragon book. Finally, this includes Mark Johnson's LALR parse table generator with his permission. I'm aware that this is a more conventional approach than what is currently envisioned for the parser for climacs. If using this code can save effort, however, then I'm willing to help out in building on it. The library is asdf-installable and is released under the LLGPL: www.cs.northwestern.edu/~ewagner/parsers.tar.gz It uses an extension to cl-ppcre (along with cl-ppcre) that adds named registers: www.cs.northwestern.edu/~ewagner/cl-ppcre-e.tar.gz For testing, It also uses CLUnit that, with a minor modification (commenting out the package operations in lines 291-292 CLUnit.lisp) runs in SBCL www.cs.northwestern.edu/~ewagner/CLUnit.tar.gz Eventually I'd like to release this library more widely but for right now I'm interested in getting feedback from anyone who finds them immediately useful. In particular, the code was written on Allegro and runs on Allegro 7.0 and SBCL 0.9.0 but has minimal testing on the latter. Making sure the code runs well for other users and on other platforms is my main priority right now. Thanks for any feedback -Earl From strandh at labri.fr Sat Feb 4 18:48:26 2006 From: strandh at labri.fr (Robert Strandh) Date: Sat, 4 Feb 2006 19:48:26 +0100 Subject: [climacs-devel] Issues with syntax-dependent command tables. In-Reply-To: <87slr015xy.fsf@sigkill.dk> References: <87zml81lp5.fsf@sigkill.dk> <87slr015xy.fsf@sigkill.dk> Message-ID: <17380.63226.915099.947180@serveur5.labri.fr> Troels Henriksen writes: > Troels Henriksen writes: > > > As an experiment, I have removed `global-climacs-table's dependency > > on `lisp-table' and instead made `lisp-table' depend on > > `global-climacs-table' (in order to get the basic navigation and > > editing commands). It seems to work properly, so I believe it should > > be trivial to perform a general cleanup of Climacs' command tables > > and their interdependencies. > > Apparently the command table issue was just a symptom of a bigger > problem. It seems that the Climacs internals are fraught with > confusing interdependencies, among other things, that the GUI-layer > depends on the Lisp syntax module. That is definitely a bad thing. > Generally, gui.lisp seems to have > become a bucket for all kinds of bits and pieces, containing a lot of > very important functions, but not really exporting any of them. This > makes it harder to properly divide responsibility among packages, Sounds plausible. > so > I've started to reorganize interdependencies and modules with the goal > of making Climacs' internal structure a bit more logical. My immediate > goal is to isolate the Lisp syntax in the `climacs-lisp-syntax' > package and the files lisp-syntax.lisp and > lisp-syntax-commands.lisp. Fortunately, the existing syntax module > protocol lends itself well to modularity, so this should not be very > hard. Unfortunately, this incompatible change will require > modification of Swine for it to continue to function properly. > > Thoughts? I think your analysis sounds right, and I your idea of improving the situation is probably the right one as well. You might want to check the archives for ideas about how to organize command lookup. I forget what we settled on, but there were issues about whether to search several command tables, and if so, in which order. Good luck, -- 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 Tue Feb 7 15:37:11 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 07 Feb 2006 16:37:11 +0100 Subject: [climacs-devel] Issues with syntax-dependent command tables. In-Reply-To: <17380.63226.915099.947180@serveur5.labri.fr> (Robert Strandh's message of "Sat, 4 Feb 2006 19:48:26 +0100") References: <87zml81lp5.fsf@sigkill.dk> <87slr015xy.fsf@sigkill.dk> <17380.63226.915099.947180@serveur5.labri.fr> Message-ID: <874q3btc2g.fsf@sigkill.dk> Well, I just committed the changes. They work for me, though they do break Swine. Check swine-devel for a patch that rectifies this. I hope I didn't break anything else. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From athas at sigkill.dk Tue Feb 7 15:47:02 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 07 Feb 2006 16:47:02 +0100 Subject: [climacs-devel] Issues with syntax-dependent command tables. In-Reply-To: <874q3btc2g.fsf@sigkill.dk> (Troels Henriksen's message of "Tue, 07 Feb 2006 16:37:11 +0100") References: <87zml81lp5.fsf@sigkill.dk> <87slr015xy.fsf@sigkill.dk> <17380.63226.915099.947180@serveur5.labri.fr> <874q3btc2g.fsf@sigkill.dk> Message-ID: <87vevrrx1l.fsf@sigkill.dk> Troels Henriksen writes: > Check swine-devel for a patch that rectifies this. That should have been clim-desktop-devel (http://common-lisp.net/mailman/listinfo/clim-desktop-devel) -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From edgardenny at comcast.net Thu Feb 23 02:45:23 2006 From: edgardenny at comcast.net (Edgar Denny) Date: Wed, 22 Feb 2006 21:45:23 -0500 Subject: [climacs-devel] Small patch for buffer info line Message-ID: <87vev6dc8s.fsf@debian.Belkin> Hi, Attached is a very small patch to correct problem where buffer info line can show "Top" when point is actually at the bottom of the buffer, etc. Also, I've added line number and column number to the info line. The patch is part work around, part fix. The existing code relies on (top master-pane) and (bot master-pane) returning accurate positions - which seems to not be the case for many types of movement within a buffer. I'll take a closer look at this problem. Edgar. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From athas at sigkill.dk Sat Feb 25 10:01:28 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 25 Feb 2006 11:01:28 +0100 Subject: [climacs-devel] Should we move SWINE into Climacs? Message-ID: <87accfeozr.fsf@sigkill.dk> As most of you probably know, CLIM-desktop ships with an extension to Climacs called SWINE. SWINE adds SWANK-based SLIME-like functionality to Climacs' Lisp Syntax-mode, and is thus pretty much necessary for doing Lisp development in Climacs. Thus, I believe that SWINE logically belongs in Climacs itself. Of course, moving SWINE to Climacs will bring Swank in as a dependency, but this will probably not be a huge problem, due to Swanks ubiquity, and the fact that it should be possible to conditionally load Swine only if Swank is available. What are your thoughts on this matter? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From nicolas.sceaux at free.fr Sat Feb 25 16:31:08 2006 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Sat, 25 Feb 2006 17:31:08 +0100 Subject: [climacs-devel] testing syntaxes Message-ID: Hi, I was wondering how do you usually test a syntax while developping it. For instance, how to see the parse-tree of a buffer? From which entry point do you access it? I hacked climacs-gui::climacs to store the climacs application-frame inside a *climacs-frame* variable, and then I inspect it with slime's inspector, and navigate until I find the relevant syntax object and its stack-top slot (this is lisp-syntax). But this is not really convenient and I'm sure people here have better way to present parse trees. nicolas From moore at bricoworks.com Sat Feb 25 18:16:24 2006 From: moore at bricoworks.com (Timothy Moore) Date: Sat, 25 Feb 2006 19:16:24 +0100 Subject: [climacs-devel] Should we move SWINE into Climacs? In-Reply-To: <87accfeozr.fsf@sigkill.dk> References: <87accfeozr.fsf@sigkill.dk> Message-ID: <44009EF8.6080606@bricoworks.com> Troels Henriksen wrote: > As most of you probably know, CLIM-desktop ships with an extension to > Climacs called SWINE. SWINE adds SWANK-based SLIME-like functionality > to Climacs' Lisp Syntax-mode, and is thus pretty much necessary for > doing Lisp development in Climacs. Thus, I believe that SWINE > logically belongs in Climacs itself. > > Of course, moving SWINE to Climacs will bring Swank in as a > dependency, but this will probably not be a huge problem, due to > Swanks ubiquity, and the fact that it should be possible to > conditionally load Swine only if Swank is available. > > What are your thoughts on this matter? It's too bad that Swank is not really an asdf system in its own right. Sure, there's a swank.asd file in Slime, but it's not normally used, even if Slime is (perhaps implicitly) using asdf to load up its dependencies. Perhaps the Slime folks could be persuaded to package it up a bit; failing that I suppose you could create a system in Swank that Does The Right Thing. As far as conditional dependencies and options go, that seems to be a weakness in asdf, something that GNU configure does better for all its warts. I realize that's quite unfair given that asdf is a build system and not a configuration system, but I'm not sure how to construct options in the asdf world without a large collection of system definitions and ugly read-time conditionals. Perhaps more could be done with asdf:feature-dependent-op and arguments to load-op; it would be nice to type (for example) (oos 'load-op :climacs :with-clim :mcclim). Tim From athas at sigkill.dk Tue Feb 28 17:53:57 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 28 Feb 2006 18:53:57 +0100 Subject: [climacs-devel] Should we move SWINE into Climacs? In-Reply-To: <44009EF8.6080606@bricoworks.com> (Timothy Moore's message of "Sat, 25 Feb 2006 19:16:24 +0100") References: <87accfeozr.fsf@sigkill.dk> <44009EF8.6080606@bricoworks.com> Message-ID: <87irqz4bey.fsf@sigkill.dk> Timothy Moore writes: > It's too bad that Swank is not really an asdf system in its own > right. Sure, there's a swank.asd file in Slime, but it's not > normally used This is somewhat of a surprise to me. CLIM-desktop seems to work fine by specifying a dependency on :swank, but is this only guaranteed to work under SBCL or somesuch? -- \ Troels "Athas" Henriksen /\ sigkill.dk