From csr21 at cam.ac.uk Fri Jul 1 20:57:59 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 01 Jul 2005 21:57:59 +0100 Subject: [climacs-devel] interactor / minibuffer redraw In-Reply-To: (Christophe Rhodes's message of "Mon, 04 Apr 2005 10:37:02 +0100") References: Message-ID: [ full message included for context ] Christophe Rhodes writes: > It is my suspicion that there is a problem in climacs' toplevel loop, > such that the minibuffer contents aren't preserved over certain > interactions. It could of course be a problem in a lower layer... > > To see the problem, arrange such that there is a climacs window with > the minibuffer area able to be obscured by another window -- something > like > > +--------------------+ > | | > +---| climacs | > | | | > | +--------------------+ > | xterm | > +----------+ > > then type (for instance) > > M-x Set > > Bring the xterm to the front, obscuring the climacs minibuffer, then > bring the climacs window back. Type > > SPC Sy SPC > > and note that the second SPC completes "Syntax" for you, but then > prints "No such command" in the minibuffer. > > The particular instance of this that I would dearly love to see fixed > -- but I suspect that it's the same problem in any case -- is that > this makes the use of the possible completions gesture (C-/) useless > in the context of C-x C-f: create a small text file in /tmp/ by other > means, and then do > > C-x C-f /t C-/ > > a (partial) completions window pops up: choose /tmp/, and then attempt > to select your file; I get > > debugger invoked on a SIMPLE-ERROR in thread 12565: > # is not > contained in # {AE455A1}>. > from > CLIM:ERASE-OUTPUT-RECORD > > Any ideas? (I'd love a quick fix, but... I appreciate that this may > not be easy) This seems to be caused by the :before method on clim:handle-repaint for extended-panes in gui.lisp. Does anyone know what it is for? Cheers, Christophe From csr21 at cam.ac.uk Mon Jul 4 13:55:02 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 04 Jul 2005 14:55:02 +0100 Subject: [climacs-devel] html syntax buglet In-Reply-To: (Christophe Rhodes's message of "Wed, 29 Jun 2005 16:19:14 +0100") References: <17088.53218.670875.769341@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > 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. OK, well, I've merged this. Would anyone apart from me using any Earley-parser-driven syntax shout if something no longer works? Thanks, Christophe From a_bakic at yahoo.com Tue Jul 12 14:34:13 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 12 Jul 2005 07:34:13 -0700 (PDT) Subject: [climacs-devel] regexp support Message-ID: <20050712143413.80372.qmail@web40621.mail.yahoo.com> Hi, I have implemented a regular expression engine, based on the Automaton package (http://www.brics.dk/automaton/), which works with characters (and not bits) and is able to handle Unicode in SBCL (it also works in CMUCL, but only up to its charcode-limit). I am using it for some code of mine and it seems quite fast, but I could try to integrate it with Climacs if there is enough interest. (I'd also have to test it better and contact the author of Automaton about the copyright, license, etc.) I will also try to integrate the cl-ppcre port posted on this list when I get another chance to take a look at the contribution. Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From strandh at labri.fr Tue Jul 12 15:57:07 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 12 Jul 2005 17:57:07 +0200 Subject: [climacs-devel] regexp support In-Reply-To: <20050712143413.80372.qmail@web40621.mail.yahoo.com> References: <20050712143413.80372.qmail@web40621.mail.yahoo.com> Message-ID: <17107.59475.892179.218865@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > I have implemented a regular expression engine, based on the Automaton package > (http://www.brics.dk/automaton/), which works with characters (and not bits) > and is able to handle Unicode in SBCL (it also works in CMUCL, but only up to > its charcode-limit). I am using it for some code of mine and it seems quite > fast, but I could try to integrate it with Climacs if there is enough interest. That would be fantastic! > (I'd also have to test it better and contact the author of Automaton about the > copyright, license, etc.) Sure. > I will also try to integrate the cl-ppcre port posted on this list when I get > another chance to take a look at the contribution. Sounds good. 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 strandh at labri.fr Thu Jul 14 08:44:16 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 14 Jul 2005 10:44:16 +0200 Subject: [climacs-devel] latest progress Message-ID: <17110.9696.636875.485496@serveur5.labri.fr> Dear mailing list member, Here is a summary of the progress that has been made since the last progress report. First, as promised, the new Lisp syntax continues to evolve. Lexemes are parsed into Common Lisp symbols and presented as such whenever possible. This opens the possibility of having clickable symbols and/or of having information displayed when the cursor is over a symbol, though not much has been done to exploit that possibility yet. A framework for indentation of Common Lisp code is in place, and indentation functions exist for some common constructs such as defun, defgeneric, defmethod, defclass, with-slots, let, let*, cond, when, unless, and prog1. This indentation framework is smarter than that of Emacs and does not make mistakes when names of CL functions are used as local variables, etc., though Emacs indent function is of course more mature than what Climacs can do at the moment. I encourage everyone to check out this framework and add an indent function for his or her favorite CL construct. The one for `loop' will be quite challenging, but some others can be quite simple, especially since I provide macros to create indent functions for simple constructs. Christophe Rhodes has released his atypical syntax module for editing lute notation. The code is available at this location: http://www.doc.gold.ac.uk/~mas01cr/tabcode-20050708.tar.gz His syntax module is used in the ECOLM project that you can read about here: http://vega.soi.city.ac.uk/~dlewis/.home/ For the ILC2005 presentation, Brian Mastenbrook wrote another atypical syntax module called `slidemacs' which lets the buffer contents be presented as slides. Minor fixes have been made by myself, Brian Mastenbrook, Dan Barlow, Christophe Rhodes Dirk Gerrits reported a bug in undo/redo that has been fixed. Dan Barlow is rumored to be working on cleaning up key bindings, and Aleksandar Bakic is rumored to be working on giving Climacs regex support. -- 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 Jul 19 19:15:46 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 19 Jul 2005 20:15:46 +0100 Subject: [climacs-devel] #\Page etc. Message-ID: <42DD5162.1000603@yahoo.com> Some of the most fun lisp (and other) files to look at/test Climacs with contain #\Page characters. A quick fix for having them display is to treat #\Page (and, while we're at it) #\Return characters as #\Spaces. Simply change the #\Space ecase in the handle-whitespace defun of your favourite syntax(es) to (#\Space #\Page #\Return), and you too can see classic files in Climacs! Notes: 1. This is certain not The Right Way, but it seems to work in the interim. Displaying (presenting) a ^L or #\Page would be better... 2. The characters that satisfy whitespacep on sbcl are #\Space, #\Tab, #\Newline, #\Page and #\Return. JQS From strandh at labri.fr Wed Jul 20 06:05:23 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 20 Jul 2005 08:05:23 +0200 Subject: [climacs-devel] #\Page etc. In-Reply-To: <42DD5162.1000603@yahoo.com> References: <42DD5162.1000603@yahoo.com> Message-ID: <17117.59811.132035.94824@serveur5.labri.fr> John Q Splittist writes: > Some of the most fun lisp (and other) files to look at/test Climacs with > contain #\Page characters. A quick fix for having them display is to > treat #\Page (and, while we're at it) #\Return characters as #\Spaces. > Simply change the #\Space ecase in the handle-whitespace defun of your > favourite syntax(es) to (#\Space #\Page #\Return), and you too can see > classic files in Climacs! Would you have time to submit a patch? > 1. This is certain not The Right Way, but it seems to work in the > interim. Displaying (presenting) a ^L or #\Page would be better... I wonder whether there might be a font that has glyphs for these characters that will fit in the same space as a printing 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 splittist at yahoo.com Wed Jul 20 06:38:09 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 20 Jul 2005 07:38:09 +0100 Subject: [climacs-devel] #\Page etc. In-Reply-To: <17117.59811.132035.94824@serveur5.labri.fr> References: <42DD5162.1000603@yahoo.com> <17117.59811.132035.94824@serveur5.labri.fr> Message-ID: <42DDF151.4050206@yahoo.com> Robert Strandh wrote: > Would you have time to submit a patch? Attached. > > 1. This is certain not The Right Way, but it seems to work in the > > interim. Displaying (presenting) a ^L or #\Page would be better... > > I wonder whether there might be a font that has glyphs for these > characters that will fit in the same space as a printing character. I can imagine that a curly horizontal arrow pointing back on itself for #\Return; what would #\Page look like? JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: space.patch URL: From splittist at yahoo.com Sat Jul 23 23:41:40 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 24 Jul 2005 00:41:40 +0100 Subject: [climacs-devel] Lisp Syntax suggestions Message-ID: <42E2D5B4.3070009@yahoo.com> Folks, As threatened, I attach a patch to lisp-syntax.lisp that: * adds support for the remaining reader macros (except that numbers are punted on [see below], pathnames don't yet require a string, and non-standard reader-macros are assumed to be OK) * adds support for tokens (being numbers, potential numbers and symbols) that include single and multiple escapes (although there is a wee bug-let to stomp I've just noticed when typing incomplete multiply escaped tokens at the end of the buffer...) * interprets tokens with escapes more accurately when trying to determine which symbols they represent It doesn't yet handle numbers in any special way -- indeed, it assumes they are symbols. This makes intelligent handling of, say, complex numbers introduced by the #C reader macro impossible. For now... In general, I've taken the approach that the editor should be far more accepting of possibly erroneous input than the reader, it being not terribly helpful (or performant) to turn everything red at the least provocation. I'm sure it's not pretty lisp. Style etc. suggestions welcomed (like "don't use tagbody, use X instead"). And I'm aware I've implemented bits of the reader twice... I'll keep hacking away at this, but this seemed a good point to share. cheers, JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax.patch URL: From strandh at labri.fr Sun Jul 24 05:30:12 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 24 Jul 2005 07:30:12 +0200 Subject: [climacs-devel] Lisp Syntax suggestions In-Reply-To: <42E2D5B4.3070009@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> Message-ID: <17123.10084.647401.39587@serveur5.labri.fr> When I apply this patch and then try to load lisp-syntax.lisp into a Climacs buffer, Climacs seems to go into an infinite loop. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From splittist at yahoo.com Sun Jul 24 06:56:17 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 24 Jul 2005 07:56:17 +0100 Subject: [climacs-devel] Lisp Syntax suggestions In-Reply-To: <17123.10084.647401.39587@serveur5.labri.fr> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> Message-ID: <42E33B91.40603@yahoo.com> Robert Strandh wrote: > When I apply this patch and then try to load lisp-syntax.lisp into a > Climacs buffer, Climacs seems to go into an infinite loop. Sorry about that -- try this one. (It was your funky |( names* | wot dont it, of course.) This patch replaces the previous one. Like the previous one, it makes two other gratuitous changes: * adds highlighting of &foo forms in +dark-green+ (made it easier to see when that part of display was working properly) * makes Christophe's change to the cursor-drawing code, so the cursor extends from ascender to descender, rather than to the base line). JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-2.patch URL: From asf at boinkor.net Sat Jul 23 20:12:57 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Sat, 23 Jul 2005 22:12:57 +0200 Subject: [climacs-devel] explicit dependencies for climacs.asd Message-ID: <87k6jh8enq.wl%asf@boinkor.net> Hi, here's a patch that adds component dependency information to climacs.asd. I used the same simple list walker that I used on McCLIM, so it's not guaranteed to be 100% correct; it did build & load from scratch, though, so I'm optimistic. This version is a 1:1 translation of the original climacs.asd definition (except for the tests, which I put into the :climacs.tests system). More improvements are possible, e.g. factoring out each of the climacs protocol files and the syntaxes into a separate system. Here's the patch: Index: climacs.asd =================================================================== RCS file: /project/climacs/cvsroot/climacs/climacs.asd,v retrieving revision 1.33 diff -u -r1.33 climacs.asd --- climacs.asd 21 Jul 2005 05:13:51 -0000 1.33 +++ climacs.asd 23 Jul 2005 20:17:19 -0000 @@ -20,61 +20,61 @@ ;;; ASDF system definition for Climacs. -(in-package :common-lisp-user) +(defpackage :climacs.system + (:use :cl :asdf)) + +(in-package :climacs.system) (defparameter *climacs-directory* (directory-namestring *load-truename*)) -(defmacro climacs-defsystem ((module &key depends-on) &rest components) - `(progn - #+mk-defsystem - (mk:defsystem ,module - :source-pathname *climacs-directory* - ,@(and depends-on `(:depends-on ,depends-on)) - :components (:serial , at components)) - #+asdf - (asdf:defsystem ,module - ,@(and depends-on `(:depends-on ,depends-on)) - :serial t - :components (,@(loop for c in components - for p = (merge-pathnames - (parse-namestring c) - (make-pathname :type "lisp" - :defaults *climacs-directory*)) - collect `(:file ,(pathname-name p) :pathname ,p)))))) - -(climacs-defsystem (:climacs :depends-on (:mcclim :flexichain)) - "Persistent/binseq-package" - "Persistent/binseq" - "Persistent/obinseq" - "Persistent/binseq2" - "translate" - "packages" - "buffer" - "Persistent/persistent-buffer" - "base" - "io" - "abbrev" - "syntax" - "text-syntax" - "kill-ring" - "undo" - "delegating-buffer" - "Persistent/persistent-undo" - "pane" - "fundamental-syntax" - "cl-syntax" - "html-syntax" - "prolog-syntax" - "ttcn3-syntax" - "lisp-syntax" - "esa" - "gui" - "slidemacs" - "slidemacs-gui" - ;;---- optional ---- - "testing/rt" - "buffer-test" - "base-test") +(defsystem :climacs + :depends-on (:mcclim :flexichain) + :components + ((:module "Persistent" + :components ((:file "binseq-package") + (:file "binseq" :depends-on ("binseq-package")) + (:file "obinseq" :depends-on ("binseq-package" "binseq")) + (:file "binseq2" :depends-on ("binseq-package" "obinseq" "binseq")))) + + (:file "packages") + (:file "buffer" :depends-on ("packages")) + (:file "persistent-buffer" + :pathname #p"Persistent/persistent-buffer.lisp" + :depends-on ("packages" "buffer" "Persistent")) + + (:file "base" :depends-on ("packages" "buffer" "persistent-buffer")) + (:file "io" :depends-on ("packages" "buffer")) + (:file "abbrev" :depends-on ("packages" "buffer" "base")) + (:file "syntax" :depends-on ("packages" "buffer" "base")) + (:file "text-syntax" :depends-on ("packages" "base" "buffer" "syntax")) + (:file "delegating-buffer" :depends-on ("packages" "buffer")) + (:file "kill-ring" :depends-on ("packages")) + (:file "undo" :depends-on ("packages")) + (:file "persistent-undo" + :pathname #p"Persistent/persistent-undo.lisp" + :depends-on ("packages" "buffer" "persistent-buffer" "undo")) + (:file "pane" :depends-on ("packages" "syntax" "buffer" "base" + "persistent-undo" "persistent-buffer" "abbrev" + "delegating-buffer" "undo")) + (:file "fundamental-syntax" :depends-on ("packages" "syntax" "buffer" "pane" + "base")) + (:file "cl-syntax" :depends-on ("packages" "buffer" "syntax" "base" "pane")) + (:file "html-syntax" :depends-on ("packages" "buffer" "syntax" "base" "pane")) + (:file "prolog-syntax" :depends-on ("packages" "base" "syntax" "pane" "buffer")) + (:file "ttcn3-syntax" :depends-on ("packages" "buffer" "syntax" "base" "pane")) + (:file "lisp-syntax" :depends-on ("packages" "syntax" "buffer" "base" "pane")) + (:file "esa" :depends-on ("packages")) + (:file "gui" :depends-on ("packages" "syntax" "base" "buffer" "undo" "pane" + "esa" "kill-ring" "io" "text-syntax" "abbrev")) + (:file "slidemacs" :depends-on ("packages" "buffer" "syntax" "base" "pane")) + (:file "slidemacs-gui" :depends-on ("packages" "slidemacs" "pane" "buffer" "syntax")))) + +(defsystem :climacs.tests + :depends-on (:climacs) + :components + ((:file "rt" :pathname #p"testing/rt.lisp") + (:file "buffer-test" :depends-on ("rt")) + (:file "base-test" :depends-on ("rt")))) #+asdf (defmethod asdf:perform :around ((o asdf:compile-op) Have fun, -- Andreas Fuchs, , asf at jabber.at, antifuchs From splittist at yahoo.com Sun Jul 24 14:06:24 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 24 Jul 2005 15:06:24 +0100 Subject: [climacs-devel] Re: explicit dependencies for climacs.asd In-Reply-To: <87k6jh8enq.wl%asf@boinkor.net> References: <87k6jh8enq.wl%asf@boinkor.net> Message-ID: <42E3A060.9050203@yahoo.com> Andreas Fuchs wrote: > here's a patch that adds component dependency information to > climacs.asd. I had to add a dependency for "packages" on "/Persistent/binseq-package", which I did by doing: (:file "binseq-package" :pathname #p"Persistent/binseq-package") (:file "packages" :depends-on ("binseq-package")) after the definition of the "Persistent" module. I'm sure this is not the right way, but it worked to get climacs loaded. JQS From asf at boinkor.net Sun Jul 24 14:25:52 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 24 Jul 2005 16:25:52 +0200 Subject: [climacs-devel] Re: explicit dependencies for climacs.asd In-Reply-To: <42E3A060.9050203@yahoo.com> References: <87k6jh8enq.wl%asf@boinkor.net> <42E3A060.9050203@yahoo.com> Message-ID: <87k6jgwaa7.wl%asf@boinkor.net> Today, John Q. Splittist wrote: > I had to add a dependency for "packages" on > "/Persistent/binseq-package", which I did by doing: > > (:file "binseq-package" > :pathname #p"Persistent/binseq-package") > (:file "packages" :depends-on ("binseq-package")) > > after the definition of the "Persistent" module. I'm sure this is > not the right way, but it worked to get climacs loaded. I suggest just adding a dependency from "packages" to the "Persistent" module, instead. Code: (:module "Persistent" :components ((:file "binseq-package") (:file "binseq" :depends-on ("binseq-package")) (:file "obinseq" :depends-on ("binseq-package" "binseq")) (:file "binseq2" :depends-on ("binseq-package" "obinseq" "binseq")))) (:file "packages" :depends-on ("Persistent")) Thanks for spotting this. Hope this fix works (-: -- Andreas Fuchs, , asf at jabber.at, antifuchs From splittist at yahoo.com Mon Jul 25 06:56:33 2005 From: splittist at yahoo.com (John Q Splittist) Date: Mon, 25 Jul 2005 07:56:33 +0100 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E33B91.40603@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> Message-ID: <42E48D21.9050302@yahoo.com> This morning's patch: * fixes a problem with the multiple-escape code (and now it should really be finished, and this time I mean it...) * introduces an interim indent method for multiple-escape forms JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-3.patch URL: From splittist at yahoo.com Mon Jul 25 19:56:31 2005 From: splittist at yahoo.com (John Q Splittist) Date: Mon, 25 Jul 2005 20:56:31 +0100 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E48D21.9050302@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> Message-ID: <42E543EF.1050109@yahoo.com> More Lisp Syntax stuff. This patch: * fixes presentations of multi-token symbols and strings * introduces a new presentation type, the 'unknown-symbol, for symbol tokens that haven't got a package in the image (because, eg. the file hasn't been loaded) * introduces a new presentation type, the 'lisp-string, for strings in the file surrounded by #\"s * presents every token as a 'string. Also included is a presentation translator from 'lisp-string to 'string that doesn't work. It ought to, and I seem to have got back into the gesture/pointer-event code with things still making (to me) sense, so I'd be grateful if someone could check whether it works for them. Things to play with: * M-x Accept String (most things mouseable) * M-x Accept Symbol (see what the system can find, and where - 'symbols are returned as the actual symbol; 'unknown-symbols are returned as strings * M-x Accept Lisp String (source code strings are mouseable) * M-% [being Query Replace], then mouse and click to choose the strings! Things to think about: * Should 'string be for actual lisp strings, and (say) ESA-string (or editor-string) be for sequences of objects in the buffer? This makes sense to me, as some commands that accept a sequence of objects from the buffer might be usable in non-text-editor contexts. (Simply changing commands like com-query-replace from (accept 'string ...) to (accept 'esa-string ...), and changing a couple of things in lisp-syntax, would work.) * What other things might it be useful to mouse around with? * Is there a natural meaning for simply clicking on something in the buffer? Things to do: * (still!) Numbers * work out why the presentation translator isn't working... JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-4.patch URL: From splittist at yahoo.com Wed Jul 27 14:34:33 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 27 Jul 2005 15:34:33 +0100 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E543EF.1050109@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> Message-ID: <42E79B79.9030008@yahoo.com> John Q Splittist wrote: > Also included is a presentation translator from 'lisp-string to 'string > that doesn't work. Now it works. Patch attached. I'm still wondering about string vs. lisp-string. On the one hand, string really does represent a lisp string. On the other hand, I can imagine wanting prolog-string, c-string, etc (in sufficiently sophisticated circumstances). JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-5.patch URL: From strandh at labri.fr Thu Jul 28 04:41:20 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 28 Jul 2005 06:41:20 +0200 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E79B79.9030008@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> <42E79B79.9030008@yahoo.com> Message-ID: <17128.25072.281178.926094@serveur5.labri.fr> Hello, This patch did not work because it does not seem to be a diff with respect to what is now the latest version in CVS (there are hunks marked with `+' that are already in CVS). Could you send a more recent one? Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From splittist at yahoo.com Thu Jul 28 06:08:43 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 28 Jul 2005 07:08:43 +0100 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <17128.25072.281178.926094@serveur5.labri.fr> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> <42E79B79.9030008@yahoo.com> <17128.25072.281178.926094@serveur5.labri.fr> Message-ID: <42E8766B.4080306@yahoo.com> Robert Strandh wrote: > Hello, > > This patch did not work because it does not seem to be a diff with > respect to what is now the latest version in CVS Herewith. Like the last one, produced with cvs diff -u. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-5b.patch URL: From strandh at labri.fr Thu Jul 28 13:50:59 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 28 Jul 2005 15:50:59 +0200 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E8766B.4080306@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> <42E79B79.9030008@yahoo.com> <17128.25072.281178.926094@serveur5.labri.fr> <42E8766B.4080306@yahoo.com> Message-ID: <17128.58051.682077.469512@serveur5.labri.fr> Hello, John Q Splittist writes: > Robert Strandh wrote: > > Hello, > > > > This patch did not work because it does not seem to be a diff with > > respect to what is now the latest version in CVS > > Herewith. Like the last one, produced with cvs diff -u. Are you sure? See my remarks below... > + (:command-table (global-climacs-table :inherit-from (global-esa-table))) > + (:menu-bar nil) OK, this one works > -(make-command-table 'global-climacs-table :errorp nil :inherit-from '(global-esa-table)) > - This one too > +(define-gesture-name :select-other :pointer-button-press (:left :meta) :unique nil) > + > +(define-presentation-translator lisp-string-to-string > + (climacs-lisp-syntax::lisp-string string global-climacs-table > + :gesture :select-other > + :tester-definitive t > + :menu nil > + :priority 10) > + (object) > + object) > + This bunch is already in the file except with a 10 instead of 11, so why is this code marked with `+'? > +(define-named-command com-accept-lisp-string () > + (display-message (format nil "~s" (accept 'lisp-string)))) This one is already in there too, except marked with lisp-syntax::lisp-string. > +(define-presentation-type unknown-symbol () :inherit-from 'symbol > + :description "unknown symbol") > + > +(define-presentation-method presentation-typep (object (type unknown-symbol)) > + (or (symbolp object) (stringp object))) > + Same with this. > - (cond ((eql (buffer-object (buffer syntax) (start-offset parse-symbol)) #\:) > - (with-drawing-options (pane :ink +dark-violet+) > - (call-next-method))) > - ((eql (buffer-object (buffer syntax) (start-offset parse-symbol)) #\&) > - (with-drawing-options (pane :ink +dark-green+) > - (call-next-method))) > - (t (call-next-method))) > + (let ((string (coerce (buffer-sequence (buffer syntax) > + (start-offset parse-symbol) > + (end-offset parse-symbol)) > + 'string))) > + (multiple-value-bind (symbol status) > + (token-to-symbol syntax parse-symbol) > + (with-output-as-presentation > + (pane (if status symbol string) (if status 'symbol 'unknown-symbol) > + :single-box :highlighting) > + (cond ((eql (buffer-object (buffer syntax) (start-offset parse-symbol)) #\:) > + (with-drawing-options (pane :ink +dark-violet+) > + (call-next-method))) > + ((eql (buffer-object (buffer syntax) (start-offset parse-symbol)) #\&) > + (with-drawing-options (pane :ink +dark-green+) > + (call-next-method))) > + (t (call-next-method))) > + ))) The code in CVS looks more like the one marked with `+' than the one marked with `-' > - (multiple-value-bind (symbol status) > - (token-to-symbol syntax parser-symbol) > - (declare (ignore symbol)) > - (if (and status (typep parser-symbol 'form)) > - (present string 'symbol :stream pane) > - (present string 'string :stream pane)))))))) > - > + (present string 'string :stream pane)))))) > + This does not look familiar at all. > +(define-presentation-type lisp-string () > + :description "lisp string") > + This one is already in there > (defmethod display-parse-tree ((parse-symbol complete-string-form) (syntax lisp-syntax) pane) > (let ((children (children parse-symbol))) > - (display-parse-tree (pop children) syntax pane) > - (with-text-face (pane :italic) > - (loop until (null (cdr children)) > - do (display-parse-tree (pop children) syntax pane))) > - (display-parse-tree (pop children) syntax pane))) > + (if (third children) > + (let ((string (coerce (buffer-sequence (buffer syntax) > + (start-offset (second children)) > + (end-offset (car (last children 2)))) > + 'string))) > + (with-output-as-presentation (pane string 'lisp-string > + :single-box :highlighting) > + (display-parse-tree (pop children) syntax pane) > + (with-text-face (pane :italic) > + (loop until (null (cdr children)) > + do (display-parse-tree (pop children) syntax pane))) > + (display-parse-tree (pop children) syntax pane))) > + (progn (display-parse-tree (pop children) syntax pane) > + (display-parse-tree (pop children) syntax pane))))) The code in CVS looks more like the one marked with `+' than the one marked with `-'. > - (display-parse-tree (pop children) syntax pane) > - (with-text-face (pane :italic) > - (loop until (null children) > - do (display-parse-tree (pop children) syntax pane))))) > + (if (second children) > + (let ((string (coerce (buffer-sequence (buffer syntax) > + (start-offset (second children)) > + (end-offset (car (last children)))) > + 'string))) > + (with-output-as-presentation (pane string 'lisp-string > + :single-box :highlighting) > + (display-parse-tree (pop children) syntax pane) > + (with-text-face (pane :italic) > + (loop until (null children) > + do (display-parse-tree (pop children) syntax pane))))) > + (display-parse-tree (pop children) syntax pane)))) same here. > - (:export)) > + (:export :lisp-string)) This one might work. > - :climacs-kill-ring :climacs-pane :clim-extensions :undo :esa)) > + :climacs-kill-ring :climacs-pane :clim-extensions :undo :esa) > + (:import-from :climacs-lisp-syntax :lisp-string)) This one 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 splittist at yahoo.com Thu Jul 28 19:25:58 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 28 Jul 2005 20:25:58 +0100 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <17128.58051.682077.469512@serveur5.labri.fr> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> <42E79B79.9030008@yahoo.com> <17128.25072.281178.926094@serveur5.labri.fr> <42E8766B.4080306@yahoo.com> <17128.58051.682077.469512@serveur5.labri.fr> Message-ID: <42E93146.1010304@yahoo.com> Robert Strandh wrote: > > Herewith. Like the last one, produced with cvs diff -u. > > Are you sure? Am I sure that the attached was the output of cvs diff -u typed a couple of minutes before I sent the message? Yes. But CVS isn't magic, so I've done it again this afternoon, and the results are now consistent with your comments. (And I note that Robert has now moved the keyboard macro code into ESA, which I wasn't seeing in CVS this morning.) I am aware that Robert is travelling over the next few days, so if he doesn't commit these changes (or take issue with them!) in the next little while I will. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lisp-syntax-5c.patch URL: From strandh at labri.fr Thu Jul 28 20:22:41 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 28 Jul 2005 22:22:41 +0200 Subject: [climacs-devel] Re: Lisp Syntax suggestions In-Reply-To: <42E93146.1010304@yahoo.com> References: <42E2D5B4.3070009@yahoo.com> <17123.10084.647401.39587@serveur5.labri.fr> <42E33B91.40603@yahoo.com> <42E48D21.9050302@yahoo.com> <42E543EF.1050109@yahoo.com> <42E79B79.9030008@yahoo.com> <17128.25072.281178.926094@serveur5.labri.fr> <42E8766B.4080306@yahoo.com> <17128.58051.682077.469512@serveur5.labri.fr> <42E93146.1010304@yahoo.com> Message-ID: <17129.16017.474731.597085@serveur5.labri.fr> John Q Splittist writes: > I am aware that Robert is travelling over the next few days, so if he > doesn't commit these changes (or take issue with them!) in the next > little while I will. Please do! -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------