From splittist at yahoo.com Sat Jun 11 19:31:00 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 11 Jun 2005 20:31:00 +0100 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <17023.30829.140422.66779@serveur5.labri.fr> References: <42787C0B.5060609@yahoo.com> <17020.29523.523623.585893@serveur5.labri.fr> <427C8820.6020206@yahoo.com> <427C9DB1.5030808@yahoo.com> <17023.30829.140422.66779@serveur5.labri.fr> Message-ID: <42AB3BF4.7070706@yahoo.com> Robert Strandh wrote: > John Q Splittist writes: > > Herewith a patch adding a point slot to climacs-buffer > You could also setf the offset of one from the other instead of > cloning. This will preserve identity, in case that is important to > someone. Herewith a patch that does that. Not a biggie, but I'm testing out using my new super powers for good. If no one spots a flaw, I'll have a go at committing this. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: offset.patch URL: From csr21 at cam.ac.uk Sun Jun 12 15:43:45 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 12 Jun 2005 16:43:45 +0100 Subject: [climacs-devel] cursor drawing Message-ID: Hi, The attached patch puts the cursor more where I expect a cursor to be, in prolog-mode. Does anyone have a feeling yet for how to generalize or abstract the displaying code so that this kind of patch wouldn't be syntax-specific? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cursor.diff URL: -------------- next part -------------- Cheers, Christophe From dan at telent.net Thu Jun 16 22:27:44 2005 From: dan at telent.net (Daniel Barlow) Date: Thu, 16 Jun 2005 23:27:44 +0100 Subject: [climacs-devel] one-character patch to gui.lisp with-input-context call Message-ID: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> Periodically I was getting errors from climacs complaining that > Condition COMMAND-TABLE-NOT-FOUND was signalled. > 0: (FIND-COMMAND-TABLE (QUOTE GLOBAL-CLIMACS-TABLE) :ERRORP T) I'm not sure how to trigger this absolutely reliably, but defining the command below and executing it a couple of times seems to do the trick most of the time (define-named-command describe-keymap () (let ((command-table 'global-climacs-table)) (map-over-command-table-keystrokes (lambda (name key item) (let ((command-name (command-menu-item-value item)) (key (slot-value item 'climi::keystroke))) (when (listp command-name) (setf command-name (car command-name))) (unless (eq command-name 'com-self-insert) (format #+nil *standard-input* *trace-output* "~A || ~S~%" key command-name )))) command-table))) (I'm working up towards writing something akin to emacs' describe-mode that shows the current keybindings. At the moment iut only shows the global bindings, but that seems to be the only bindings there are right now anyway ...) Anyway, the problem seems to be an extra ' in gui.lisp : --- gui.lisp 15 Jun 2005 06:00:12 -0000 1.144 +++ gui.lisp 16 Jun 2005 22:16:41 -0000 @@ -315,7 +316,7 @@ (progn (handler-case (with-input-context - ('(command :command-table 'global-climacs-table)) + ('(command :command-table global-climacs-table)) (object) (process-gestures) (t yesno? -dan From strandh at labri.fr Fri Jun 17 07:39:32 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 17 Jun 2005 09:39:32 +0200 Subject: [climacs-devel] one-character patch to gui.lisp with-input-context call In-Reply-To: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> References: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> Message-ID: <17074.32308.858658.914192@serveur5.labri.fr> Daniel Barlow writes: > > yesno? Looks plausible. Do you have commit privileges? If not, I suggest you give you some. -- 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 Fri Jun 17 07:41:14 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 17 Jun 2005 09:41:14 +0200 Subject: [climacs-devel] one-character patch to gui.lisp with-input-context call In-Reply-To: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> References: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> Message-ID: <17074.32410.763269.642291@serveur5.labri.fr> Daniel Barlow writes: > > (I'm working up towards writing something akin to emacs' > describe-mode that shows the current keybindings. At the moment iut > only shows the global bindings, but that seems to be the only > bindings there are right now anyway ...) That would be great. If at the same time you could think about what the Climacs equivalent of mode-specific key bindings would be, that would be even better. -- 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 dan at telent.net Fri Jun 17 18:26:08 2005 From: dan at telent.net (Daniel Barlow) Date: Fri, 17 Jun 2005 19:26:08 +0100 Subject: [climacs-devel] keybindings (was one-character patch to gui.lisp with-input-context call) In-Reply-To: <17074.32410.763269.642291@serveur5.labri.fr> (Robert Strandh's message of "Fri, 17 Jun 2005 09:41:14 +0200") References: <87slziszrz.fsf@no-rom-basic.office.uk.clara.net> <17074.32410.763269.642291@serveur5.labri.fr> Message-ID: <87zmtox2kf.fsf_-_@noetbook.telent.net> Robert Strandh writes: > That would be great. If at the same time you could think about what > the Climacs equivalent of mode-specific key bindings would be, that > would be even better. Some points arising from discussion on irc, and a few other things that occured to me: 1) An emacs 'mode' is typically two things, really: it has a keymap, and it also decribes the syntactic properties of the text in the buffer being edited (at least as far as is necessary for colourising, indentation etc). Most emacs modes do the latter in a 'sloppy' fashion with regexes instead of the full-blooded parsing that climacs does, but nevertheless the intention is there. It would probably help to separate these concerns in climacs. If apps like slidemacs or tabcode are typical, it's going to be a common requirement that there are two different representations of the same buffer shown simultaneously in different windows. These windows are both representations of the same buffer but will (in general) each want their own keybindings. 2) I'd like to see if it can all be done with data structures that are easily inspectable to find out what the bindings are. A big part of emacs learnability is that you can prod around in this way to find out what your new mode does. command-tables + accelerators meet this requirement; clos dispatch from (gesture pane syntax) to command doesn't. 3) I think I'd like to try a command-table associated with each pane-in-which-editing-is-done. This would usually inherit from another table associated with the buffer syntax, which in turn would inherit global bindings. This is probably going to mean that most of the things-that-were-modes-in-emacs will need a subclass of pane-in-which-editing-is-done as well as a syntax. 4) The point was raised that if we go with (3) above, a pane-in-which-editing-is-done may want to suppress bindings that it inherits from a parent table. For example, slidemacs slideshow mode may not want to have lots of self-insert keys. This is an interesting question insofar as many of the modes in emacs that don't allow keyboard entry of characters (e.g. dired, gnus summary buffers) are the kinds of things that are probably outside scope for climacs and would be better implemented as clim apps of their own. On the other hand, climacs is a sequence editor not just a text editor, and in any setting where the objects being edited are unlike characters, self-insert is not going to be a really useful concept. Maybe some of the need for suppressing bindings would go away if self-insert for "normal" keys wasn't part of the global command-table, but was provided as an extra table that a pane-in-which-editing-is-done can inherit from. Remember that command-tables can inherit from more than one parent, so in principle we can have as many mixin tables as we like, and in practice as many as we can cope with. Perhaps also it'll be the case that a command-table for a syntax will provide commands (com-goto-definition) but not accelerators, and leave the pane-in-which-editing-is-done to say how the commands map to the keyboard (M-.) 5) This may turn out to be insufficiently flexible or to be impossibly over-flexible. Without trying it I think it's going to be hard to say which. 6) pane-in-which-editing-is-done needs a better name ;-) From strandh at labri.fr Thu Jun 2 04:23:23 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 2 Jun 2005 06:23:23 +0200 Subject: [climacs-devel] latest progress Message-ID: <17054.35259.927006.208344@serveur5.labri.fr> Dear mailing list member, There have been a few exciting developments since the previous progress report. First, we (me, Brian Mastenbrook, Christophe Rhodes) have a paper about Climacs syntax protocols accepted at the ILC 2005. In it, we explain the difference between per-buffer and per-window syntax updating and give examples of modules that use these methods. When reading what my co-authors had written, I was struck by the number of syntax modules that already exist for Climacs and how varied they are: a very complete syntax module for ISO Prolog, a module for Tabcode notation used for Lute scores, a module for Testing and Test Control Notation 3 (TTCN3), and of course existing but incomplete syntax modules for Common Lisp and HTML. Second, due to difficulties achieving good performance with the Earley parser, I have written an alternative parser based on incremental LR parsing technology. I also wrote the definitions necessary for this module to parse Common Lisp. This syntax module is named "Lisp" to distinguish it from the one called "Common Lisp". It is experimental for now, so both are available. The incremental LR parser keeps a parse tree for the entire buffer up to date. It is thus a per-buffer module, which would be impossible with the current Earley parser. Parsing all of lisp-syntax.lisp (around 1000 lines) takes around 2 seconds on my machine, but this is only done when the file is initially loaded, or when edits to the buffer are made that makes the contents parse entirely differently from last time, such as when a closing parenthesis is introduced at the beginning of the buffer. In almost all cases, the incremental LR parser is able to patch the existing parse tree. As an example, typing a function definition at the beginning of a buffer containing lisp-syntax. lisp requires less than 10ms per keystroke to update the entire parse tree. Current feature of the "Lisp" syntax module include C-M-b and C-M-f (backward and forward expression), C-M-x (eval defun), and of course syntax highlighting of strings, keywords, and comments. One interesting feature of the LR parser that I implemented is that the lexer is a generic function that depends on the state of the parser. This method is slower than the one used for the Earley parser, but we could afford this since the parser is incremental. The consequences of this lexer organization is that the parser could enter a state in which a totally different language, with different lexemes, is to be parsed. This feature opens the door to modular parsers allowing us to parse a string of PHP code inside an HTML buffer, or to check the grammar of strings and comments of a program. Plans are to factor out code that could be common for more LR-based syntax modules, either into syntax.lisp or to a new file, but probably the former since there are definitions like that of a parse tree that look very similar in the Earley parser and in the LR parser. I also haven't given up on trying to make the Earley parser truly incremental in the same way that the LR parser now is. Plans also include writing a new LALR parser generator, simply because the one in Climacs uses generic functions instead of tables for the traditional `action' and `goto' (called `new-state' in Climacs) functions of LR parsing. The new parser generator would have to discover inheritance relations between parser states. Once such a generator exists, I might rewrite the HTML syntax module to take advantage of it. For a detailed list of updates, I refer you to the CVS archives. 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 brian at mastenbrook.net Sun Jun 5 13:10:44 2005 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Sun, 5 Jun 2005 08:10:44 -0500 Subject: [climacs-devel] New syntax for Climacs: "slidemacs" Message-ID: (Let's try this again: I can never remember which of my various mail aliases are subscribed to which lists.) I've added the beginnings of the slideshow mode for climacs that I'm writing for the ILC talk to CVS. There are two new syntaxes sharing a common grammar: "Slidemacs-Editor" and "Slidemacs-GUI". Slidemacs- Editor a syntax for editing slidemacs files, which are a lightweight (very, very lightweight at the moment) description of a slideshow: slideset "A Test Slideset" { slide "Jello" { * "I like Jello" * "Jello is good" * "Almost as good as Climacs!" } } Slidemacs-GUI is a syntax which displays these slides inline in the Climacs editor window. They look like this: http://www.unmutual.info/images/slidemacs-jello.png The slide which has the point in it is displayed in the Climacs window; the bullet point with the point in it is displayed in bold. If no slide contains the point, the window is empty. There are new keystrokes C-- and C-= (that's control #\- and #\=) for navigating between bullets. Right now the slidemacs GUI mode is set up to draw everything in white ink. For now, until I come up with something better, press Control-1 to change the background to blue and Control-2 to change it back to white. -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/ From csr21 at cam.ac.uk Mon Jun 27 21:31:31 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 27 Jun 2005 22:31:31 +0100 Subject: [climacs-devel] html syntax buglet Message-ID: Hi, I think NEXT-LEXEME has a buglet in HTML syntax. in this clause: (#\< (fo) (cond ((or (end-of-buffer-p scan) (not (eql (object-after scan) #\/))) (make-instance 'start-tag-start)) (t (fo) (make-instance 'end-tag-start)))) Here the effect of the /next/ character affects the identification of the current lexeme. This means that the lexer is no longer entirely local, and so UPDATE-SYNTAX (which invalidates the lexemes based on the damaged region) might not invalidate enough. To see this, open an empty html file and type foo and observe that the "" is treated as a parse error. The problem is that the "<" of "", when first typed, is treated as a start-tag-start, and this is never invalidated. I think the simplest way to fix this is probably to make #\< always lex as a tag-start, rather than differentiating between start-tag-start and end-tag-start, because then the update-syntax method doesn't need to be updated. (I found this while briefly looking for the bug which affects Prolog syntax: loading a prolog file initially shows everything to be a parse error; typing space at the top of the buffer forces a reparse and everything is well from that point. I have no idea why this happens.) Cheers, Christophe From dirk at dirkgerrits.com Mon Jun 27 22:05:18 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Tue, 28 Jun 2005 00:05:18 +0200 Subject: [climacs-devel] 'No more undo' drops me in the debugger. Message-ID: The following steps put me in the Lisp debugger with the error "No more undo": * Start Climacs. * Press C-x u. I've reproduced this with both McCLIM 0.9.1 and McCLIM CVS. Climacs and Flexichain were from CVS in both cases. My system is an AMD64 running SBCL 0.9.1. By the way, the error is RETURN-TO-CLIMACS'able. Kind regards, Dirk Gerrits From strandh at labri.fr Tue Jun 28 04:19:46 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Jun 2005 06:19:46 +0200 Subject: [climacs-devel] html syntax buglet In-Reply-To: References: Message-ID: <17088.53218.670875.769341@serveur5.labri.fr> Christophe Rhodes writes: > > I think NEXT-LEXEME has a buglet in HTML syntax. Looks plausible. > > in this clause: > > (#\< (fo) (cond ((or (end-of-buffer-p scan) > (not (eql (object-after scan) #\/))) > (make-instance 'start-tag-start)) > (t (fo) > (make-instance 'end-tag-start)))) > > Here the effect of the /next/ character affects the identification of > the current lexeme. This means that the lexer is no longer entirely > local, and so UPDATE-SYNTAX (which invalidates the lexemes based on > the damaged region) might not invalidate enough. To see this, open an > empty html file and type > > foo > > and observe that the "" is treated as a parse error. The > problem is that the "<" of "", when first typed, is treated as > a start-tag-start, and this is never invalidated. > > I think the simplest way to fix this is probably to make #\< always > lex as a tag-start, rather than differentiating between > start-tag-start and end-tag-start, because then the update-syntax > method doesn't need to be updated. You might be right. However, this bug was introduced because I wanted to have fewer lexemes in order to speed up the parser. I'll think about it some more before making this change. > (I found this while briefly looking for the bug which affects Prolog > syntax: loading a prolog file initially shows everything to be a parse > error; typing space at the top of the buffer forces a reparse and > everything is well from that point. I have no idea why this happens.) That's strange indeed. Is it OK even after removing the space? -- 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 Jun 28 05:03:44 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Jun 2005 07:03:44 +0200 Subject: [climacs-devel] 'No more undo' drops me in the debugger. In-Reply-To: References: Message-ID: <17088.55856.231018.486088@serveur5.labri.fr> Dirk Gerrits writes: > The following steps put me in the Lisp debugger with the error "No more > undo": > > * Start Climacs. > * Press C-x u. > > I've reproduced this with both McCLIM 0.9.1 and McCLIM CVS. Climacs and > Flexichain were from CVS in both cases. My system is an AMD64 running > SBCL 0.9.1. Thanks for reporting this. The bug was due to the fact the NO-MORE-UNDO condition was not handled. 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 dirk at dirkgerrits.com Tue Jun 28 12:02:51 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Tue, 28 Jun 2005 14:02:51 +0200 Subject: [climacs-devel] Re: 'No more undo' drops me in the debugger. In-Reply-To: <17088.55856.231018.486088@serveur5.labri.fr> References: <17088.55856.231018.486088@serveur5.labri.fr> Message-ID: Robert Strandh wrote: > Dirk Gerrits writes: > > The following steps put me in the Lisp debugger with the error "No more > > undo": > > > > * Start Climacs. > > * Press C-x u. > > > > I've reproduced this with both McCLIM 0.9.1 and McCLIM CVS. Climacs and > > Flexichain were from CVS in both cases. My system is an AMD64 running > > SBCL 0.9.1. > > Thanks for reporting this. The bug was due to the fact the > NO-MORE-UNDO condition was not handled. It looks fixed now. Great! Kind regards, Dirk Gerrits From dirk at dirkgerrits.com Tue Jun 28 12:00:34 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Tue, 28 Jun 2005 14:00:34 +0200 Subject: [climacs-devel] Re: html syntax buglet In-Reply-To: <17088.53218.670875.769341@serveur5.labri.fr> References: <17088.53218.670875.769341@serveur5.labri.fr> Message-ID: Robert Strandh wrote: > Christophe Rhodes writes: > > (I found this while briefly looking for the bug which affects Prolog > > syntax: loading a prolog file initially shows everything to be a parse > > error; typing space at the top of the buffer forces a reparse and > > everything is well from that point. I have no idea why this happens.) > > That's strange indeed. Is it OK even after removing the space? It is for me. After this initial reparse, it continued to parse correctly whatever I did. Kind regards, Dirk Gerrits From csr21 at cam.ac.uk Wed Jun 29 15:19:14 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 29 Jun 2005 16:19:14 +0100 Subject: [climacs-devel] html syntax buglet In-Reply-To: <17088.53218.670875.769341@serveur5.labri.fr> (Robert Strandh's message of "Tue, 28 Jun 2005 06:19:46 +0200") References: <17088.53218.670875.769341@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > (I found this while briefly looking for the bug which affects Prolog > > syntax: loading a prolog file initially shows everything to be a parse > > error; typing space at the top of the buffer forces a reparse and > > everything is well from that point. I have no idea why this happens.) > > That's strange indeed. Is it OK even after removing the space? Yes. I think I've tracked it down, though I'm sufficiently unfamiliar with the parsing machinery that I can't say I'm sure: at least, the attached patch fixes this (the Prolog-related, that is) bug. For what it's worth, I /believe/ that what this patch fixes is the fact that the initial state can be not just at the start of rules matching target, but also partway (if there is the possibility of empty elements matching the first element on the right-hand-side of a rule) through a rule. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: syntax-initial-state.diff URL: -------------- next part -------------- Cheers, Christophe