From splittist at yahoo.com Tue May 3 17:30:43 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 03 May 2005 18:30:43 +0100 Subject: [climacs-devel] Pathnames and cl-fad Message-ID: <4277B543.8090707@yahoo.com> Wondering why the Find File completion was funky on my openmcl+clx climacs, and after a delightful tour through the mcclim completion code, I realised that it's because (directory ...) on openmcl requires :directories t to list directories. I made a start on adding this to gui.lisp, but I've ended up just replicating a portion of cl-fad (http://www.weitz.de/cl-fad/). I should really have gone further and conditionalized wildcard as well, and then further back... Is there any benefit to adding cl-fad as a dependency, or just adding cl-fad to the climacs distribution? (Or does it really live at the McClim level?) Anywho, a diff is attached. Not tested on all the lisps listed. JQS --- gui.lisp.~1.128.~ Sat Mar 19 22:08:31 2005 +++ gui.lisp Tue May 3 18:13:47 2005 @@ -621,9 +623,17 @@ (full-so-far (concatenate 'string directory-prefix so-far)) (pathnames (loop with length = (length full-so-far) - for path in (directory (concatenate 'string - (remove-trail so-far) - "*.*")) + and wildcard = (concatenate 'string (remove-trail so-far) "*.*") + for path in + #+(or :sbcl :cmu :lispworks) (directory wildcard) + #+:openmcl (directory wildcard :directories t) + #+:allegro (directory wildcard :directories-are-files nil) + #+:clisp (nconc (directory wildcard) + (directory (clisp-subdirectories-wildcard wildcard))) + #+:cormanlisp (nconc (directory wildcard) + (cl::directory-subdirs dirname)) + #-(or :sbcl :cmu :lispworks :openmcl :allegro :clisp :cormanlisp) + (directory wildcard) when (let ((mismatch (mismatch (namestring path) full-so-far))) (or (null mismatch) (= mismatch length))) collect path)) From splittist at yahoo.com Tue May 3 18:45:10 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 03 May 2005 19:45:10 +0100 Subject: [climacs-devel] Re: Pathnames and cl-fad In-Reply-To: <4277B543.8090707@yahoo.com> References: <4277B543.8090707@yahoo.com> Message-ID: <4277C6B6.2080005@yahoo.com> John Q Splittist wrote: > Anywho, a diff is attached. Not tested on all the lisps listed. And complete rubbish it is, being the product of an earlier cut-n-paste. Sorry about that. Try this one. JQS --- gui.lisp.~1.128.~ Sat Mar 19 22:08:31 2005 +++ gui.lisp Tue May 3 19:43:44 2005 @@ -621,9 +625,15 @@ (full-so-far (concatenate 'string directory-prefix so-far)) (pathnames (loop with length = (length full-so-far) - for path in (directory (concatenate 'string - (remove-trail so-far) - "*.*")) + and wildcard = (concatenate 'string (remove-trail so-far) "*.*") + for path in + #+(or :sbcl :cmu :lispworks) (directory wildcard) + #+:openmcl (directory wildcard :directories t) + #+:allegro (directory wildcard :directories-are-files nil) + #+:cormanlisp (nconc (directory wildcard) + (cl::directory-subdirs dirname)) + #-(or :sbcl :cmu :lispworks :openmcl :allegro :cormanlisp) + (directory wildcard) when (let ((mismatch (mismatch (namestring path) full-so-far))) (or (null mismatch) (= mismatch length))) collect path)) From splittist at yahoo.com Tue May 3 18:47:25 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 03 May 2005 19:47:25 +0100 Subject: [climacs-devel] Line and column number display Message-ID: <4277C73D.2040207@yahoo.com> More useless aesthetic fiddling (cf. my Isearch feedback code, in the moderator queue because I brilliantly managed to send it before my subscription verification): adding line and column numbers to the status display. I've added 1 to the buffer-line-number return value, because a line-number of 0 seems wrong (and contrary to Emacs), but perhaps I've missed a trick here. JQS --- gui.lisp.~1.128.~ Sat Mar 19 22:08:31 2005 +++ gui.lisp Tue May 3 19:43:44 2005 @@ -125,9 +125,13 @@ (declare (ignore frame)) (with-slots (climacs-pane) pane (let* ((buf (buffer climacs-pane)) - (name-info (format nil " ~a ~a Syntax: ~a~a~a~a ~a" + (point-offset (offset (point climacs-pane))) + (tab-width (tab-space-count (stream-default-view climacs-pane))) + (name-info (format nil " ~a ~a ~10<(~a,~a)~> Syntax: ~a~a~a~a ~a" (if (needs-saving buf) "**" "--") (name buf) + (1+ (buffer-line-number buf point-offset)) + (buffer-display-column buf point-offset tab-width) (name (syntax buf)) (if (slot-value climacs-pane 'overwrite-mode) " Ovwrt" From a_bakic at yahoo.com Tue May 3 20:55:41 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 3 May 2005 13:55:41 -0700 (PDT) Subject: [climacs-devel] Line and column number display In-Reply-To: <4277C73D.2040207@yahoo.com> Message-ID: <20050503205542.22464.qmail@web40611.mail.yahoo.com> > adding line and column numbers to the status display. I'm afraid that this one has to wait until I make standard-buffer work faster with lines and columns. (Something similar used to be there but was removed for performance reasons.) Regards, Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From splittist at yahoo.com Wed May 4 07:38:51 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 04 May 2005 08:38:51 +0100 Subject: [climacs-devel] Point - buffer or pane? (plus syntax resetting) Message-ID: <42787C0B.5060609@yahoo.com> Currently point is kept in the climacs-pane object. While this means one can have multiple panes on the same buffer with different points, it does mean that switching buffers in the same pane loses the point information, so point is always reset. Below are some changes to pane.lisp that move point to the climacs-buffer object. This has the effect of _not_ resetting point when doing a com-switch-to-buffer. Of course, when you com-split-window-*, there is only one point for each of the panes, so the cursors follow one another. Interesting redisplay features can be observed. Presumably the right thing to do is have one point (and mark, and perhaps other things - isearch, query-replace?) per buffer per pane. On a com-split-window the new pane could be given some kind of proxy climacs-buffer pointing to the original, but with its own state. Or maybe I'm barking up the wrong tree. Anyway, consider this a quick fix for the annoyance of losing one's place in a file when switching buffers. Also, by commenting out lines in com-switch-to-buffer (in gui.lisp) as follows, a syntax reset can be avoided on c-x b as well: (define-named-command com-switch-to-buffer () (let ((buffer (accept 'buffer :prompt "Switch to buffer")) (pane (current-window))) (setf (buffer pane) buffer) ; (setf (syntax buffer) (make-instance ; 'basic-syntax :buffer (buffer (point pane)))) ; (beginning-of-buffer (point pane)) (full-redisplay pane))) JQS --- pane.lisp.~1.24.~ Wed Apr 6 06:31:53 2005 +++ pane.lisp Wed May 4 07:46:08 2005 @@ -193,7 +193,10 @@ (defclass extended-binseq2-buffer (binseq2-buffer p-undo-mixin abbrev-mixin) () (:documentation "Extensions accessible via marks.")) -(defclass climacs-buffer (delegating-buffer filename-mixin name-mixin) +(defclass point-mixin () + ((point :initform nil :initarg :point :accessor point))) + +(defclass climacs-buffer (delegating-buffer filename-mixin name-mixin point-mixin) ((needs-saving :initform nil :accessor needs-saving) (syntax :accessor syntax) (indent-tabs-mode :initarg indent-tabs-mode :initform t @@ -210,7 +213,6 @@ (defclass climacs-pane (application-pane) ((buffer :initform (make-instance 'climacs-buffer) :accessor buffer) - (point :initform nil :initarg :point :reader point) (mark :initform nil :initarg :mark :accessor mark) (top :reader top) (bot :reader bot) @@ -231,6 +233,12 @@ (insert* cache 0 nil) cache)))) +(defmethod point ((pane climacs-pane)) + (point (buffer pane))) + +(defmethod (setf point) (mark (pane climacs-pane)) + (setf (point (buffer pane)) mark)) + (defmethod tab-width ((pane climacs-pane)) (tab-width (stream-default-view pane))) @@ -239,9 +247,9 @@ (defmethod initialize-instance :after ((pane climacs-pane) &rest args) (declare (ignore args)) - (with-slots (buffer point mark) pane - (when (null point) - (setf point (clone-mark (low-mark buffer) :right))) + (with-slots (buffer mark) pane + (when (null (point pane)) + (setf (point pane) (clone-mark (low-mark buffer) :right))) (when (null mark) (setf mark (clone-mark (low-mark buffer) :right)))) (with-slots (buffer top bot scan) pane @@ -255,11 +263,12 @@ tab-width (* 8 space-width))))) (defmethod (setf buffer) :after (buffer (pane climacs-pane)) - (with-slots (point mark top bot) pane - (setf point (clone-mark (low-mark buffer) :right) - mark (clone-mark (low-mark buffer) :right) - top (clone-mark (low-mark buffer) :left) - bot (clone-mark (high-mark buffer) :right)))) + (with-slots (mark top bot) pane + (unless (point pane) + (setf (point pane) (clone-mark (low-mark buffer) :right))) + (setf mark (clone-mark (low-mark buffer) :right) + top (clone-mark (low-mark buffer) :left) + bot (clone-mark (high-mark buffer) :right)))) (define-presentation-type url () :inherit-from 'string) From splittist at yahoo.com Sun May 1 17:41:01 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 01 May 2005 18:41:01 +0100 Subject: [climacs-devel] Isearch feedback Message-ID: <427514AD.8040503@yahoo.com> Hi, To celebrate getting climacs to run (openmcl 0.14.3, clx) I had a go at adding some minibuffer feedback for the Isearch functions. A diff is attached. Some questions: 1. Is this actually a useful thing for me to do? 2. Is this the right form of diff? 3. Is (display-message ..) the way to go for this kind of thing? (It almost seems too easy...) Loading an edited gui file into a running climacs and seeing the changes instantly (or as close to instantly as climacs gets, these days) is very cool! cheers, JQS --- gui.lisp.~1.128.~ Sat Mar 19 22:08:31 2005 +++ gui.lisp Sun May 1 17:23:22 2005 @@ -1086,6 +1086,7 @@ (offset mark) (if forwardp (- (offset mark2) (length string)) (+ (offset mark2) (length string))))) + (display-message "~:[Failing ~;~]Isearch~:[ backward~;~]: ~A" success forwardp string) (push (make-instance 'isearch-state :search-string string :search-mark mark @@ -1096,9 +1097,11 @@ (beep))))) (define-named-command com-isearch-mode-forward () + (display-message "Isearch: ") (isearch-command-loop (current-window) t)) (define-named-command com-isearch-mode-backward () + (display-message "Isearch backward: ") (isearch-command-loop (current-window) nil)) (define-named-command com-isearch-append-char () @@ -1116,7 +1119,8 @@ (define-named-command com-isearch-delete-char () (let* ((pane (current-window))) (cond ((null (second (isearch-states pane))) - (beep)) + (display-message "Isearch: ") + (beep)) (t (pop (isearch-states pane)) (loop until (endp (rest (isearch-states pane))) @@ -1128,7 +1132,10 @@ (+ (offset (search-mark state)) (length (search-string state))) (- (offset (search-mark state)) - (length (search-string state)))))))))) + (length (search-string state))))) + (display-message "Isearch~:[ backward~;~]: ~A" + (search-forward-p state) + (search-string state))))))) (define-named-command com-isearch-forward () (let* ((pane (current-window)) From nicolas.sceaux at free.fr Wed May 4 11:15:41 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Wed, 04 May 2005 13:15:41 +0200 Subject: [climacs-devel] regex Message-ID: <87sm13b5sy.fsf@free.fr> Hello, Some months ago, there was a discussion about adapting cl-ppcre for use with climacs buffers iso. plain strings. http://common-lisp.net/pipermail/climacs-devel/2005-January/000077.html I would like to know if maybe someone (Lawrence?) had got some results, and eventually some advices to give, before putting my noze inside the beast. Writing lexers (ie, the NEXT-LEXEME method) is not exactly trivial with complicated syntaxes; having something like emacs' looking-at function might make that task a bit easier. Regards, Nicolas From wencel at gmail.com Wed May 4 16:09:21 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Wed, 04 May 2005 17:09:21 +0100 Subject: [climacs-devel] Re: regex References: <87sm13b5sy.fsf@free.fr> Message-ID: Hi there, Nicolas Sceaux wrote: > Hello, > Some months ago, there was a discussion about adapting cl-ppcre for > use with climacs buffers iso. plain strings. > http://common-lisp.net/pipermail/climacs-devel/2005-January/000077.html > I would like to know if maybe someone (Lawrence?) had got some > results, and eventually some advices to give, before putting my noze > inside the beast. I started looking at this, and then, unfortunately, real life intervened, so I haven't had much of a chance to get things working. I had a very trivial proof-of-concept implementation that just turned buffers into strings and then matched on them, obviously, this is far from ideal. After discussing alternatives here and with Edi, it seems like the way forward is to modify cl-ppcre to change all occurances of (SCHAR *STRING* ...) and the like in the sources to some function that returns a character in a Climacs buffer. That is, rather than doing (scan regex string) and then matching in string, do (scan regex buffer) and somehow match in buffer. This is around the point that I got not much further. I didn't manage to figure out a way to make this work nicely and didn't get round to figuring out what was wrong before other work intervened. Sorry not to have any better news really, I'll probably have more time come the end of May but won't really be able to look at things before that. I can send you what I do have (non-working) so far if you're interested. cheers, Lawrence From a_bakic at yahoo.com Wed May 4 23:15:15 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Wed, 4 May 2005 16:15:15 -0700 (PDT) Subject: [climacs-devel] Point - buffer or pane? (plus syntax resetting) In-Reply-To: <42787C0B.5060609@yahoo.com> Message-ID: <20050504231515.42438.qmail@web40623.mail.yahoo.com> Hi, Sounds fine to me, but I need to check the archive first. I think there were some discussions on where point and friends should belong. As for the syntax reset, I am not familiar enough with syntax-related code to approve this change at the moment. Regarding your Isearch-related post: > 1. Is this actually a useful thing for me to do? My guess is that things like this are useful to other users, too. I'm not sure if I understood the question. > 2. Is this the right form of diff? The form is probably fine, but the line numbers did not match, so I patched gui.lisp manually. > 3. Is (display-message ..) the way to go for this kind of thing? (It almost seems too easy...) I don't know, it seems to work. I saw similar uses of display-message, too. Thanks, Alex __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From nicolas.sceaux at free.fr Thu May 5 10:09:13 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Thu, 05 May 2005 12:09:13 +0200 Subject: [climacs-devel] Re: regex In-Reply-To: (Lawrence Mitchell's message of "Wed, 04 May 2005 17:09:21 +0100") References: <87sm13b5sy.fsf@free.fr> Message-ID: <87psw6ougm.fsf@free.fr> Lawrence Mitchell writes: > After discussing alternatives here and with Edi, it seems like > the way forward is to modify cl-ppcre to change all occurances of > (SCHAR *STRING* ...) and the like in the sources to some function > that returns a character in a Climacs buffer. > > That is, rather than doing (scan regex string) and then matching > in string, do (scan regex buffer) and somehow match in buffer. > This is around the point that I got not much further. I didn't > manage to figure out a way to make this work nicely and didn't > get round to figuring out what was wrong before other work > intervened. > > Sorry not to have any better news really, I'll probably have more > time come the end of May but won't really be able to look at > things before that. I can send you what I do have (non-working) > so far if you're interested. Yes please. I have a few ideas, and would like to see if you took the same direction, or another path. From csr21 at cam.ac.uk Thu May 5 10:29:45 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 05 May 2005 11:29:45 +0100 Subject: [climacs-devel] Point - buffer or pane? (plus syntax resetting) In-Reply-To: <20050504231515.42438.qmail@web40623.mail.yahoo.com> (Aleksandar Bakic's message of "Wed, 4 May 2005 16:15:15 -0700 (PDT)") References: <20050504231515.42438.qmail@web40623.mail.yahoo.com> Message-ID: Aleksandar Bakic writes: > Hi, > > Sounds fine to me, but I need to check the archive first. I think > there were some discussions on where point and friends should > belong. As for the syntax reset, I am not familiar enough with > syntax-related code to approve this change at the moment. >From what I understand, I think that the change is right: buffers should keep their syntax even if they are buried and re-exposed. A simple test case: visit foo.html in HTML Syntax, then C-x b to *scratch*, then C-x b back to foo.html. I would expect the HTML syntax to be preserved, but at present it isn't. Cheers, Christophe From csr21 at cam.ac.uk Thu May 5 11:02:10 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 05 May 2005 12:02:10 +0100 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: (Ignas Mikalajunas's message of "Thu, 28 Apr 2005 13:23:31 +0300") References: Message-ID: Ignas Mikalajunas writes: > It tries to open my home directory and of course fails (I know there > is no dired, but crashing my editor because of that is evil) I've made climacs more resilient to unhandled lisp errors: there is now a return-to-climacs restart around the command loop. I'm not yet entirely happy with my implementation of it, but it seems to work well enough. The restart doesn't currently wrap redisplay; maybe it should. Cheers, Christophe From nicolas.sceaux at free.fr Thu May 5 14:21:51 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Thu, 05 May 2005 16:21:51 +0200 Subject: [climacs-devel] Re: regex In-Reply-To: (Lawrence Mitchell's message of "Wed, 04 May 2005 17:09:21 +0100") References: <87sm13b5sy.fsf@free.fr> Message-ID: <87is1xpxc0.fsf@free.fr> Lawrence Mitchell writes: > After discussing alternatives here and with Edi, it seems like > the way forward is to modify cl-ppcre to change all occurances of > (SCHAR *STRING* ...) and the like in the sources to some function > that returns a character in a Climacs buffer. > > That is, rather than doing (scan regex string) and then matching > in string, do (scan regex buffer) and somehow match in buffer. OK, I think I managed to have SCAN do its job on a buffer instead of a string. On a fresh image: ---- test.lisp ---- (in-package :common-lisp-user) (defpackage :climacs-buffer (:use #:cl) (:export #:buffer #:size #:buffer-object #:buffer-substring)) (in-package :climacs-buffer) ;;; fake buffer implementation, for testing (defclass buffer () ((contents :initarg :contents))) (defmethod size ((buffer buffer)) (length (slot-value buffer 'contents))) (defmethod buffer-object ((buffer buffer) offset) (aref (slot-value buffer 'contents) offset)) (defmethod buffer-substring ((buffer buffer) start &optional (end (size buffer))) (subseq (slot-value buffer 'contents) start end)) (in-package :common-lisp-user) (defvar *buffer* (make-instance 'climacs-buffer:buffer :contents " salut les amis. Comment allez-vous tous les 4 ?")) (pushnew :climacs-ppcre *features*) (asdf:oos 'asdf:compile-op :cl-ppcre) (asdf:oos 'asdf:load-op :cl-ppcre) ---- test.lisp ---- ;;;; Compile file /home/nicolas/lisp/climacs-ppcre/test.lisp ... ... CL-USER> (cl-ppcre:scan "\\w+\\s+(\\d+)" *buffer*) 41 46 #(45) #(46) CL-USER> (climacs-buffer:buffer-substring *buffer* 41 46) "les 4" which seems not bad. I'll clean a bit my hacks on CL-PPCRE and then send them here. Nicolas From splittist at yahoo.com Thu May 5 20:17:25 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 05 May 2005 21:17:25 +0100 Subject: [climacs-devel] Re: Point - buffer or pane? (plus syntax resetting) In-Reply-To: References: <20050504231515.42438.qmail@web40623.mail.yahoo.com> Message-ID: <427A7F55.9060701@yahoo.com> Christophe Rhodes wrote: > Aleksandar Bakic writes: >>Sounds fine to me, but I need to check the archive first. I think >>there were some discussions on where point and friends should >>belong. I remember something of the same, but I don't think it was on this list -- perhaps one of the earlier cl-emacs efforts? >> As for the syntax reset, I am not familiar enough with >>syntax-related code to approve this change at the moment. > > From what I understand, I think that the change is right: buffers > should keep their syntax even if they are buried and re-exposed. A > simple test case: visit foo.html in HTML Syntax, then C-x b to > *scratch*, then C-x b back to foo.html. I would expect the HTML > syntax to be preserved, but at present it isn't. I think it's safe to remove the syntax reset (ie. the setf on the buffer's syntax slot) in com-switch-to-buffer (and com-find-file, FWIW) -- even if you're switching to a new buffer (should a fresh buffer really be created?) (or finding a new file) a buffer is initialised with a fresh basic-syntax by an :after method on initialize-instance in pane.lisp. Which is a convoluted way of saying: since it's already impossible to have a buffer without a syntax, the only command which should touch the syntax is Set Syntax (at the moment); Switch To Buffer and Find File should leave it alone. JQS From splittist at yahoo.com Fri May 6 20:15:10 2005 From: splittist at yahoo.com (John Q Splittist) Date: Fri, 06 May 2005 21:15:10 +0100 Subject: [climacs-devel] Re: Pathnames In-Reply-To: <4277C6B6.2080005@yahoo.com> References: <4277B543.8090707@yahoo.com> <4277C6B6.2080005@yahoo.com> Message-ID: <427BD04E.6060900@yahoo.com> I propose that the 'filename' slot of a buffer be renamed 'filepath'. This is because it really does hold the path relating to the file whose contents are in the buffer, and because it allows an easier distinction between the place in the filesystem of the buffer (the filepath), and the textual name of the buffer when the buffer corresponds to a file (being the path-name.path-type of the filepath). This is only a terminological change, but it might save some confusion later on. Certainly it makes the pathname-filename function make more sense: at the moment it gets called on the filename to produce... the filname; when renamed as filepath-filename it's called on the filepath to produce the filename. Well, it makes it easier for me to understand. A hopefully working diff is attached. (That is, the change works, and I hope the diff does.) JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filepath.patch URL: From splittist at yahoo.com Fri May 6 21:41:31 2005 From: splittist at yahoo.com (John Q Splittist) Date: Fri, 06 May 2005 22:41:31 +0100 Subject: [climacs-devel] Re: cl-fad In-Reply-To: <4277B543.8090707@yahoo.com> References: <4277B543.8090707@yahoo.com> Message-ID: <427BE48B.1040300@yahoo.com> John Q Splittist wrote: > I made a start on adding this to gui.lisp, but I've ended up just > replicating a portion of cl-fad (http://www.weitz.de/cl-fad/). > ... Is there any benefit to adding cl-fad as a dependency, > or just adding cl-fad to the climacs distribution? (Or does it really > live at the McClim level?) I've tried adding cl-fad as a dependency (just added to the modules in the .asd), and used its facilities to do a bit more error checking on the commands that use filenames/filepaths (e.g. trying to write to a directory doesn't blow up any more). One thing I'm not sure of is whether there is a mismatch between the lisps supported by cl-fad and those supported by climacs. (cl-fad supports CMUCL, Corman, Allegro, CLISP, LW, openmcl and SBCL.) Diff attached. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cl-fad.patch URL: From a_bakic at yahoo.com Fri May 6 22:40:53 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 6 May 2005 15:40:53 -0700 (PDT) Subject: [climacs-devel] Point - buffer or pane? (plus syntax resetting) In-Reply-To: <42787C0B.5060609@yahoo.com> Message-ID: <20050506224054.93048.qmail@web40604.mail.yahoo.com> > Presumably the right thing to do is have one point (and mark, and > perhaps other things - isearch, query-replace?) per buffer per pane. On > a com-split-window the new pane could be given some kind of proxy > climacs-buffer pointing to the original, but with its own state. I looked at the archive: the discussions I had mentioned were on overwrite-mode and goal-column. I'd suggest that you take a look at climacs-buffer and delegating-buffer classes, and see if you can create a proxy climacs-buffer by reusing the implementation slot. Also, try to "close over" the things that should be moved from climacs-pane to climacs-buffer (the things you mention in parentheses). Alex __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From strandh at labri.fr Sat May 7 07:50:43 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 7 May 2005 09:50:43 +0200 Subject: [climacs-devel] Point - buffer or pane? (plus syntax resetting) In-Reply-To: <42787C0B.5060609@yahoo.com> References: <42787C0B.5060609@yahoo.com> Message-ID: <17020.29523.523623.585893@serveur5.labri.fr> Hello, John Q Splittist writes: > Currently point is kept in the climacs-pane object. While this means one > can have multiple panes on the same buffer with different points, it > does mean that switching buffers in the same pane loses the point > information, so point is always reset. Actually, the good way of doing it is to have a point both in the pane and in the buffer. When a pane is about to change the buffer on display, the point is saved in the old buffer and loaded from the new buffer. > Below are some changes to pane.lisp that move point to the > climacs-buffer object. This has the effect of _not_ resetting point when > doing a com-switch-to-buffer. Of course, when you com-split-window-*, > there is only one point for each of the panes, so the cursors follow one > another. Interesting redisplay features can be observed. This behavior is not acceptable for many reasons. I commonly use two windows displaying different parts of the same buffer and define macros that rely on point being different in the two. > Presumably the right thing to do is have one point (and mark, and > perhaps other things - isearch, query-replace?) per buffer per pane. On > a com-split-window the new pane could be given some kind of proxy > climacs-buffer pointing to the original, but with its own state. Split window should duplicate the point of the window, but then they should be independent. Switching to a different buffer should reload point from the buffer. Take care, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From splittist at yahoo.com Sat May 7 09:19:28 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 07 May 2005 10:19:28 +0100 Subject: [climacs-devel] Re: Point - buffer or pane? (plus syntax resetting) In-Reply-To: <17020.29523.523623.585893@serveur5.labri.fr> References: <42787C0B.5060609@yahoo.com> <17020.29523.523623.585893@serveur5.labri.fr> Message-ID: <427C8820.6020206@yahoo.com> Robert Strandh wrote: ['It' is having point saved when switching buffers...] > Actually, the good way of doing it is to have a point both in the pane > and in the buffer. When a pane is about to change the buffer on > display, the point is saved in the old buffer and loaded from the new > buffer. [...but allowing different windows with different points on the same buffer.] ... > Split window should duplicate the point of the window, but then they > should be independent. Switching to a different buffer should reload > point from the buffer. Absolutely. I'll do this then. Cheers, JQS From splittist at yahoo.com Sat May 7 10:51:29 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 07 May 2005 11:51:29 +0100 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <427C8820.6020206@yahoo.com> References: <42787C0B.5060609@yahoo.com> <17020.29523.523623.585893@serveur5.labri.fr> <427C8820.6020206@yahoo.com> Message-ID: <427C9DB1.5030808@yahoo.com> John Q Splittist wrote: > Absolutely. I'll do this [follow Robert's advice] then. Herewith a patch adding a point slot to climacs-buffer (initialized from low-mark). When a pane is created, or gets a new buffer, the pane's point slot is cloned from the buffer's point. When a buffer is buried, the buffer's point is cloned from the pane's point. When a pane is split, the buffer's point is cloned from the existing pane's point so that the new pane is initialized with the existing point. This has the effect that a buffer keeps its point when buried and unburied (ie. you can C-x b in peace), but different panes on the same buffer have their own independent point (ie. you can C-x [23] in peace). JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buffer-pointer.patch URL: From a_bakic at yahoo.com Sat May 7 14:47:16 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 7 May 2005 07:47:16 -0700 (PDT) Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <427C9DB1.5030808@yahoo.com> Message-ID: <20050507144716.21214.qmail@web40607.mail.yahoo.com> I can commit this patch as soon as you and Robert agree that the following scenario does not cause a problem: Suppose you have two panes and two buffers (e.g., *scratch* and foo). If you keep switching between the two buffers in both panes, you will notice that you can't really keep two independent points to the same buffer. Instead, the point that was last saved into buffer, when the buffer was buried in one pane, ends up in the other pane when the same buffer is unburied in that other pane. Alex --- John Q Splittist wrote: > John Q Splittist wrote: > > Absolutely. I'll do this [follow Robert's advice] then. > > Herewith a patch adding a point slot to climacs-buffer (initialized from > low-mark). When a pane is created, or gets a new buffer, the pane's > point slot is cloned from the buffer's point. When a buffer is buried, > the buffer's point is cloned from the pane's point. When a pane is > split, the buffer's point is cloned from the existing pane's point so > that the new pane is initialized with the existing point. > > This has the effect that a buffer keeps its point when buried and > unburied (ie. you can C-x b in peace), but different panes on the same > buffer have their own independent point (ie. you can C-x [23] in peace). > > JQS __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From splittist at yahoo.com Sat May 7 17:17:38 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 07 May 2005 18:17:38 +0100 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <20050507144716.21214.qmail@web40607.mail.yahoo.com> References: <427C9DB1.5030808@yahoo.com> <20050507144716.21214.qmail@web40607.mail.yahoo.com> Message-ID: <427CF832.8040108@yahoo.com> Aleksandar Bakic wrote: > I can commit this patch as soon as you and Robert agree that the following > scenario does not cause a problem: > > Suppose you have two panes and two buffers (e.g., *scratch* and foo). If you > keep switching between the two buffers in both panes, you will notice that you > can't really keep two independent points to the same buffer. Instead, the point > that was last saved into buffer, when the buffer was buried in one pane, ends > up in the other pane when the same buffer is unburied in that other pane. This doesn't worry me: last-to-be-buried-wins is (I'm pretty sure) the GNU Emacs behaviour: Indirect Buffers are something different. But if Robert has a different/better idea, I would be happy to bow to his deeper thought and try to implement that... What about an application-wide Push Down List (stack) of points a la Zmacs? JQS From a_bakic at yahoo.com Sat May 7 17:58:51 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 7 May 2005 10:58:51 -0700 (PDT) Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <427CF832.8040108@yahoo.com> Message-ID: <20050507175851.96105.qmail@web40627.mail.yahoo.com> > This doesn't worry me: last-to-be-buried-wins is (I'm pretty sure) the > GNU Emacs behaviour: Indirect Buffers are something different. Good. > But if Robert has a different/better idea, I would be happy to bow to > his deeper thought and try to implement that... OK. > What about an application-wide Push Down List (stack) of points a la Zmacs? I haven't used something like this, so I'd say, only if (1) it is a proven good idea and nicely extends the default behavior, and (2) you can do it quickly or you'd like to do it. Thanks, Alex __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From brian at mastenbrook.net Sun May 8 12:52:25 2005 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Sun, 08 May 2005 07:52:25 -0500 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax Message-ID: <427E0B89.2050008@mastenbrook.net> Hi, I've been tracking down a problem visible in the Common-lisp syntax. To replicate this problem, put an empty buffer into the syntax, and type () - you should see the parens jump to the right one column. Actually, there's an extra open-paren being presented; I'm not sure why it doesn't show on screen, but it is taking up that leftmost column. The reason for this is that there's an extra open-paren on the parse stack at that point, as evidenced by the debug statement I put in display-parse-stack in cl-syntax.lisp: This parse stack's trees are (# #). That nonempty-cl-terminals actually has the list-expr in it. So far I've been unable to figure out why this extra tree is on the parse stack. Does anybody have a good idea here? -- Brian Mastenbrook brian at mastenbrook.net From splittist at yahoo.com Sun May 8 19:50:54 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 08 May 2005 20:50:54 +0100 Subject: [climacs-devel] Query Replace feedback Message-ID: <427E6D9E.6040904@yahoo.com> I attach a patch that provides some feedback when doing a Query Replace (when you're being asked for a decision; when the operation has finished). It also provides the user with default choices from the Query Replace done last time, if any. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: qr-feedback.patch URL: From splittist at yahoo.com Sun May 8 20:18:21 2005 From: splittist at yahoo.com (John Q Splittist) Date: Sun, 08 May 2005 21:18:21 +0100 Subject: [climacs-devel] Skip internal buffers Message-ID: <427E740D.1090708@yahoo.com> A small patch to avoid being asked whether to save buffers whose names begin with an asterisk, like *scratch*. It was driving me mad. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: skip-asterisk.patch URL: From csr21 at cam.ac.uk Sun May 8 20:19:37 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 08 May 2005 21:19:37 +0100 Subject: [climacs-devel] Skip internal buffers In-Reply-To: <427E740D.1090708@yahoo.com> (John Q. Splittist's message of "Sun, 08 May 2005 21:18:21 +0100") References: <427E740D.1090708@yahoo.com> Message-ID: John Q Splittist writes: > A small patch to avoid being asked whether to save buffers whose names > begin with an asterisk, like *scratch*. It was driving me mad. Brian suggested (in a discussion we had a little while ago on IRC) that instead the logic should be more like "don't prompt if the buffer is not associated with a file". Cheers, Christophe From csr21 at cam.ac.uk Sun May 8 21:00:22 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 08 May 2005 22:00:22 +0100 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax In-Reply-To: <427E0B89.2050008@mastenbrook.net> (Brian Mastenbrook's message of "Sun, 08 May 2005 07:52:25 -0500") References: <427E0B89.2050008@mastenbrook.net> Message-ID: Brian Mastenbrook writes: > I've been tracking down a problem visible in the Common-lisp > syntax. To replicate this problem, put an empty buffer into the > syntax, and type () - you should see the parens jump to the right one > column. Actually, there's an extra open-paren being presented; I'm not > sure why it doesn't show on screen, but it is taking up that leftmost > column. The reason for this is that there's an extra open-paren on the > parse stack at that point, as evidenced by the debug statement I put > in display-parse-stack in cl-syntax.lisp: > > This parse stack's trees are (# > #). > > That nonempty-cl-terminals actually has the list-expr in it. > > So far I've been unable to figure out why this extra tree is on the > parse stack. Does anybody have a good idea here? Here is a guess: the list-expr in cl-syntax contains (as the list items) CL-TERMINALS, which is also the target symbol of the grammar itself. I'm willing to believe that this confuses matters. (setf parser (make-instance 'parser :grammar *cl-grammar* :target 'cl-terminals)) and (add-cl-rule (list-expr -> ((start paren-open) (items cl-terminals) (end paren-close)) :start start :items items :end end)) Robert, is this likely to be the cause of the problem? If so, any idea how to fix it? Cheers, Christophe From csr21 at cam.ac.uk Sun May 8 21:18:36 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 08 May 2005 22:18:36 +0100 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax In-Reply-To: (Christophe Rhodes's message of "Sun, 08 May 2005 22:00:22 +0100") References: <427E0B89.2050008@mastenbrook.net> Message-ID: Christophe Rhodes writes: > Here is a guess: the list-expr in cl-syntax contains (as the list > items) CL-TERMINALS, which is also the target symbol of the grammar > itself. I'm willing to believe that this confuses matters. I think this guess is wrong. Rewriting the list-expr grammar to use a different list (define-list list-items empty-list-items nonempty-list-items cl-terminal) did not make the problem go away. Cheers, Christophe From csr21 at cam.ac.uk Sun May 8 21:34:03 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 08 May 2005 22:34:03 +0100 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax In-Reply-To: (Christophe Rhodes's message of "Sun, 08 May 2005 22:18:36 +0100") References: <427E0B89.2050008@mastenbrook.net> Message-ID: Christophe Rhodes writes: > Christophe Rhodes writes: > >> Here is a guess: the list-expr in cl-syntax contains (as the list >> items) CL-TERMINALS, which is also the target symbol of the grammar >> itself. I'm willing to believe that this confuses matters. > > I think this guess is wrong. Rewriting the list-expr grammar to use a > different list > (define-list list-items empty-list-items nonempty-list-items cl-terminal) > did not make the problem go away. The attached patch fixes the problem. I don't know why. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cl-syntax.diff URL: -------------- next part -------------- Cheers, Christophe From splittist at yahoo.com Mon May 9 08:32:44 2005 From: splittist at yahoo.com (John Q Splittist) Date: Mon, 09 May 2005 09:32:44 +0100 Subject: [climacs-devel] Re: Skip internal buffers In-Reply-To: References: <427E740D.1090708@yahoo.com> Message-ID: <427F202C.8000001@yahoo.com> Christophe Rhodes wrote: > Brian suggested (in a discussion we had a little while ago on IRC) Of course! I'd wondered where all the discussion was going on. Doh! > that instead the logic should be more like "don't prompt if the buffer > is not associated with a file". See patch -- only buffers that are both modified and have a non-nil filename are prompted for. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: skip-non-file.patch URL: From brian at mastenbrook.net Mon May 9 12:17:59 2005 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Mon, 09 May 2005 07:17:59 -0500 Subject: [climacs-devel] Re: Skip internal buffers In-Reply-To: <427F202C.8000001@yahoo.com> References: <427E740D.1090708@yahoo.com> <427F202C.8000001@yahoo.com> Message-ID: <427F54F7.3000703@mastenbrook.net> John Q Splittist wrote: > See patch -- only buffers that are both modified and have a non-nil > filename are prompted for. > > JQS The way I did this locally was to remove the needs-saving accessor and redefine it as a generic function + one method that said (and (filename buffer) (needs-saving buffer)). This means that the logic of needs-saving is spread around the source less. Does this make sense to you? -- Brian Mastenbrook brian at mastenbrook.net From asf at boinkor.net Mon May 9 12:37:05 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 09 May 2005 14:37:05 +0200 Subject: [climacs-devel] cl-syntax symbol cleverness Message-ID: <87vf5svamm.wl%asf@boinkor.net> Hi, I just hacked on cl-syntax.lisp a bit. now it can correctly render the first screenful of cl-syntax.lisp, and a few other files that I tried it on. (-: Changes: * Add support for qualified symbols (via : and ::) * Add support for keyword symbols * Add support for lambda list keywords * Fix the lexer's neutralcharp a bit to support the above (#\-, #\+, and #\. should all be read as part of the symbol name). Index: cl-syntax.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/cl-syntax.lisp,v retrieving revision 1.12 diff -u -r1.12 cl-syntax.lisp --- cl-syntax.lisp 29 Apr 2005 20:10:32 -0000 1.12 +++ cl-syntax.lisp 9 May 2005 12:36:28 -0000 @@ -53,6 +53,8 @@ (defclass paren-close (cl-lexeme) ()) (defclass comma (cl-lexeme) ()) (defclass quote-symbol (cl-lexeme) ()) +(defclass colon (cl-lexeme) ()) +(defclass ampersand (cl-lexeme) ()) (defclass double-quote (cl-lexeme) ()) (defclass hex (cl-lexeme) ()) (defclass pipe (cl-lexeme) ()) @@ -78,6 +80,8 @@ (#\, (fo) (make-instance 'comma)) (#\" (fo) (make-instance 'double-quote)) (#\' (fo) (make-instance 'quote-symbol)) + (#\: (fo) (make-instance 'colon)) + (#\& (fo) (make-instance 'ampersand)) (#\# (fo) (make-instance 'hex)) (#\| (fo) (make-instance 'pipe)) (#\` (fo) (make-instance 'backquote)) @@ -115,7 +119,7 @@ (defun neutralcharp (var) (and (characterp var) (not (member var '(#\( #\) #\, #\" #\' #\# #\| #\` #\@ #\; #\\ - #\/ #\. #\+ #\- #\Newline #\Space #\Tab) + #\: #\/ #\Newline #\Space #\Tab) :test #'char=)))) @@ -783,6 +787,98 @@ (display-parse-tree start syntax pane)) (display-parse-tree item syntax pane))) +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Qualified symbols + +;; XXX: There's a bit of duplication going on here. I'm not sure if +;; that could be reduced by clever inheritance. But then, it's only +;; OAOOM. + +(defclass qualified-symbol (cl-entry) + ((package-name :initarg :package-name) + (colon1 :initarg :colon1) + (colon2 :initarg :colon2) + (symbol-name :initarg :symbol-name))) + +(defclass qualified-exported-symbol (cl-entry) + ((package-name :initarg :package-name) + (colon :initarg :colon) + (symbol-name :initarg :symbol-name))) + +(add-cl-rule (qualified-symbol -> ((package-name default-item) + (colon1 colon (= (end-offset package-name) + (start-offset colon1))) + (colon2 colon (= (end-offset colon1) + (start-offset colon2))) + (symbol-name default-item (= (end-offset colon2) + (start-offset symbol-name)))) + :package-name package-name + :colon1 colon1 + :colon2 colon2 + :symbol-name symbol-name)) + +(add-cl-rule (qualified-exported-symbol -> ((package-name default-item) + (colon colon (= (end-offset package-name) + (start-offset colon))) + (symbol-name default-item (= (end-offset colon) + (start-offset symbol-name)))) + :package-name package-name + :colon colon + :symbol-name symbol-name)) + +(defmethod display-parse-tree ((entity qualified-symbol) (syntax cl-syntax) pane) + (with-slots (package-name colon1 colon2 symbol-name) entity + (with-drawing-options (pane :text-style (make-text-style :fix :bold nil) :ink +purple+) + (display-parse-tree package-name syntax pane) + (display-parse-tree colon1 syntax pane) + (display-parse-tree colon2 syntax pane)) + (display-parse-tree symbol-name syntax pane))) + +(defmethod display-parse-tree ((entity qualified-exported-symbol) (syntax cl-syntax) pane) + (with-slots (package-name colon symbol-name) entity + (display-parse-tree package-name syntax pane) + (with-drawing-options (pane :ink (make-rgb-color 0.0 0.0 1.0)) + (display-parse-tree colon syntax pane)) + (display-parse-tree symbol-name syntax pane))) + +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Keyword symbols + +(defclass keyword-symbol (cl-entry) + ((start :initarg :start) + (item :initarg :item))) + +(add-cl-rule (keyword-symbol -> ((start colon) + (item identifier)) + :start start :item item)) + +(defmethod display-parse-tree ((entity keyword-symbol) (syntax cl-syntax) pane) + (with-slots (start item) entity + (with-text-face (pane :bold) + (display-parse-tree start syntax pane) + (display-parse-tree item syntax pane)))) + +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Lambda list Keywords + +(defclass lambda-list-keyword (cl-entry) + ((start :initarg :start) + (item :initarg :item))) + +(add-cl-rule (lambda-list-keyword -> ((start ampersand) + (item default-item (and + (= (end-offset start) + (start-offset item)) + (member item + '( ;; ordinary LLs + "optional" "rest" "key" "aux" "allow-other-keys" + ;; macro LLs + "body" "whole" "environment") + :test #'default-item-is)))) + :start start :item item)) + +(defmethod display-parse-tree ((entity lambda-list-keyword) (syntax cl-syntax) pane) + (with-slots (start item) entity + (with-drawing-options (pane :ink +blue+) + (display-parse-tree start syntax pane) + (display-parse-tree item syntax pane)))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Backquoted expr @@ -850,6 +946,10 @@ (add-cl-rule (cl-terminal -> (balanced-comment) :item balanced-comment)) (add-cl-rule (cl-terminal -> (cl-string) :item cl-string)) (add-cl-rule (cl-terminal -> (quoted-expr) :item quoted-expr)) +(add-cl-rule (cl-terminal -> (keyword-symbol) :item keyword-symbol)) +(add-cl-rule (cl-terminal -> (lambda-list-keyword) :item lambda-list-keyword)) +(add-cl-rule (cl-terminal -> (qualified-symbol) :item qualified-symbol)) +(add-cl-rule (cl-terminal -> (qualified-exported-symbol) :item qualified-exported-symbol)) (add-cl-rule (cl-terminal -> (backquoted-expr) :item backquoted-expr)) (add-cl-rule (cl-terminal -> (char-item) :item char-item)) (add-cl-rule (cl-terminal -> (unquoted-expr) :item unquoted-expr)) @@ -925,19 +1025,21 @@ (defun handle-whitespace (pane buffer start end) (let ((space-width (space-width pane)) (tab-width (tab-width pane))) - (loop while (< start end) - do (ecase (buffer-object buffer start) - (#\Newline (terpri pane) - (setf (aref *cursor-positions* (incf *current-line*)) - (multiple-value-bind (x y) (stream-cursor-position pane) - (declare (ignore x)) - y))) - (#\Space (stream-increment-cursor-position - pane space-width 0)) - (#\Tab (let ((x (stream-cursor-position pane))) - (stream-increment-cursor-position - pane (- tab-width (mod x tab-width)) 0)))) - (incf start)))) + (loop while (and (< start end) + (whitespacep (buffer-object buffer start))) + do (ecase (buffer-object buffer start) + (#\Newline (terpri pane) + (setf (aref *cursor-positions* (incf *current-line*)) + (multiple-value-bind (x y) (stream-cursor-position pane) + (declare (ignore x)) + y))) + (#\Space (stream-increment-cursor-position + pane space-width 0)) + (#\Tab (let ((x (stream-cursor-position pane))) + (stream-increment-cursor-position + pane (- tab-width (mod x tab-width)) 0))) + (#\Page nil)) + (incf start)))) (defmethod display-parse-tree :around ((entity cl-parse-tree) syntax pane) (with-slots (top bot) pane That was fun. (-: Cheers, -- Andreas Fuchs, , asf at jabber.at, antifuchs From strandh at labri.fr Mon May 9 13:24:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 9 May 2005 15:24:21 +0200 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <20050507144716.21214.qmail@web40607.mail.yahoo.com> References: <427C9DB1.5030808@yahoo.com> <20050507144716.21214.qmail@web40607.mail.yahoo.com> Message-ID: <17023.25733.813170.149532@serveur5.labri.fr> Aleksandar Bakic writes: > I can commit this patch as soon as you and Robert agree that the following > scenario does not cause a problem: > > Suppose you have two panes and two buffers (e.g., *scratch* and foo). If you > keep switching between the two buffers in both panes, you will notice that you > can't really keep two independent points to the same buffer. Instead, the point > that was last saved into buffer, when the buffer was buried in one pane, ends > up in the other pane when the same buffer is unburied in that other pane. That's OK. Emacs does not do better than this either. -- 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 May 9 13:25:19 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 9 May 2005 15:25:19 +0200 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <427CF832.8040108@yahoo.com> References: <427C9DB1.5030808@yahoo.com> <20050507144716.21214.qmail@web40607.mail.yahoo.com> <427CF832.8040108@yahoo.com> Message-ID: <17023.25791.118491.379370@serveur5.labri.fr> John Q Splittist writes: > But if Robert has a different/better idea, I would be happy to bow to > his deeper thought and try to implement that... I don't. This one is fine with me. > What about an application-wide Push Down List (stack) of points a la Zmacs? I wouldn't go to that much trouble at this point. -- 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 May 9 14:29:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 9 May 2005 16:29:21 +0200 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax In-Reply-To: References: <427E0B89.2050008@mastenbrook.net> Message-ID: <17023.29633.445412.514676@serveur5.labri.fr> Christophe Rhodes writes: > Here is a guess: the list-expr in cl-syntax contains (as the list > items) CL-TERMINALS, which is also the target symbol of the grammar > itself. I'm willing to believe that this confuses matters. > > (setf parser (make-instance 'parser > :grammar *cl-grammar* > :target 'cl-terminals)) > > and > > (add-cl-rule (list-expr -> ((start paren-open) > (items cl-terminals) > (end paren-close)) > :start start :items items :end end)) > > Robert, is this likely to be the cause of the problem? As you guessed yourself, the answer is most likely "no". > If so, any > idea how to fix it? Not yet. I have had an intense week with looking more at incremental redisplay (which now takes up as much time as the parser) in HTML syntax. I'll start looking into CL syntax shortly. 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 Mon May 9 14:31:00 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 9 May 2005 16:31:00 +0200 Subject: [climacs-devel] Extra open-paren on parse stack in Common-lisp syntax In-Reply-To: References: <427E0B89.2050008@mastenbrook.net> Message-ID: <17023.29732.455335.818264@serveur5.labri.fr> Christophe Rhodes writes: > Christophe Rhodes writes: > > > Christophe Rhodes writes: > > > >> Here is a guess: the list-expr in cl-syntax contains (as the list > >> items) CL-TERMINALS, which is also the target symbol of the grammar > >> itself. I'm willing to believe that this confuses matters. > > > > I think this guess is wrong. Rewriting the list-expr grammar to use a > > different list > > (define-list list-items empty-list-items nonempty-list-items cl-terminal) > > did not make the problem go away. > > The attached patch fixes the problem. I don't know why. That patch does not look right to me. I'll look into the problem shortly. 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 Mon May 9 14:49:17 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 9 May 2005 16:49:17 +0200 Subject: [climacs-devel] Re: Point - buffer or pane? In-Reply-To: <427C9DB1.5030808@yahoo.com> References: <42787C0B.5060609@yahoo.com> <17020.29523.523623.585893@serveur5.labri.fr> <427C8820.6020206@yahoo.com> <427C9DB1.5030808@yahoo.com> Message-ID: <17023.30829.140422.66779@serveur5.labri.fr> John Q Splittist writes: > Herewith a patch adding a point slot to climacs-buffer (initialized from > low-mark). When a pane is created, or gets a new buffer, the pane's > point slot is cloned from the buffer's point. When a buffer is buried, > the buffer's point is cloned from the pane's point. When a pane is > split, the buffer's point is cloned from the existing pane's point so > that the new pane is initialized with the existing point. > > This has the effect that a buffer keeps its point when buried and > unburied (ie. you can C-x b in peace), but different panes on the same > buffer have their own independent point (ie. you can C-x [23] in peace). Thanks. 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. Take care, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From splittist at yahoo.com Wed May 11 18:06:02 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 11 May 2005 19:06:02 +0100 Subject: [climacs-devel] Multiple Query Replace Message-ID: <4282498A.2060401@yahoo.com> Below is a proof-of-concept Multiple Query Replace and Multiple Query Replace From Buffer. I'm assuming that the forthcoming cl-ppcre integration (thanks Nicolas!) will change things around a bit in this space, and all the Query commands will get refactored as a result. Also, the code for reading the search strings from a buffer is even worse than my usual efforts... Multiple Query Replace: prompts for pairs of strings, the first to search for, the second to replace it; entering an empty string stops the prompting. The command then steps through the buffer and, each time it finds one of the search strings, asks you if you want to replace it with the relevant replacement string. Thus, to change all the "foo"s to "bar"s, and all the "bar"s to "foo"s: M-x Multiple Query Replace Multiple Query Replace: foo Multiple Query Replace foo with: bar Multiple Query Replace: bar Multiple Query Replace bar with: foo Multiple Query Replace: ... and it does its thing. This kind of swapping (or, more generally, rotating) can't be done by successive Query Replaces. But entering a bunch of strings at the prompt can get tedious, so there's: Multiple Query Replace From Buffer: prompts for a buffer containing pairs of strings (words), the first in each pair being the string to search for, the second being the string to replace it with. Thus, create a buffer "foostrings" with: foo bar bar baz baz foo swap back to the buffer to rotate these words in, M-x Multiple Query Replace From Buffer Buffer with Query Replace Strings: foostrings and away we go. Any thoughts? This seems such a useful facility I wonder why it isn't in GNU emacs - unless it is and I've just missed it... (Note that the accept method for buffers always creates a buffer if you specify one that doesn't exist: the creation should be factored out into com-switch-to-buffer etc. When I get the CVS climacs to build I'll do that, if no-one beats me to it...) JQS In base.lisp [or (in-package :climacs-base) ;;; Multiple search (defun buffer-looking-at-some (buffer offset list &key (test #'eql)) "return true if and only if BUFFER contains one of the vectors in LIST at OFFSET" (loop for vector in list when (buffer-looking-at buffer offset vector :test test) return vector finally (return nil))) (defun looking-at-some (mark list &key (test #'eql)) "return true if and only if BUFFER contains one of the vectors in LIST after MARK" (buffer-looking-at-some (buffer mark) (offset mark) list :test test)) (defun buffer-search-forward-some (buffer offset list &key (test #'eql)) "return the smallest offset of BUFFER >= OFFSET containing a vector from LIST or NIL if no such offset exists" (loop for i from offset to (size buffer) for vector = (buffer-looking-at-some buffer i list :test test) when vector return (values i vector) finally (return nil))) (defun search-forward-some (mark list &key (test #'eql)) "move MARK forward after the first occurence of a vector in LIST after MARK" (multiple-value-bind (offset vector) (buffer-search-forward-some (buffer mark) (offset mark) list :test test) (when offset (setf (offset mark) (+ offset (length vector))) vector))) In gui.lisp [or (in-package :climacs-gui)] ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Multiple Query Replace (defun multiple-query-replace-find-next-match (mark list) "returns NIL or the vector found from LIST" (flet ((object-equal (x y) (and (characterp x) (characterp y) (char-equal x y)))) (climacs-base::search-forward-some mark list :test #'object-equal))) (define-named-command com-multiple-query-replace () (let (strings string1 string2) (loop (setf string1 (accept 'string :prompt "Multiple Query Replace")) (when (string= "" string1) (return)) (setf string2 (accept 'string :prompt (format nil "Multiple Query Replace ~A with" string1))) (setf strings (acons string1 string2 strings))) (multiple-query-replace (nreverse strings)))) (define-named-command com-multiple-query-replace-from-buffer () (let ((buffer (accept 'buffer :prompt "Buffer with Query Replace strings"))) (unless (member buffer (buffers *application-frame*)) (beep) (display-message "~A not an existing buffer" (name buffer)) (return-from com-multiple-query-replace-from-buffer nil)) (let* ((words (loop with words = nil with mark1 = (clone-mark (low-mark buffer)) with mark2 = (clone-mark (low-mark buffer)) for old-mark1-offset = nil then (offset mark1) initially (beginning-of-buffer mark1) (beginning-of-buffer mark2) do (forward-word mark1) (backward-word mark1) (forward-word mark2) (push (coerce (region-to-sequence mark1 mark2) 'string) words) (forward-word mark1) until (eql (offset mark1) old-mark1-offset) finally (return (nreverse (rest words)))))) (unless (evenp (length words)) (beep) (display-message "Not an even number of words in ~A" (name buffer)) (return-from com-multiple-query-replace-from-buffer nil)) (let ((strings (loop for (key value) on words by #'cddr collecting (cons key value)))) (multiple-query-replace strings))))) (defun multiple-query-replace (strings) (declare (special strings)) (let ((occurrences 0)) (declare (special occurrences)) (when strings (let* ((pane (current-window)) (point (point pane)) (found (multiple-query-replace-find-next-match point (mapcar #'car strings)))) (when found (setf (query-replace-state pane) (make-instance 'query-replace-state :string1 found :string2 (cdr (assoc found strings :test #'string=))) (query-replace-mode pane) t) (display-message "Multiple Query Replace ~A with ~A: " (string1 (query-replace-state pane)) (string2 (query-replace-state pane))) (simple-command-loop 'multiple-query-replace-climacs-table (query-replace-mode pane) ((setf (query-replace-mode pane) nil)))))) (display-message "Replaced ~A occurrence~:P" occurrences))) (define-named-command com-multiple-query-replace-replace () (declare (special strings occurrences)) (let* ((pane (current-window)) (point (point pane)) (buffer (buffer pane)) (state (query-replace-state pane)) (string1-length (length (string1 state)))) (backward-object point string1-length) (let* ((offset1 (offset point)) (offset2 (+ offset1 string1-length)) (region-case (buffer-region-case buffer offset1 offset2))) (delete-range point string1-length) (insert-sequence point (string2 state)) (setf offset2 (+ offset1 (length (string2 state)))) (finish-output *error-output*) (case region-case (:upper-case (upcase-buffer-region buffer offset1 offset2)) (:lower-case (downcase-buffer-region buffer offset1 offset2)) (:capitalized (capitalize-buffer-region buffer offset1 offset2)))) (incf occurrences) (let ((found (multiple-query-replace-find-next-match point (mapcar #'car strings)))) (cond ((null found)(setf (query-replace-mode pane) nil)) (t (setf (query-replace-state pane) (make-instance 'query-replace-state :string1 found :string2 (cdr (assoc found strings :test #'string=)))) (display-message "Multiple Query Replace ~A with ~A: " (string1 (query-replace-state pane)) (string2 (query-replace-state pane)))))))) (define-named-command com-multiple-query-replace-skip () (declare (special strings)) (let* ((pane (current-window)) (point (point pane)) (found (multiple-query-replace-find-next-match point (mapcar #'car strings)))) (cond ((null found)(setf (query-replace-mode pane) nil)) (t (setf (query-replace-state pane) (make-instance 'query-replace-state :string1 found :string2 (cdr (assoc found strings :test #'string=)))) (display-message "Multiple Query Replace ~A with ~A: " (string1 (query-replace-state pane)) (string2 (query-replace-state pane))))))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Multiple query replace command table (make-command-table 'multiple-query-replace-climacs-table :errorp nil) (defun multiple-query-replace-set-key (gesture command) (add-command-to-command-table command 'multiple-query-replace-climacs-table :keystroke gesture :errorp nil)) (multiple-query-replace-set-key '(#\Newline) 'com-query-replace-exit) (multiple-query-replace-set-key '(#\Space) 'com-multiple-query-replace-replace) (multiple-query-replace-set-key '(#\Backspace) 'com-multiple-query-replace-skip) (multiple-query-replace-set-key '(#\Rubout) 'com-query-replace-skip) (multiple-query-replace-set-key '(#\q) 'com-query-replace-exit) (multiple-query-replace-set-key '(#\y) 'com-multiple-query-replace-replace) (multiple-query-replace-set-key '(#\n) 'com-multiple-query-replace-skip) From splittist at yahoo.com Wed May 11 18:30:12 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 11 May 2005 19:30:12 +0100 Subject: [climacs-devel] Re: Multiple Query Replace In-Reply-To: <4282498A.2060401@yahoo.com> References: <4282498A.2060401@yahoo.com> Message-ID: <42824F34.3040102@yahoo.com> > (multiple-query-replace-set-key '(#\Rubout) 'com-query-replace-skip) Obviously this should be 'com-multiple-query-replace-skip ... JQS From nicolas.sceaux at free.fr Wed May 11 22:30:48 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Thu, 12 May 2005 00:30:48 +0200 Subject: [climacs-devel] Multiple Query Replace In-Reply-To: <4282498A.2060401@yahoo.com> (John Q. Splittist's message of "Wed, 11 May 2005 19:06:02 +0100") References: <4282498A.2060401@yahoo.com> Message-ID: <87ll6l5raf.fsf@free.fr> John Q Splittist writes: > I'm assuming that the forthcoming cl-ppcre > integration (thanks Nicolas!) wopopop This is not done yet. I still get 122 failures / 1625 tests (CL-PPCRE test suite adapted for using standard-buffers instead of strings). Nicolas From dlewis at soi.city.ac.uk Wed May 11 14:23:47 2005 From: dlewis at soi.city.ac.uk (David Lewis) Date: Wed, 11 May 2005 15:23:47 +0100 Subject: [climacs-devel] spaces in directory or filenames under MacOS Message-ID: <85de97ed0c5434b50fc1f9d278563a1e@soi.city.ac.uk> Hi, I've run into a problem running climacs on a mac: the space character in directory or file names seems to break the pathname input in the minibuffer. Any thoughts about ways round the issue/escape character options? Thanks, David Lewis From nicolas.sceaux at free.fr Thu May 12 21:12:36 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Thu, 12 May 2005 23:12:36 +0200 Subject: [climacs-devel] cl-ppcre Message-ID: <87wtq46tdn.fsf@free.fr> Hello, Finally, I've managed to modify CL-PPCRE so that it should be able to scan arbitrary sequences -- including buffers. To save bandwidth, it has been put here: http://nicolas.sceaux.free.fr/climacs-ppcre.tar.gz Changes to climacs: - regex.lisp, which implements the appropriate methods to make buffers scannable by ppcre - regex-test.lisp, for unit test. - a patch for climacs.asd and packages.lisp -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: regex.lisp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: regex-test.lisp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ppcre.patch Type: text/x-patch Size: 1988 bytes Desc: not available URL: -------------- next part -------------- To test it: unpack climacs-ppcre.tar.gz inside the climacs root directory (should create a climacs-ppcre/ subdirectory) * (asdf:oos 'asdf:compile-op :climacs-ppcre) * (asdf:oos 'asdf:compile-op :climacs-ppcre-test) * (asdf:oos 'asdf:load-op :climacs-ppcre-test) * (climacs-ppcre-test:test) This is the regular CL-PPCRE unit tests (using strings). It should output 3 differences: 662 790 1439. * (asdf:oos 'asdf:compile-op :climacs) * (asdf:oos 'asdf:load-op :climacs) * (climacs-regex-tests:test) This is the same unit tests, but using STANDARD-BUFFERs iso STRINGs. It should output the same three differences. Nicolas From brian at mastenbrook.net Fri May 13 00:42:35 2005 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Thu, 12 May 2005 19:42:35 -0500 Subject: [climacs-devel] Syntax for an entire file Message-ID: <4283F7FB.3050706@mastenbrook.net> I'm having trouble understanding the interaction between the parser and the view of the buffer on screen. Is the buffer re-parsed every time the view changes? I'm trying to understand why syntax is not working correctly for parsed objects which extend beyond a single screenful - for instance, #( on the first line, and ) many lines after. It seems that when ) is on screen, the syntax is applied correctly, but when #( is on screen, the entire buffer is not parsed and so there is no colored display of #(. (Also the closing paren does not display on the correct line - I'm still looking into this one.) -- Brian Mastenbrook brian at mastenbrook.net From csr21 at cam.ac.uk Mon May 16 15:25:21 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 16 May 2005 16:25:21 +0100 Subject: [climacs-devel] Paper Message-ID: Hi, People on this list might be interested in a draft a colleague and I submitted to CMMR 2005, describing the application based on climacs that's being used for editing lute tablature encodings. It's provisionally available at (but be aware that it is only a draft, and has not yet been reviewed let alone accepted). Cheers, Christophe From nicolas.sceaux at free.fr Tue May 17 18:00:16 2005 From: nicolas.sceaux at free.fr (Nicolas Sceaux) Date: Tue, 17 May 2005 20:00:16 +0200 Subject: [climacs-devel] Paper In-Reply-To: (Christophe Rhodes's message of "Mon, 16 May 2005 16:25:21 +0100") References: Message-ID: <873bslpwb3.fsf@free.fr> Christophe Rhodes writes: > Hi, > > People on this list might be interested in a draft a colleague and I > submitted to CMMR 2005, describing the application based on climacs > that's being used for editing lute tablature encodings. It's > provisionally available at > > (but be aware that it is only a draft, and has not yet been reviewed > let alone accepted). > > Cheers, > > Christophe This is really interesting indeed. May I ask what library do you use for MIDI feedback? (I am planning to experiment with a climacs syntax for the LilyPond notation, and MIDI output is obviously something that I would like, ultimately). nicolas From csr21 at cam.ac.uk Thu May 19 08:18:53 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 19 May 2005 09:18:53 +0100 Subject: [climacs-devel] DEFINE-SYNTAX Message-ID: Hi, Is anyone (apart from me) maintaining an out-of-tree syntax? I would like to change DEFINE-SYTNAX's syntax to support adding something like emacs' auto-mode-alist. I don't really mind what it ends up looking like, but I do need the functionality; on the other hand, if I can avoid breaking someone else's application, so much the better. Comments welcome. Old: (define-syntax tabcode-syntax ("Tabcode" (basic-syntax)) ((player :initarg :player :initform nil))) Possible New: (define-syntax tabcode-syntax (:name "Tabcode" :pathname-type "tc") (basic-syntax) ((player :initarg :player :initform nil))) (define-syntax (tabcode-syntax :name "Tabcode" :pathname-type "tc") (basic-syntax) ((player :initarg :player :initform nil))) (define-syntax tabcode-syntax (basic-syntax) ((player :initarg :player :initform nil)) (:name "Tabcode") (:pathname-type "tc")) From csr21 at cam.ac.uk Thu May 19 09:02:30 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 19 May 2005 10:02:30 +0100 Subject: [climacs-devel] Fwd: Insert file In-Reply-To: <1b374c0ebdbc1bee268006379b9d24a3@gold.ac.uk> (David Lewis's message of "Fri, 29 Apr 2005 16:59:22 +0100") References: <1b374c0ebdbc1bee268006379b9d24a3@gold.ac.uk> Message-ID: David Lewis writes: > I've had to implement an insert-file command for my own work (helped > by Christophe). Hope it's useful. OK, no-one seems to have complained too much about this, so I've merged it into Climacs CVS. > Change to gui.lisp: > > @@ -707,6 +710,20 @@ For future reference: it's significantly easier to merge patches if they come straight from the diff command (or cvs diff), because they can just be fed into another program. cvs diff produces a header like Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.138 diff -u -r1.138 gui.lisp --- gui.lisp 10 May 2005 16:28:53 -0000 1.138 +++ gui.lisp 19 May 2005 09:04:08 -0000 before the diff itself, which allows the patch program to identify "hunks" and apply the patch automatically. Nevertheless, thank you for your contribution. Cheers, Christophe From csr21 at cam.ac.uk Thu May 19 09:52:55 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 19 May 2005 10:52:55 +0100 Subject: [climacs-devel] DEFINE-SYNTAX In-Reply-To: (Christophe Rhodes's message of "Thu, 19 May 2005 09:18:53 +0100") References: Message-ID: Christophe Rhodes writes: > Comments welcome. To keep things concrete, attached is what I propose for now. I don't expect to win any points for style, and I can imagine that tweaks will be needed even to this new interface, but it does the job I need it to for now. Objections? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: syntax.diff URL: -------------- next part -------------- Cheers, Christophe From splittist at yahoo.com Thu May 19 11:00:29 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 19 May 2005 12:00:29 +0100 Subject: [climacs-devel] Re: DEFINE-SYNTAX In-Reply-To: References: Message-ID: <428C71CD.9060403@yahoo.com> This makes sense to me. I've been wondering about the best way to deal with buffer attributes, in particular from parsing a -*- attr:value; -*- line. Obviously this could include a Syntax:Common-lisp; entry as another (as in, an additional) way of solving the auto-syntax issue. My initial thought was just adding a slot to the buffer object with an alist and a bunch of relevant getters and setters. But I'm not sure that's sufficiently Common Lispy. Christophe Rhodes wrote: [on 'Basic' mode] > +;;; FIXME: this is a really bad name. It's even worse if it's > +;;; case-insensitive. Emacs' "Fundamental" isn't too bad. I agree with this, too: 'Fundamental' seems better than 'Basic'. JQS From a_bakic at yahoo.com Mon May 23 16:32:50 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Mon, 23 May 2005 09:32:50 -0700 (PDT) Subject: [climacs-devel] a paragraph on persistent buffers Message-ID: <20050523163250.45908.qmail@web40612.mail.yahoo.com> Hi, Below is a paragraph explaining the essence of the persistent buffer implementations, together with a couple of references (which need be put in the bibtex format). Please let me know if you'd like to see more. Regards, Alex There are three purely functional (aka fully persistent) buffer implementations, all based on work in progress by Robert Will in Haskell~[1], which builds upon work by Stephen Adams~[2]. The underlying data structure is a balanced binary tree with an abstracted-away rebalancing scheme, supporting sequence operations needed by the Climacs buffer protocol at reasonable speed ($O(\log~N$)). The first implementation, {\tt binseq-buffer}, uses one tree whose leaf nodes (buffer elements) can be arbitrary objects. An optimized implementation, {\tt obinseq-buffer}, uses less space but buffer elements must be non-nil atoms. Finally, {\tt binseq2-buffer} combines the previous two implementations, by using a tree whose leaf nodes contain the optimized trees representing lines; the benefit of this implementation are faster ($O(\log~N)$) operations dealing with lines and columns. All the three implementations enable simple and inexpensive undo/redo operations because older buffer versions are kept as a whole in memory. The space cost of these implementations is not negligent, however, significant portions of older buffer versions are simply shared with newer buffer versions. Also, it is not necessary separately to remember editing operations in undo records, in order to preserve precise buffer history. Besides the undo operation simplification, the persistent buffer implementations facilitate further purely functional operations on Climacs buffers. [1] Robert Will. Algebraic Collections: A Standard for Functional Data Structures. http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ [2] Stephen Adams. Functional pearls: Efficient sets -- a balancing act. Journal of Functional Programming, 3(4):553-561, October 1993. http://swiss.csail.mit.edu/~adams/BB/ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From a_bakic at yahoo.com Tue May 24 09:52:55 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 24 May 2005 02:52:55 -0700 (PDT) Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: 6667 Message-ID: <20050524095256.78950.qmail@web40626.mail.yahoo.com> > The space cost of these implementations is not negligent... But I am :-) Thanks for the correction. Alex __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From csr21 at cam.ac.uk Tue May 24 10:04:29 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 24 May 2005 11:04:29 +0100 Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: <20050524095256.78950.qmail@web40626.mail.yahoo.com> (Aleksandar Bakic's message of "Tue, 24 May 2005 02:52:55 -0700 (PDT)") References: <20050524095256.78950.qmail@web40626.mail.yahoo.com> Message-ID: Aleksandar Bakic writes: >> The space cost of these implementations is not negligent... > > But I am :-) Thanks for the correction. Not at all -- thank you for writing it! While I have you, though: when you say "Also, it is not necessary separately to remember editing operations in undo records, in order to preserve precise buffer history", what is meant there? Without having looked at the code, my guess is that you're contrasting the persistent buffer implementation of undo, which doesn't need to remember editing operations, with the "ordinary" buffer implementation, which does -- but I could be wildly off. Thanks, Christophe From a_bakic at yahoo.com Tue May 24 12:46:31 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 24 May 2005 05:46:31 -0700 (PDT) Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: Message-ID: <20050524124632.34258.qmail@web40601.mail.yahoo.com> > While I have you, though: when you say "Also, it is not necessary > separately to remember editing operations in undo records, in order to > preserve precise buffer history", what is meant there? Without having > looked at the code, my guess is that you're contrasting the persistent > buffer implementation of undo, which doesn't need to remember editing > operations, with the "ordinary" buffer implementation, which does -- > but I could be wildly off. Yes, an undo record of a persistent buffer only keeps a version of the buffer (effectively, just a pointer because the contents is also part of newer buffer versions). An undo record of a regular buffer only keeps an editing operation, I think. So, perhaps you could rewrite that portion and say that only a pointer is kept instead of an editing operation object... Alex __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From a_bakic at yahoo.com Tue May 24 13:24:07 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 24 May 2005 06:24:07 -0700 (PDT) Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: 6667 Message-ID: <20050524132407.28845.qmail@web40612.mail.yahoo.com> > An undo record of a regular buffer only keeps an editing > operation, I think. I can?t access the code at the moment, but I guess a regular undo record also keeps a pointer to the buffer (as opposed to the contents of it (a tree) kept by a persistent undo record), so the difference is an edit operation (at least). Alex __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ From strandh at labri.fr Tue May 24 15:29:48 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 24 May 2005 17:29:48 +0200 Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: <20050524132407.28845.qmail@web40612.mail.yahoo.com> References: <20050524132407.28845.qmail@web40612.mail.yahoo.com> Message-ID: <17043.18540.357862.69773@serveur6.labri.fr> Aleksandar Bakic writes: > > An undo record of a regular buffer only keeps an editing > > operation, I think. > > I can?t access the code at the moment, but I guess a regular undo record also > keeps a pointer to the buffer (as opposed to the contents of it (a tree) kept > by a persistent undo record), so the difference is an edit operation (at > least). Not sure what you mean, but if memory serves, an undo record contains buffer offsets as opposed to (say) marks, since we rely on undo operations to be applied in the reverse order compared to ordinary operations. -- 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 May 24 17:54:33 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 24 May 2005 10:54:33 -0700 (PDT) Subject: [climacs-devel] a paragraph on persistent buffers In-Reply-To: <17043.18540.357862.69773@serveur6.labri.fr> Message-ID: <20050524175433.6237.qmail@web40611.mail.yahoo.com> > > > An undo record of a regular buffer only keeps an editing > > > operation, I think. > > > > I can?t access the code at the moment, but I guess a regular undo record > also > > keeps a pointer to the buffer (as opposed to the contents of it (a tree) > kept > > by a persistent undo record), so the difference is an edit operation (at > > least). > > Not sure what you mean, but if memory serves, an undo record contains > buffer offsets as opposed to (say) marks, since we rely on undo > operations to be applied in the reverse order compared to ordinary > operations. Sorry, I am forgetting the terminology. I meant the same by the "editing operation": offsets plus the kind of operation and perhaps a text operand. The operation gets reversed once it is undone so that it can be redone. No such thing in a persistent buffer's undo record. (Also, just to repeat: with both kinds of buffers, markers are generally invalidated by undo/redo, even though they remain valid for some undo/redo operations with standard buffers.) Alex __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ From csr21 at cam.ac.uk Thu May 26 08:26:56 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 26 May 2005 09:26:56 +0100 Subject: [climacs-devel] DEFINE-SYNTAX In-Reply-To: (Christophe Rhodes's message of "Thu, 19 May 2005 10:52:55 +0100") References: Message-ID: Christophe Rhodes writes: > Objections? Having heard none, and given we have version control anyway, I've merged something like this into CVS. Cheers, Christophe From strandh at labri.fr Fri May 27 07:19:29 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 27 May 2005 09:19:29 +0200 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: References: Message-ID: <17046.51713.692063.290264@serveur5.labri.fr> Hello, [ I took this text from Christophe's replay because I was unable to decode the original message ] Ignas Mikalajunas writes: > Hi, i like the idea of Common lisp emacs like editor, and i would like > to test it, but it seemsso unuseable to me that i just can't even test > it :(, the bugs i have managed to encounter in like 3 minutes of using > climacs were: Christophe already pretty much said what I wanted to say, but let me just add a few notes. At the moment, I strongly discourage people who would only be potential USERS of Climacs to even try it out. The only reason it is publicly available is so that potential DEVELOPERS can try it out, give feedback with respect to architecture issues, add new functionality, and generally improve things. Personally, I am way to busy with fundamental issues such as parser efficiency and the architecture of the incremental parser to have time to fix bugs like these. The project has only existed for 5 months. I think it is tough to expect a few part-time (a few hours a week at most) volunteers to create a fully-functional Emacs clone in Common Lisp in that amount of time. I suggest you check back in say a year or so. Thanks anyway for the bug report. -- 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 zedek at gnu-rox.org Fri May 27 21:27:58 2005 From: zedek at gnu-rox.org (Xavier Maillard) Date: Fri, 27 May 2005 23:27:58 +0200 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: <17046.51713.692063.290264@serveur5.labri.fr> (Robert Strandh's message of "Fri, 27 May 2005 09:19:29 +0200") References: <17046.51713.692063.290264@serveur5.labri.fr> Message-ID: On 27 May 2005, Robert Strandh outgrape: > At the moment, I strongly discourage people who would only be > potential USERS of Climacs to even try it out. The only reason > it is publicly available is so that potential DEVELOPERS can > try it out, give feedback with respect to architecture issues, > add new functionality, and generally improve things. I personnally agree with you even if I am one of the impatient user :) I read this list carefully and when ready, I'll jump onto it. Keep up the good job guys. -- Xavier MAILLARD (GnuPG: 1024D/1E028EA5) EmacsOS user (http://emacsfr.org) APRIL (http://www.april.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From strandh at labri.fr Mon May 30 13:00:15 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 30 May 2005 15:00:15 +0200 Subject: [climacs-devel] Bugs reporting :) In-Reply-To: References: <17046.51713.692063.290264@serveur5.labri.fr> Message-ID: <17051.3679.798152.175071@serveur5.labri.fr> Xavier Maillard writes: > I personnally agree with you even if I am one of the impatient > user :) I read this list carefully and when ready, I'll jump onto > it. Great. Read on. I'll soon write something about lisp syntax. > Keep up the good job guys. Thanks, will 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. ---------------------------------------------------------------------