From wencel at gmail.com Sun Jan 2 17:34:47 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Sun, 2 Jan 2005 17:34:47 +0000 Subject: [climacs-devel] Typo patch for syntax.lisp, transpose-lines and exchange-point-and-mark for gui.lisp Message-ID: <2b1f8a5b05010209346ec88009@mail.gmail.com> Hi there, these two patches add some extra commands to gui.lisp and fix a typo in syntax.lisp. 2005-01-02 Lawrence Mitchell * gui.lisp ((define-application-frame climacs)): Add a without-interactor clause to the frame :layout. This is a layout without a minibuffer pane. (com-toggle-layout): Toggle layout between 'default and 'without-interactor. Note the without-interactor layout no longer allows you to enter extended commands (there's nowhere for *standard-input* to go) so I'm not sure how useful it is. (com-set-mark): Fix indentation. (com-exchange-point-and-mark): New command, exchange the positions of point and mark, bound to C-x C-x. (com-transpose-lines): New command, bound to C-x C-t. * syntax.lisp (present-contents): Fix typo in argument list. -- Lawrence Mitchell -------------- next part -------------- A non-text attachment was scrubbed... Name: gui.lisp.patch Type: text/x-patch Size: 2667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syntax.lisp.patch Type: text/x-patch Size: 569 bytes Desc: not available URL: From wencel at gmail.com Sun Jan 2 18:06:44 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Sun, 2 Jan 2005 18:06:44 +0000 Subject: [climacs-devel] A nicer transpose-lines Message-ID: <2b1f8a5b0501021006c2cfa2d@mail.gmail.com> Here's (what I think) is a slightly nicer transpose-lines: (define-named-command com-transpose-lines () (let ((point (point (win *application-frame*)))) (beginning-of-line point) (unless (beginning-of-buffer-p point) (previous-line point)) (let* ((bol (offset point)) (eol (progn (end-of-line point) (offset point))) (line (buffer-sequence (buffer point) bol eol))) (delete-region bol point) ;; Remove newline at end of line as well. (unless (end-of-buffer-p point) (delete-range point)) ;; If the current line is at the end of the buffer, we want to ;; be able to insert past it, so we need to get an extra line ;; at the end. (when (progn (end-of-line point) (end-of-buffer-p point)) (insert-object point #\Newline)) (next-line point) (insert-sequence point line) (insert-object point #\Newline)))) -- Lawrence Mitchell From strandh at labri.fr Wed Jan 5 05:32:30 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 5 Jan 2005 06:32:30 +0100 Subject: [climacs-devel] latest progress Message-ID: <16859.31726.167911.263807@serveur5.labri.fr> Hello, This message is mostly for those who do not read climacs-cvs and who do not participate in the #lisp IRC channel. Climacs has dozens of lines added to it every day. At this rate I estimate we will have a completely usable editor by the time the student projects are finished in May. Do not hesitate taking on even minor tasks such as fixing a bug or adding documentation strings. And please add your favorite Emacs command that is currently missing from Climacs, but please let us know (by mailing to this list) what you are working on in that case. Recent improvements: * the near-final redisplay algorithm is in place. Screen update is now very fast after simple buffer operation such as inserting characters on a line. * transpose-{objects,words,lines} exist. * the implementation of the buffer protocol is faster. * we have function to search for a string in the buffer (non-incremental for now). * the CLX translate function was fixed so that non-ascii characters can be displayed. * input mode for iso-latin-1 on a US-international keyboard was implemented. Not sure Climacs is the right place for this, though. It might migrate to McCLIM one day. * implemented a command for setting the syntax (with completion). * probably some things I forgot. What is being worked on: * multi-buffer, multi-window -- 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 rudi at constantly.at Wed Jan 5 12:23:41 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 5 Jan 2005 13:23:41 +0100 Subject: [climacs-devel] Some small patches Message-ID: Hi, Just to mingle with the cool kids, I've superficially browsed the climacs code. I must say it was an enjoyable read, very clean and with good naming and structure. I append some proposed fixes for things that caught my eye; since I haven't even downloaded the code locally, it's in the form of whole, modified functions, for which I apologize. Cheers, Rudi 1) buffer.lisp: buffer-sequence conses unnecessarily, since the length of the result vector is known; the following (untested) might be better. As before, the case of offset1 > offset2 returns a zero-length vector, but this is more apparent in the code now. (defmethod buffer-sequence ((buffer standard-buffer) offset1 offset2) ;; untested, for illustration purposes only (assert (<= 0 offset1 (size buffer)) () (make-condition 'no-such-offset :offset offset1)) (assert (<= 0 offset2 (size buffer)) () (make-condition 'no-such-offset :offset offset2)) (if (< offset1 offset2) (let ((result (make-array (list (- offset2 offset1))))) (loop for offset from offset1 below offset2 for i upfrom 0 do (setf (svref result i) (buffer-object buffer offset))) result) (make-array '(0)))) 2) gui.lisp could use a method (defmethod frame-standard-output ((frame climacs)) (get-frame-pane frame 'int)) (if the minibuffer is indeed the standard-output, of course), so that the function display-message can display to *standard-output* instead of *standard-input*. 3) Also, in gui.lisp, initialize-instance shouldn't unconditionally clobber the syntax: (defmethod initialize-instance :after ((pane climacs-pane) &rest args) (declare (ignore args)) (with-slots (buffer point syntax mark) pane (when (null point) (setf point (make-instance 'standard-right-sticky-mark :buffer buffer))) (when (null mark) (setf mark (make-instance 'standard-right-sticky-mark :buffer buffer))) (when (null syntax) (setf syntax (make-instance 'texinfo-syntax :pane pane))))) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From a_bakic at yahoo.com Thu Jan 6 10:48:47 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 6 Jan 2005 02:48:47 -0800 (PST) Subject: [climacs-devel] redisplay bug? Message-ID: <20050106104847.15283.qmail@web40622.mail.yahoo.com> Hi, I am testing an implementation of a buffer that uses a persistent data structure. This buffer's size changes with every operation (insert, delete) and there are no gaps. I noticed the following: when I start Climacs using this buffer type, enter "123", then delete the "3", I get the error below. I traced my buffer and it seems fine; I just do not know why Climacs tries to get an object at offset 2 once there are only two letters in the buffer ("12"). I will try to see if the problem is on my part (as I had to modify Climacs code to fit my buffer type in) but perhaps someone more familiar with the redisplay code may want to take a look. Thanks, Alex No such offset: 2 [Condition of type CLIMACS-BUFFER:NO-SUCH-OFFSET] Restarts: 0: [CONTINUE] Retry assertion. 1: [ABORT] Abort handling SLIME request. 2: [ABORT] Return to Top-Level. Backtrace: 0: (LISP::ASSERT-ERROR (<= 0 CLIMACS-BUFFER:OFFSET (1- #)) NIL #) 1: ((METHOD CLIMACS-BUFFER:BUFFER-OBJECT NIL (CLIMACS-BUFFER:BINSEQ-BUFFER T)) (#(7) . #(#)) # # 2) 2: (CLIMACS-BASE::BUFFER-NUMBER-OF-LINES-IN-REGION # 2 3) 3: ((METHOD CLIMACS-SYNTAX::COMPUTE-CACHE NIL (T CLIMACS-SYNTAX:BASIC-SYNTAX)) (#(2 8 1) . #()) # # #) 4: ((METHOD CLIMACS-SYNTAX:REDISPLAY-WITH-SYNTAX NIL (T CLIMACS-SYNTAX:BASIC-SYNTAX)) (#(8 4 5 3 1) . #()) # # #) 5: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) # # # ...) 6: (CLIM-INTERNALS::%INVOKE-UPDATING # # #) 7: ((METHOD CLIM-INTERNALS::COMPUTE-NEW-OUTPUT-RECORDS-1 NIL (CLIM:STANDARD-UPDATING-OUTPUT-RECORD T T)) (#(4 NIL 4 23) . #(# #)) # # # ...) 8: ((FLET #:CONTINUATION0) #) 9: ((METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) #<#1=unused-arg> #<#1#> # # ...) 10: ((METHOD CLIM:REDISPLAY-OUTPUT-RECORD NIL (CLIM:UPDATING-OUTPUT-RECORD CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN)) (#(20) . #(# # #)) # # # ...) 11: ((METHOD CLIM:REDISPLAY-FRAME-PANE (:AROUND) (CLIM:APPLICATION-FRAME T)) (#(21 21) . #()) #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL (# . #) :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL # :ARG-INFO #) :ARG-INFO (2 . T)) # # ...) 12: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 13: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 14: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 15: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 16: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 17: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#)) # # #) 18: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G7513 G7514 G7515)" #<#1=unused-arg> #<#1#> # NIL) 19: (CLIMACS-GUI::CLIMACS-TOP-LEVEL # :COMMAND-PARSER # :COMMAND-UNPARSER ...) 20: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#(20) . #()) #<#1=unused-arg> # #<#1#>) 21: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) #1=(CLIM:APPLICATION-FRAME)) (#(16 15) . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL (# . #) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) 22: (SWANK::EVAL-REGION "(climacs-gui::climacs) " T) 23: ("DEFSLIMEFUN LISTENER-EVAL") 24: (SWANK:LISTENER-EVAL "(climacs-gui::climacs) __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From matley at muppetslab.org Thu Jan 6 11:52:03 2005 From: matley at muppetslab.org (Luigi Panzeri) Date: Thu, 06 Jan 2005 12:52:03 +0100 Subject: [climacs-devel] latest progress In-Reply-To: <16859.31726.167911.263807@serveur5.labri.fr> (Robert Strandh's message of "Wed, 5 Jan 2005 06:32:30 +0100") References: <16859.31726.167911.263807@serveur5.labri.fr> Message-ID: <87wtuqai70.fsf@matley.muppetslab.org> Robert Strandh writes: > Do not hesitate taking on even minor tasks such as fixing a bug or > adding documentation strings. And please add your favorite Emacs > command that is currently missing from Climacs, but please let us know > (by mailing to this list) what you are working on in that case. > Hi, i am lookig at climacs, which i consider a nice project. I wrote for fun a little function for the buffer library that implements the dabbrev-expand function (plus two utility function), commonly keybinded with M-/ on emacs (one of my favourite command for writing texts) It tries to expand the current word in one that is found in the buffer. It works incrementally, using a closure and avoid duplicated expansion. It is not a beautiful code imho, but it works well. I don not have a lot of real experience with cl programming, so i have many doubts about design and style. I ll try to change it, but i ll be happy if you look at it and point me what could be wrong. (in-package :climacs-buffer) ;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Dynamic Abbrev ;;; Simple implementation ;;;;;;;;;;;;;;;;;;;;;;;;; (defun previous-word (mark) "Return a freshly allocated sequence, that is word before the mark" (region-to-sequence (loop for i downfrom (1- (offset mark)) until (zerop i) while (constituentp (buffer-object (buffer mark) (1- i))) finally (return i)) mark)) (defun buffer-search-word-backward (buffer offset word &key (test #'eql)) "return the largest offset of BUFFER <= (- OFFSET (length WORD)) containing WORD as a word or NIL if no such offset exists" (loop for i downfrom (- offset (length word)) to 0 when (and (or (zerop i) (whitespacep (buffer-object buffer (1- i)))) (buffer-looking-at buffer i word :test test)) return i finally (return nil))) (let ((last-match-off nil) (matches nil) (cur-search nil)) (defun dabbrev-expand (mark) "Expand word, dynamically. Expands to the most recent, preceding word for which it is a prefix. Move mark and insert text." (flet ((sequence-equal (s1 s2) (not (mismatch s1 s2)))) (let ((word (previous-word mark)) (buffer (buffer mark))) (unless (and last-match-off ;; restart search (member word matches :test #'sequence-equal) (search cur-search word) (zerop (search cur-search word))) (setf cur-search word matches nil last-match-off (offset mark))) (backward-delete-word mark) (let* ((new-match-off (buffer-search-word-backward buffer last-match-off cur-search :test #'eql)) (new-match (if new-match-off (buffer-sequence buffer new-match-off (loop for i upfrom new-match-off while (constituentp (buffer-object buffer i)) finally (return i))) cur-search))) (setf last-match-off new-match-off) (insert-sequence mark new-match) (if (and new-match-off (member new-match matches :test #'sequence-equal)) (dabbrev-expand mark) (pushnew new-match matches :test #'sequence-equal))))))) (in-package :climacs-gui) (define-named-command com-dabbrev-expand () (dabbrev-expand (point (win *application-frame*)))) (global-set-key '(#\/ :meta) 'com-dabbrev-expand) -- Luigi Panzeri From a_bakic at yahoo.com Thu Jan 6 12:37:46 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 6 Jan 2005 04:37:46 -0800 (PST) Subject: [climacs-devel] redisplay bug? In-Reply-To: <20050106104847.15283.qmail@web40622.mail.yahoo.com> Message-ID: <20050106123746.58540.qmail@web40626.mail.yahoo.com> Hm, it seems that Climacs creates 14 markers behind the scenes. I may have to review my code for updating cursors/markers, especially those near the end of the buffer. Alex > Backtrace: > 0: (LISP::ASSERT-ERROR (<= 0 CLIMACS-BUFFER:OFFSET (1- #)) NIL > #) __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From strandh at labri.fr Thu Jan 6 12:57:02 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 6 Jan 2005 13:57:02 +0100 Subject: [climacs-devel] Some small patches In-Reply-To: References: Message-ID: <16861.13726.118758.977818@serveur5.labri.fr> Hello Rudi. Rudi Schlatte writes: > > Just to mingle with the cool kids, I've superficially browsed the > climacs code. I must say it was an enjoyable read, very clean and > with good naming and structure. Thank you. That's good to hear. > I append some proposed fixes for > things that caught my eye; since I haven't even downloaded the code > locally, it's in the form of whole, modified functions, for which I > apologize. No problem. > 1) buffer.lisp: buffer-sequence conses unnecessarily, since the length > of > the result vector is known; the following (untested) might be > better. As before, the case of offset1 > offset2 returns a > zero-length vector, but this is more apparent in the code now. > > (defmethod buffer-sequence ((buffer standard-buffer) offset1 offset2) > ;; untested, for illustration purposes only > (assert (<= 0 offset1 (size buffer)) () > (make-condition 'no-such-offset :offset offset1)) > (assert (<= 0 offset2 (size buffer)) () > (make-condition 'no-such-offset :offset offset2)) > (if (< offset1 offset2) > (let ((result (make-array (list (- offset2 offset1))))) > (loop for offset from offset1 below offset2 > for i upfrom 0 > do (setf (svref result i) (buffer-object buffer offset))) > result) > (make-array '(0)))) I took this idea but modified your code a bit. In particular I removed some of your consing :) in your call to make-array. > 2) gui.lisp could use a method > > (defmethod frame-standard-output ((frame climacs)) > (get-frame-pane frame 'int)) > > (if the minibuffer is indeed the standard-output, of course), It is not. It is *standard-input* in fact. And *standard-input* and *standard-output* are bound by the toplevel loop. But it might be a good idea, to bind something like *error-output*. I'll have to think about that some more. > so that > the function display-message can display to *standard-output* instead > of *standard-input*. > > 3) Also, in gui.lisp, initialize-instance shouldn't unconditionally > clobber the syntax: > > (defmethod initialize-instance :after ((pane climacs-pane) &rest args) > (declare (ignore args)) > (with-slots (buffer point syntax mark) pane > (when (null point) > (setf point (make-instance 'standard-right-sticky-mark > :buffer buffer))) > (when (null mark) > (setf mark (make-instance 'standard-right-sticky-mark > :buffer buffer))) > (when (null syntax) > (setf syntax (make-instance 'texinfo-syntax :pane pane))))) OK, but that required adding an :initform to the syntax in the class. Thanks again, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Thu Jan 6 16:31:24 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 6 Jan 2005 17:31:24 +0100 Subject: [climacs-devel] latest progress In-Reply-To: <87wtuqai70.fsf@matley.muppetslab.org> References: <16859.31726.167911.263807@serveur5.labri.fr> <87wtuqai70.fsf@matley.muppetslab.org> Message-ID: <16861.26588.533132.982617@serveur5.labri.fr> Luigi Panzeri writes: > i am lookig at climacs, which i consider a nice project. I wrote for > fun a little function for the buffer library that implements the > dabbrev-expand function (plus two utility function), commonly > keybinded with M-/ on emacs (one of my favourite command for writing > texts) Thanks for doing that. I need a few days to go through your code and send you the comments, but most of it seem OK, though I would not necessarily put it where you suggest. I might just modify it where I think appropriate and stick it in. Thanks again. -- 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 rudi at constantly.at Thu Jan 6 18:41:23 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Thu, 6 Jan 2005 19:41:23 +0100 Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/gui.lisp In-Reply-To: <20050106164113.8322E884BC@common-lisp.net> References: <20050106164113.8322E884BC@common-lisp.net> Message-ID: <90CE40F5-6012-11D9-815F-000A95717856@constantly.at> On 6. J?n 2005, at 17:41, Robert Strandh wrote: > Update of /project/climacs/cvsroot/climacs > In directory common-lisp.net:/tmp/cvs-serv18560 > > Modified Files: > gui.lisp > Log Message: > Improved next- and previous-line commands so that a sequence > of such commands tries to preserve the original column. > > Date: Thu Jan 6 17:41:11 2005 > Author: rstrandh [snip] > +(defvar *previous-command*) > +(defvar *goal-column*) Will there ever be two climacs instances / frames running at the same time? In this case, previous-command and goal-column should be slots of the climacs frame, I think. Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From strandh at labri.fr Thu Jan 6 18:57:37 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 6 Jan 2005 19:57:37 +0100 Subject: [climacs-devel] Re: [climacs-cvs] CVS update: climacs/gui.lisp In-Reply-To: <90CE40F5-6012-11D9-815F-000A95717856@constantly.at> References: <20050106164113.8322E884BC@common-lisp.net> <90CE40F5-6012-11D9-815F-000A95717856@constantly.at> Message-ID: <16861.35361.368853.819360@serveur5.labri.fr> Rudi Schlatte writes: > Will there ever be two climacs instances / frames running at the same > time? In this case, previous-command and goal-column should be slots > of the climacs frame, I think. Yes, you are right. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Fri Jan 7 07:17:58 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 7 Jan 2005 08:17:58 +0100 Subject: [climacs-devel] latest progress In-Reply-To: <87wtuqai70.fsf@matley.muppetslab.org> References: <16859.31726.167911.263807@serveur5.labri.fr> <87wtuqai70.fsf@matley.muppetslab.org> Message-ID: <16862.14246.156784.715237@serveur5.labri.fr> Hello again, Luigi Panzeri writes: > i am lookig at climacs, which i consider a nice project. I wrote for > fun a little function for the buffer library that implements the > dabbrev-expand function (plus two utility function), commonly > keybinded with M-/ on emacs (one of my favourite command for writing > texts) I took your idea, but implemented it differently: * first, I wanted different behavior when two consecutive dabbrev-expand commands were executed. * second, I wanted it search forward in the buffer after having reached the beginning of the buffer. I kept your utility command (and added one for forward search). My implementation has been committed, or will be soon if you want to look at it. Thanks for helping out, -- 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 Sat Jan 8 09:30:59 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 8 Jan 2005 01:30:59 -0800 (PST) Subject: [climacs-devel] overwrite mode Message-ID: <20050108093059.42003.qmail@web40607.mail.yahoo.com> Hi, Should there be a buffer primitive, e.g., update-buffer-object, for the overwrite mode (instead of a pair delete-insert)? I suppose the overwrite mode could be handled in the com-self-insert command: call update-object (marks are unaffected) unless we are at the end of the buffer, in which case we call the usual insert-object. Better ideas? Alex __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From strandh at labri.fr Sat Jan 8 10:46:07 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 8 Jan 2005 11:46:07 +0100 Subject: [climacs-devel] overwrite mode In-Reply-To: <20050108093059.42003.qmail@web40607.mail.yahoo.com> References: <20050108093059.42003.qmail@web40607.mail.yahoo.com> Message-ID: <16863.47599.972196.42677@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > Should there be a buffer primitive, e.g., update-buffer-object, for the > overwrite mode (instead of a pair delete-insert)? I suppose the overwrite mode > could be handled in the com-self-insert command: call update-object (marks are > unaffected) unless we are at the end of the buffer, in which case we call the > usual insert-object. Better ideas? I would put it in base.lisp and make it a combination of (setf buffer-object) and forward-mark. -- 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 Sat Jan 8 12:28:20 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 8 Jan 2005 04:28:20 -0800 (PST) Subject: [climacs-devel] overwrite mode In-Reply-To: <16863.47599.972196.42677@serveur5.labri.fr> Message-ID: <20050108122820.1567.qmail@web40604.mail.yahoo.com> > I would put it in base.lisp and make it a combination of (setf > buffer-object) and forward-mark. I suppose you meant that the point should be moved one place to the right. How would (setf buffer-object) relate to undo, for example? (Have you intentionally omitted this from the buffer protocol for some reason?) Should there also be a primitive for overwriting a sequence? I don't think I ever used something like that, though, but one might want to yank a sequence in the overwrite mode. Alex __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From rudi at constantly.at Sun Jan 9 13:37:55 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Sun, 9 Jan 2005 14:37:55 +0100 Subject: [climacs-devel] upcase-word, downcase-word, capitalize-word Message-ID: Hi, Here's an implementation of the emacs commands M-u, M-l, M-c for climacs. (I removed the binding of M-u to com-browse-url, hope that's ok.) Comments from the style office are welcome, as always :) Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: frob-words.patch Type: application/octet-stream Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From a_bakic at yahoo.com Sun Jan 9 14:14:18 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 9 Jan 2005 06:14:18 -0800 (PST) Subject: [climacs-devel] per-buffer data Message-ID: <20050109141418.1568.qmail@web40610.mail.yahoo.com> Hi, I noticed that *overwrite-mode* should not be global, but per-buffer, like in Emacs (and not per-pane, like goal-column, because I suppose there could be multiple panes showing the same buffer; I do not know whether goal-column should be per-buffer, too). How should we go about this: adding slots to standard-buffer or using a subclass of it?.. Alex __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From a_bakic at yahoo.com Sun Jan 9 14:38:20 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 9 Jan 2005 06:38:20 -0800 (PST) Subject: [climacs-devel] per-buffer data In-Reply-To: <20050109141418.1568.qmail@web40610.mail.yahoo.com> Message-ID: <20050109143820.43150.qmail@web40612.mail.yahoo.com> > How should we go about this: adding slots to > standard-buffer or using a subclass of it?.. A mixin class could do, I guess. Alex __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From strandh at labri.fr Sun Jan 9 15:40:34 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 9 Jan 2005 16:40:34 +0100 Subject: [climacs-devel] per-buffer data In-Reply-To: <20050109141418.1568.qmail@web40610.mail.yahoo.com> References: <20050109141418.1568.qmail@web40610.mail.yahoo.com> Message-ID: <16865.20594.832517.950456@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > I noticed that *overwrite-mode* should not be global, but per-buffer, like in > Emacs (and not per-pane, like goal-column, because I suppose there could be > multiple panes showing the same buffer; I do not see why overwrite mode could not be per-pane. It's an input mode, and does not influence the contents of the buffer. > I do not know whether goal-column > should be per-buffer, too). Good question. I don't know. It could go either way. > How should we go about this: adding slots to > standard-buffer or using a subclass of it?.. Probably mixins, as you pointed out later. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Sun Jan 9 15:46:44 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 9 Jan 2005 16:46:44 +0100 Subject: [climacs-devel] overwrite mode In-Reply-To: <20050108122820.1567.qmail@web40604.mail.yahoo.com> References: <16863.47599.972196.42677@serveur5.labri.fr> <20050108122820.1567.qmail@web40604.mail.yahoo.com> Message-ID: <16865.20964.831440.821286@serveur5.labri.fr> Aleksandar Bakic writes: > > I would put it in base.lisp and make it a combination of (setf > > buffer-object) and forward-mark. > > I suppose you meant that the point should be moved one place to the right. How > would (setf buffer-object) relate to undo, for example? I don't know. I guess a compound undo record could be used. The reason I am suggesting a combination of (setf buffer-object) and forward-mark, is that it is potentially more efficient. On the other hand, the real question is about semantics. If you have the text: abcdef with the point between the c and the d, and a right-sticky mark at the same place, then using a combination between delete and insert to overwrite the d will put the mark between the d and the e, whereas using a combination of (setf buffer-object) and forward-mark will leave it between the c and the d. The analogous thing happens to a left-sticky mark initially between the d and the e. > (Have you intentionally > omitted this from the buffer protocol for some reason?) This? Overwrite? No, I just don't ever use it myself. > Should there also be a > primitive for overwriting a sequence? I don't think I ever used something like > that, though, but one might want to yank a sequence in the overwrite mode. Sure, someone that uses overwrite mode might want to do that. -- 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 Sun Jan 9 22:11:38 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 9 Jan 2005 14:11:38 -0800 (PST) Subject: [climacs-devel] overwrite mode In-Reply-To: <16865.20964.831440.821286@serveur5.labri.fr> Message-ID: <20050109221138.89570.qmail@web40613.mail.yahoo.com> > I don't know. I guess a compound undo record could be used. The > reason I am suggesting a combination of (setf buffer-object) and > forward-mark, is that it is potentially more efficient. I also had efficiency in mind. For a start, I committed a delete-insert combination (only within com-self-insert; I noticed in Emacs that Yank ignores Overwrite mode, for example). > On the other hand, the real question is about semantics. Right. If an overwrite should not affect marks, then neither a delete-insert combination nor using a compound undo record (with an insert and a delete) with (setf buffer-object) will work. Notice that Overwrite mode works like Insert mode at the end of the line. Unless someone knows the definition, perhaps we can define it whatever works for us. Alex __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From strandh at labri.fr Thu Jan 13 06:15:12 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 13 Jan 2005 07:15:12 +0100 Subject: [climacs-devel] latest progress Message-ID: <16870.4592.862881.36840@serveur5.labri.fr> Hello, This message is mostly for those who do not read climacs-cvs and who do not participate in the #lisp IRC channel. More people are getting involved in Climacs development, which is good. I continue to take care of the basic stuff like redisplay and such, whereas others provide Emacs-like functionality. This is a good division of labor, because in order to provide new functionality, all you need to know is the buffer protocols which are well documented. Climacs now has the basic infrastructure for numeric arguments. One simple thing to work on would thus be to add &optional (n 1) to a number of functions such as the ones in base.lisp or buffer.lisp. If you do, first make sure the modification you introduce is backward compatible and also do not forget to update the documentation at the same time. Notice though, that this functionality requires a working unread-gesture, which was put into CVS McCLIM only a few days ago. Do not update your Climacs source before updating your McCLIM source. In order to have numeric arguments behave like in Emacs, we need to extend how CLIM handles numeric arguments. It is not enough to have a *numeric-argument-marker*, because Emacs can behave differently if no numeric argument was given and when a numeric argument of 1 was given. Adding that possibility to Climacs will require something like a *numeric-argument-flag* to indicate whether a numeric argument was given at all. Now that unread-gesture works, I am thinking of attacking incremental search next, though, if someone else feels like working on that, that would be fine as well. Recent improvements: * next-line and previous-line commands now follow columns just like Emacs does. * fixed a nasty problem in buffer.lisp (thanks to Matthieu Villeneuve) that was correct (but not great coding practice) but exposed a bug in CMUCL. * implemented an improved version of buffer-sequence according to a suggestion by Rudi Schlatte, as well as another minor style improvement, also from him. * implemented dynamic abbrev expansion (M-/) as suggested by Luigi Panzeri, and integrated his utility function into base.lisp. * fixed a bug in redisplay. * added numeric arguments. This feature requires a CVS version of McCLIM as of 2005-01-11. Only a few commands take numeric arguments at the moment such as forward-object, backward-object, delete-object, and backward-delete-object. There are more to come. * the cursor display problem has been "fixed" by drawing a rectangle rather than a line. This makes obsolete the hacky code for explicit rounding of cursor coordinates. Also made the cursor somewhat wider so that it is easier to find. * abbrevs work again (I am not sure when the got broken) * implemented a new command: load-file * probably some things I forgot. What is being worked on: * multi-buffer, multi-window (expect some partial commits soon) * upcase-region, downcase-region, capitalize-region (imminent) * probably some things I don't know about. Enjoy, -- 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 moore at bricoworks.com Fri Jan 14 16:15:48 2005 From: moore at bricoworks.com (Timothy Moore) Date: Fri, 14 Jan 2005 17:15:48 +0100 Subject: [climacs-devel] OpenMCL fixes Message-ID: <8D89895F-6647-11D9-820C-000A959839F8@bricoworks.com> I committed some changes to the Flexichain module that fix the problems that climacs had in OpenMCL. Support for weak pointers in implementations other than CMUCL and SBCL was missing. Tim From strandh at labri.fr Fri Jan 14 16:51:35 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 14 Jan 2005 17:51:35 +0100 Subject: [climacs-devel] OpenMCL fixes In-Reply-To: <8D89895F-6647-11D9-820C-000A959839F8@bricoworks.com> References: <8D89895F-6647-11D9-820C-000A959839F8@bricoworks.com> Message-ID: <16871.63639.433047.180807@serveur5.labri.fr> Timothy Moore writes: > I committed some changes to the Flexichain module that fix the problems > that climacs had in OpenMCL. Support for weak pointers in > implementations other than CMUCL and SBCL was missing. Thanks for doing that. I had totally forgotten how CMUCL/SBCL dependent that part was. I should have put in a message at least to avoid extra work for you. -- 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 Fri Jan 14 20:22:31 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 14 Jan 2005 12:22:31 -0800 (PST) Subject: [climacs-devel] A minor bug in Flexichain/utilities.lisp Message-ID: <20050114202232.344.qmail@web40607.mail.yahoo.com> Hi, Without the following patch, a defclass fails for me (CMUCL). Alex > cvs diff utilities.lisp Index: utilities.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/Flexichain/utilities.lisp,v retrieving revision 1.2 diff -r1.2 utilities.lisp 44a45 > #-openmcl() __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From a_bakic at yahoo.com Fri Jan 14 21:33:03 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 14 Jan 2005 13:33:03 -0800 (PST) Subject: [climacs-devel] buffer-object vs. element* and such Message-ID: <20050114213303.43759.qmail@web40608.mail.yahoo.com> Hi, Some recent changes to buffer.lisp broke my experimental code that uses a non-standard buffer class. Namely, code like this: (defmethod end-of-line ((mark mark-mixin)) (let* ((offset (offset mark)) (buffer (buffer mark)) (chain (slot-value buffer 'contents)) (size (nb-elements chain))) (loop until (or (= offset size) (eql (element* chain offset) #\Newline)) do (incf offset)) (setf (offset mark) offset))) The above method is specialized on mark-mixin only, not on standard-buffer. However, since recently it calls nb-elements and element*. I would rather see size and buffer-object instead. There are similar calls in, say, redisplay-with-syntax in syntax.lisp, where one would expect the code not to depend on flexichain. On other places, such as caching for fast redisplay, the dependence on flexichain is explicit and that is fine with me (I need to take a closer look at caching and see how it relates to non-standard buffers). Please let me know if I can make changes wrt. the above arguments or if you have objections. Thanks, Alex __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From a_bakic at yahoo.com Fri Jan 14 23:16:05 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 14 Jan 2005 15:16:05 -0800 (PST) Subject: [climacs-devel] buffer-object vs. element* and such In-Reply-To: <20050114213303.43759.qmail@web40608.mail.yahoo.com> Message-ID: <20050114231605.49735.qmail@web40612.mail.yahoo.com> > There are similar calls in, say, > redisplay-with-syntax in syntax.lisp, where one would expect the code not to > depend on flexichain. Actually, this is fine, I forgot to coerce the result of my buffer-sequence method to vector, like in the case of standard-buffer... BTW, the protocol says this method should return a sequence, not necessarily a vector. Method display-line in syntax.lisp assumes that line is a vector without explicitly specializing the line formal on it. Alex __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From moore at bricoworks.com Sat Jan 15 08:45:13 2005 From: moore at bricoworks.com (Timothy Moore) Date: Sat, 15 Jan 2005 09:45:13 +0100 Subject: [climacs-devel] A minor bug in Flexichain/utilities.lisp In-Reply-To: <20050114202232.344.qmail@web40607.mail.yahoo.com> References: <20050114202232.344.qmail@web40607.mail.yahoo.com> Message-ID: Thanks for noticing this. I've checked in a fix to Flexichain; give it a try. Tim On Jan 14, 2005, at 9:22 PM, Aleksandar Bakic wrote: > Hi, > > Without the following patch, a defclass fails for me (CMUCL). > > Alex > >> cvs diff utilities.lisp > Index: utilities.lisp > =================================================================== > RCS file: /project/gsharp/cvsroot/gsharp/Flexichain/utilities.lisp,v > retrieving revision 1.2 > diff -r1.2 utilities.lisp > 44a45 >> #-openmcl() > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel From strandh at labri.fr Sun Jan 16 06:25:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 16 Jan 2005 07:25:21 +0100 Subject: [climacs-devel] buffer-object vs. element* and such In-Reply-To: <20050114213303.43759.qmail@web40608.mail.yahoo.com> References: <20050114213303.43759.qmail@web40608.mail.yahoo.com> Message-ID: <16874.2257.874356.423144@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > Hi, > > Some recent changes to buffer.lisp broke my experimental code that uses a > non-standard buffer class. Namely, code like this: > > (defmethod end-of-line ((mark mark-mixin)) > (let* ((offset (offset mark)) > (buffer (buffer mark)) > (chain (slot-value buffer 'contents)) > (size (nb-elements chain))) > (loop until (or (= offset size) > (eql (element* chain offset) #\Newline)) > do (incf offset)) > (setf (offset mark) offset))) > > The above method is specialized on mark-mixin only, not on standard-buffer. > However, since recently it calls nb-elements and element*. I would rather see > size and buffer-object instead. I think I did that because I needed the additional speed. And it is a temporary hack because with a buffer implementation using lines, it would have an immediate implementation anyway. > There are similar calls in, say, > redisplay-with-syntax in syntax.lisp, where one would expect the code not to > depend on flexichain. No, that's not quite true. The calls to the flexichain functions in that case have nothing to do with the buffer, only with the fact that the cache uses a flexichain to hold lines. > On other places, such as caching for fast redisplay, the > dependence on flexichain is explicit and that is fine with me (I need to take a > closer look at caching and see how it relates to non-standard buffers). I think that's the only dependence. > Please let me know if I can make changes wrt. the above arguments or if you > have objections. I am afraid I must object. end-of-line was a major bottleneck and needed more speed. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Sun Jan 16 06:26:08 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 16 Jan 2005 07:26:08 +0100 Subject: [climacs-devel] buffer-object vs. element* and such In-Reply-To: <20050114231605.49735.qmail@web40612.mail.yahoo.com> References: <20050114213303.43759.qmail@web40608.mail.yahoo.com> <20050114231605.49735.qmail@web40612.mail.yahoo.com> Message-ID: <16874.2304.997907.138798@serveur5.labri.fr> Aleksandar Bakic writes: > Actually, this is fine, I forgot to coerce the result of my buffer-sequence > method to vector, like in the case of standard-buffer... BTW, the protocol says > this method should return a sequence, not necessarily a vector. Method > display-line in syntax.lisp assumes that line is a vector without explicitly > specializing the line formal on it. Yes, the protocol description needs to be changed. -- 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 rudi at constantly.at Mon Jan 17 12:10:51 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Mon, 17 Jan 2005 13:10:51 +0100 Subject: [climacs-devel] Some cleanups Message-ID: Hi, The attached patch removes compile-time warnings throughout and OAOOs some code in text-syntax.lisp (this part should be reviewed by the committer since it was written in a sleep-deprived/caffeine-rush state of mind, but beginning-of-paragraph / end-of-paragraph seem to be working as well as before). Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: frob-text-syntax.diff Type: application/octet-stream Size: 5679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ignas.mikalajunas at gmail.com Mon Jan 17 21:09:55 2005 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Mon, 17 Jan 2005 23:09:55 +0200 Subject: [climacs-devel] Dead escape key Message-ID: By default in emacs, and on linux in general Esc key serves as meta modifier. I guess this can be implemented in a more elegand manner yet here is the patch. --- gui.lisp 17 Jan 2005 13:35:52 -0000 1.78 +++ gui.lisp 17 Jan 2005 21:04:19 -0000 @@ -791,9 +791,29 @@ (make-command-table 'global-climacs-table :errorp nil) +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; +;;; +;;; Dead-escape command table + +(make-command-table 'dead-escape-climacs-table :errorp nil) + +(add-menu-item-to-command-table 'global-climacs-table "dead-escape" + :menu 'dead-escape-climacs-table + :keystroke '(:escape)) + +(defun dead-escape-set-key (gesture command) + (add-command-to-command-table command 'dead-escape-climacs-table + :keystroke gesture :errorp nil)) + (defun global-set-key (gesture command) (add-command-to-command-table command 'global-climacs-table - :keystroke gesture :errorp nil)) + :keystroke gesture :errorp nil) + (when (and + (listp gesture) + (find :meta gesture)) + (dead-escape-set-key (remove :meta gesture) command))) + + (loop for code from (char-code #\space) to (char-code #\~) do (global-set-key (code-char code) 'com-self-insert)) Ignas Mikalajunas From rudi at constantly.at Tue Jan 18 13:34:55 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Tue, 18 Jan 2005 14:34:55 +0100 Subject: [climacs-devel] base.lisp patches Message-ID: Hi, This fixes delete-indentation (it was deleting non-whitespace non-alphanumeric characters), provides shorter and (potentially) more efficient (backward-)delete-word and checks for an error case in number-of-lines-in-region. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: frob-base.patch Type: application/octet-stream Size: 2605 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From rudi at constantly.at Tue Jan 18 16:04:16 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Tue, 18 Jan 2005 17:04:16 +0100 Subject: [climacs-devel] [Patch] ignore argument error in delete-region + misc fixes Message-ID: <9A4E91EE-696A-11D9-815F-000A95717856@constantly.at> Hi, As discussed on irc, here's a patch that makes (delete-region mark1 mark2) and (delete-region mark2 mark1) do the same thing, instead of silently doing nothing in one of the cases. The documentation is updated, as are the tests. Additionally, there's a general clone-mark function and a fixed transpose-lines (I observed it pasting the new lower line on the end of the following line instead of inserting it before). Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: delete-region.patch Type: application/octet-stream Size: 7718 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From wencel at gmail.com Tue Jan 18 22:24:47 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Tue, 18 Jan 2005 22:24:47 +0000 Subject: [climacs-devel] Don't create file until save. Message-ID: <2b1f8a5b0501181424711dd8e9@mail.gmail.com> Hi there, here's a patch that ensures that com-find-file doesn't create a file if it doesn't exist already, instead, the file is only written when saved. Lawrence -- Lawrence Mitchell -------------- next part -------------- A non-text attachment was scrubbed... Name: gui.lisp.patch Type: text/x-patch Size: 881 bytes Desc: not available URL: From strandh at labri.fr Wed Jan 19 05:29:05 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 19 Jan 2005 06:29:05 +0100 Subject: [climacs-devel] Don't create file until save. In-Reply-To: <2b1f8a5b0501181424711dd8e9@mail.gmail.com> References: <2b1f8a5b0501181424711dd8e9@mail.gmail.com> Message-ID: <16877.61473.751871.721831@serveur5.labri.fr> Patch applied. 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 strandh at labri.fr Wed Jan 19 05:41:13 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 19 Jan 2005 06:41:13 +0100 Subject: [climacs-devel] progress report Message-ID: <16877.62201.398274.537746@serveur5.labri.fr> Dear list member, This message is mostly for people who are not members of the climacs-cvs mailing list and who do not follow the discussion on the #lisp IRC channel. This has been a fantastic week for Climacs in terms of progress. Many people have implemented new functionality, factored existing code, or proposed bug fixes. On the downside, it appears that only one out of three student projects was taken (Common Lisp syntax). On the other hand, if this is confirmed, that leaves the implementation of the undo protocol and of the new buffer representation to some of you that are eager to get these functionalities working. Here is a list of the past week's accomplishments: * overwrite mode. (thanks to Alexandar Bakic) * new functionality: {downcase,upcase-capitilze}-region. (thanks to Matthieu Villeneuve) * new in the buffer protocol (setf buffer-object). (thanks to Matthieu Villeneuve) * code factoring in the form of a do-buffer-region macro. (thanks to Matthieu Villeneuve) * did a major overhaul of the syntax facility. The previous functionality is now divided into three parts: the first one is the real syntax, associated with the buffer instead of with the pane. The second part is the cache management, now associated with the pane instead of with the syntax. The third part is a CLIM view, associated with the pane, which determines presentation parameters such as highlighting. * tabify and untabify region commands. (thanks to Matthieu Villeneuve) * implemented beginning-of-paragraph and end-of-paragraph, the first commands to exploit a syntax, in this case text-syntax. * minor fixes in buffer.lisp and addition of a framework for regression testing of the buffer implementation. (thanks to Aleksandar Bakic) * new command: delete-indentation. (thanks to Matthieu Villeneuve) * implemented full-redisplay (C-l). * implemented multi-buffer support, with C-x b bound to the command switch-to-buffer. Buffer completion works as expected. * implemented preliminary multi-window support. C-x 2 splits the window vertically, C-x splits horizontally. C-x 0 deletes the current window. This is still preliminary code. One annoying problem is that the entire frame gets resized whenever a new window is added or deleted. * code factoring in text-syntax.lisp (thanks to Rudi Schlatte) * new commands (bound to TAB and C-j) for indenting lines according to the syntax. (thanks to Matthieu Villeneuve) * a key sequence such as ESC now works the same way as they keystroke M-. (thanks to Ignas Mikalajunas) * delete-region now works independently of the order between the two marks. (thanks to Rudi Schlatte and Aleksandar Bakic) * find-file does not create the file if it does not exist. (thanks to Lawrence Mitchell) -- 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 wencel at gmail.com Thu Jan 20 23:11:18 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Thu, 20 Jan 2005 23:11:18 +0000 Subject: [climacs-devel] Kill buffer function Message-ID: Hi there, now that embryonic multi-buffer support is emerging, it would be nice if one could kill buffers too. Something like this maybe: (define-named-command com-kill-buffer () (with-slots (buffers) *application-frame* (let ((buffer (buffer (current-window)))) (when (needs-saving buffer) ;; FIXME, needs a yes-or-no-p. (com-save-buffer)) (setf buffers (remove buffer buffers)) ;; Always need one buffer. (when (null buffers) (push (make-instance 'climacs-buffer :name "*scratch*") buffers)) (setf (buffer (current-window)) (car buffers))))) This also means that we need some kind of YES-OR-NO-P function that shadows CL:YES-OR-NO-P, since that looks for answers on *QUERY-IO*. (defun yes-or-no-p (format-string &rest arguments) (loop (let ((answer (string-downcase (accept 'string :prompt (apply #'format nil format-string arguments))))) (cond ((string-equal answer "yes") (return t)) ((string-equal answer "no") (return nil)) (t nil))))) would be a rather unfriendly version. I can't see anything in CLIM that deals for doing this, but maybe I'm missing something. -- Lawrence Mitchell From wencel at gmail.com Sun Jan 23 17:25:26 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Sun, 23 Jan 2005 17:25:26 +0000 Subject: [climacs-devel] Isearch backward. Message-ID: Hi there, here's a patch which allows for isearching backwards in a buffer as well as forward. I'm not sure if this is a nice way to do things, it introduces a special variable *ISEARCHING-BACKWARDS* (which probably ought to be a buffer/pane slot instead) which we bind to T if we're actually searching backwards. ISEARCH-FROM-MARK then calls SEARCH-FORWARD or SEARCH-BACKWARD as appropriate. This way we minimise the amount of code duplication between forward and backward search, though at the expense of making COM-ISEARCH-FORWARD not always do what it says. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 2509 bytes Desc: Patch for isearch-backward to gui.lisp URL: -------------- next part -------------- -- Lawrence Mitchell From a_bakic at yahoo.com Sun Jan 23 18:25:38 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 23 Jan 2005 10:25:38 -0800 (PST) Subject: [climacs-devel] number-of-lines-inregion Message-ID: <20050123182538.48869.qmail@web40607.mail.yahoo.com> Hi, Should the generic function number-of-lines-in-region be symmetrical wrt. its mark parameters? Recently, delete-region has been changed so that the order of mark offsets does not matter. In general, is there are rule by which one could decide whether an operator on two marks should care about the mark offset order or not? If number-of-lines-in-region should be changed as described above, I can do it (together with simplifying its use in pane.lisp). I will upload some more tests soon (I caught some (real) virus a couple of days ago...). Alex __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From rudi at constantly.at Sun Jan 23 18:53:16 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Sun, 23 Jan 2005 19:53:16 +0100 Subject: [climacs-devel] number-of-lines-inregion In-Reply-To: <20050123182538.48869.qmail@web40607.mail.yahoo.com> References: <20050123182538.48869.qmail@web40607.mail.yahoo.com> Message-ID: <0A6B8A6B-6D70-11D9-9318-000A95717856@constantly.at> On 23. J?n 2005, at 19:25, Aleksandar Bakic wrote: > Hi, > > Should the generic function number-of-lines-in-region be symmetrical > wrt. its > mark parameters? Recently, delete-region has been changed so that the > order of > mark offsets does not matter. I'd vote "yes". > In general, is there are rule by which one could > decide whether an operator on two marks should care about the mark > offset order > or not? My gut feeling is that code such as: (let ((mark1 (obtain-mark-1)) (mark2 (obtain-mark-2))) (operate-on-region mark1 mark2)) should not have to check and exchange marks manually. So, I think most operations on regions should be order-agnostic. Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From matthieu.villeneuve at free.fr Sun Jan 23 19:26:38 2005 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Sun, 23 Jan 2005 20:26:38 +0100 Subject: [climacs-devel] number-of-lines-inregion In-Reply-To: <0A6B8A6B-6D70-11D9-9318-000A95717856@constantly.at> References: <20050123182538.48869.qmail@web40607.mail.yahoo.com> <0A6B8A6B-6D70-11D9-9318-000A95717856@constantly.at> Message-ID: <1106508398.41f3fa6e3bb31@imp5-q.free.fr> Quoting Rudi Schlatte : > > On 23. J?n 2005, at 19:25, Aleksandar Bakic wrote: > > > Hi, > > > > Should the generic function number-of-lines-in-region be symmetrical > > wrt. its > > mark parameters? Recently, delete-region has been changed so that the > > order of > > mark offsets does not matter. > > I'd vote "yes". > > > In general, is there are rule by which one could > > decide whether an operator on two marks should care about the mark > > offset order > > or not? > > My gut feeling is that code such as: > > (let ((mark1 (obtain-mark-1)) (mark2 (obtain-mark-2))) > (operate-on-region mark1 mark2)) > > should not have to check and exchange marks manually. So, I think most > operations on regions should be order-agnostic. I agree, I'd vote "yes" too. I had written the function region-limits in gui.lisp, but in my opinion it solves the problem at the wrong place, callers of functions in base.lisp shouldn't worry about the order of marks. -- Matthieu Villeneuve From matthieu.villeneuve at free.fr Sun Jan 23 23:37:27 2005 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Mon, 24 Jan 2005 00:37:27 +0100 Subject: [climacs-devel] Isearch backward. In-Reply-To: References: Message-ID: <1106523447.41f435376de04@imp5-q.free.fr> Hello Lawrence, Quoting Lawrence Mitchell : > here's a patch which allows for isearching backwards in a buffer > as well as forward. I finally ended up continuing from what I had for backward isearch, which I think behaves a bit more like emacs' isearch, but the basic idea seems to be the same as that of your patch, with a direction parameter kept in the current search state. By the way, I would appreciate any comment on the code, as I'm really not sure I took the right path for that feature. Thanks, -- Matthieu Villeneuve From strandh at labri.fr Mon Jan 24 04:12:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 24 Jan 2005 05:12:21 +0100 Subject: [climacs-devel] number-of-lines-inregion In-Reply-To: <20050123182538.48869.qmail@web40607.mail.yahoo.com> References: <20050123182538.48869.qmail@web40607.mail.yahoo.com> Message-ID: <16884.30117.10901.388996@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > Should the generic function number-of-lines-in-region be symmetrical wrt. its > mark parameters? Recently, delete-region has been changed so that the order of > mark offsets does not matter. In general, is there are rule by which one could > decide whether an operator on two marks should care about the mark offset order > or not? Since delete-region has changed, it seems reasonable to apply the same rule everywhere. > If number-of-lines-in-region should be changed as described above, I can do it > (together with simplifying its use in pane.lisp). I will upload some more tests > soon (I caught some (real) virus a couple of days ago...). Sounds good to me. -- 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 wencel at gmail.com Mon Jan 24 12:24:19 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Mon, 24 Jan 2005 12:24:19 +0000 Subject: [climacs-devel] Regexs in climacs Message-ID: <2b1f8a5b05012404241142b98f@mail.gmail.com> Hi there, after my rather abortive attempts to try and define a delete-other-windows the other day, I thought I'd look at maybe supporting some kind of regex search in climacs. The obvious candidate for the matching is Edi Weitz's CL-PPCRE, after all, we don't want to do more work than we have to. The question then becomes, how do we match things? AFAICT, cl-ppcre matches on strings, so the naive way of hooking it into climacs is to return the buffer as a string, match against that, extract the offsets and then move POINT to the relevant place. This, however, doesn't seem particularly clean, will not be particularly efficient for large buffers, and completely ignores the fact that climacs buffers can contain general objects, rather than just characters. So, any suggestions? I suppose one could construct strings to match against "lazily", say, construct a string containing the current line's contents, try and match against that, if it doesn't match, trying matching on the current line and the next line as well. Alternately, find a nice way of hooking the cl-ppcre way of doing things into climacs' mode of operation. Lawrence -- Lawrence Mitchell From amoroso at mclink.it Mon Jan 24 13:00:30 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 24 Jan 2005 14:00:30 +0100 Subject: [climacs-devel] Regexs in climacs In-Reply-To: <2b1f8a5b05012404241142b98f@mail.gmail.com> (Lawrence Mitchell's message of "Mon, 24 Jan 2005 12:24:19 +0000") References: <2b1f8a5b05012404241142b98f@mail.gmail.com> Message-ID: <87ekgbm175.fsf@plato.moon.paoloamoroso.it> Lawrence Mitchell writes: > delete-other-windows the other day, I thought I'd look at maybe > supporting some kind of regex search in climacs. > > The obvious candidate for the matching is Edi Weitz's CL-PPCRE, after > all, we don't want to do more work than we have to. The question then > becomes, how do we match things? AFAICT, cl-ppcre matches on strings, [...] > So, any suggestions? I suppose one could construct strings to match I suggest that you Cc: Edi. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From a_bakic at yahoo.com Tue Jan 25 21:59:26 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Tue, 25 Jan 2005 13:59:26 -0800 (PST) Subject: [climacs-devel] left-sticky-mark, etc. Message-ID: <20050125215926.30530.qmail@web40610.mail.yahoo.com> Because of the following method (and the right counterpart) in buffer.lisp: (defmethod initialize-instance :after ((mark left-sticky-mark) &rest args &key (offset 0)) "Associates a created mark with the buffer it was created for." (declare (ignore args)) (assert (<= 0 offset (size (buffer mark))) () (make-condition 'no-such-offset :offset offset)) (setf (slot-value mark 'cursor) (make-instance 'left-sticky-flexicursor :chain (slot-value (buffer mark) 'contents) :position offset))) I had to define a new left-sticky-mark class because I did not use left-sticky-flexicursor. Then very recently, I extended open-line to work on left-sticky-mark and right-sticky-mark arguments, but it does not work on my new classes. I tried replacing left-sticky-mark with standard-left-sticky-mark above, and I did not see any problems. If these two :after methods were specialized on standard marks, I would not need extra classes and things would be simpler. Am I missing something? Alex __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From strandh at labri.fr Wed Jan 26 05:01:43 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 26 Jan 2005 06:01:43 +0100 Subject: [climacs-devel] left-sticky-mark, etc. In-Reply-To: <20050125215926.30530.qmail@web40610.mail.yahoo.com> References: <20050125215926.30530.qmail@web40610.mail.yahoo.com> Message-ID: <16887.9271.850141.653734@serveur5.labri.fr> Aleksandar Bakic writes: > Because of the following method (and the right counterpart) in buffer.lisp: > > (defmethod initialize-instance :after ((mark left-sticky-mark) &rest args &key > (offset 0)) > "Associates a created mark with the buffer it was created for." > (declare (ignore args)) > (assert (<= 0 offset (size (buffer mark))) () > (make-condition 'no-such-offset :offset offset)) > (setf (slot-value mark 'cursor) > (make-instance 'left-sticky-flexicursor > :chain (slot-value (buffer mark) 'contents) > :position offset))) > > I had to define a new left-sticky-mark class because I did not use > left-sticky-flexicursor. Then very recently, I extended open-line to work on > left-sticky-mark and right-sticky-mark arguments, but it does not work on my > new classes. I tried replacing left-sticky-mark with standard-left-sticky-mark > above, and I did not see any problems. If these two :after methods were > specialized on standard marks, I would not need extra classes and things would > be simpler. Am I missing something? Probably not. I think that must be a mistake. Go ahead and fix it if you like. -- 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 Wed Jan 26 05:37:35 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 26 Jan 2005 06:37:35 +0100 Subject: [climacs-devel] latest progress Message-ID: <16887.11423.795816.75304@serveur5.labri.fr> Dear mailing list member, We have had another amazing week of Climacs development. I keep telling myself that it will slow down very soon now, but that has not happened yet. At some point, though, we shall run out of fairly easy Emacs-like functionality to add, and we probably cannot expect this rate of progress anymore. When that will happen, I don't know. Here is a list of the progress that has been made this week: * Implemented keyboard macros * Auto-fill mode (thanks to Matthieu Villeneuve) * Test for climacs-base (thanks to Aleksandar Bakic) * Box ajuster gadget for changing size of windows [the code is in there but not enabled due to a problem that we cannot seem to find] (thanks to Nicolas Lamirault) * Kill-buffer command (thanks to Lawrence Mitchell) * Improved on the quit command so that Climacs asks to save buffers that need saving * Incremental search (thanks to Matthieu Villeneuve) * Implemented undo and redo Again, if someone feels like contributing, patches are welcome. Contributions can be of different kinds such as added functionality (probably the most gratifying), bug fixes (less so), code factoring, improvements to the architecture, contributions to the internals documentation, etc. There are still some major things to implement. Lawrence Mitchell is looking into using regular expressions, and my student project concerning Common Lisp syntax will soon start. Aleksandar Bakic is about to commit an alternative implementation of the buffer protocol based on so-called persistent data structures (in this context, "persistent" means that all previous states of the structure are automatically maintained) . This is interesting because given that the buffer protocol is fairly well defined, drop-in replacements should be possible. It might even be possible to have several different implementations in parallel, and to choose the one that is best suited to the editing task at hand. 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 csr21 at cam.ac.uk Wed Jan 26 18:32:20 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 26 Jan 2005 18:32:20 +0000 Subject: [climacs-devel] climacs-based application Message-ID: Hi, As some of you will no doubt know, I've been working on an application using climacs as the editor framework; the application is to provide visual feedback and other nifty things for a text-based language for lute tablature. Today, I got it to a basically working state; I got incremental parsing working early yesterday, incremental redisplay working late yesterday, and ironed out some bugs during the course of the day related to non-locality of various constructs -- in particular, the comment delimiters #\{ and #\} are fully-nestable in tabcode, which makes the incremental parsing aspect rather tricky. The code is available at ; if anyone wants to give it a try, please do -- "simply" load the tabcode and tabcode-gui systems, then (climacs-gui::climacs) and either Set Syntax SPC Tabcode or first load one of the .tc files in that source distribution, then Set Syntax SPC Tabcode and start typing. However, the questions I have relate more to infrastructural issues, and relate to the tabcode-syntax.lisp and gui.lisp files in that source distribution. Those files are decorated with FIXMEs, but to attempt to summarize the main issues that might be clarified here: * I am aware that there is a separation between syntax and view in current Climacs, such that GUI elements are meant to be distinct from syntactical markup. I don't really see how to implement this with my current model. Please advise :-) * Where are LOW-MARK and HIGH-MARK of a buffer positioned when all that has happened is that the point has moved? Is this well-defined somewhere? * I would like to draw the element near the cursor in a different colour. This doesn't interact trivially with incremental-redisplay, at least as far as I can see; is there a way of selectively invalidating one updating output record so that it is forced to be redrawn? * Presentations are not active / highlighted in the normal command loop. I'm given to understand that this is because until recently mcclim defined a global presentation/command thing which would have made this too painful. It would be good, however, to have the presentations in my graphical window active without having to type M-x (to establish a command input context (?)) * I have some specialized keybindings, which I'm currently putting in the global space; is there a mode-specific keybinding concept in Climacs yet, or is this the only place for them? Notwithstanding all these comments and questions, thank you for providing a lovely editor in such a short time! All comments with respect to the tabcode editor are very welcome, and I hope it provides incentive to get an even better infrastructure. Cheers, Christophe From strandh at labri.fr Wed Jan 26 19:19:29 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 26 Jan 2005 20:19:29 +0100 Subject: [climacs-devel] climacs-based application In-Reply-To: References: Message-ID: <16887.60737.791894.415198@serveur5.labri.fr> Christophe Rhodes writes: > * Where are LOW-MARK and HIGH-MARK of a buffer positioned when all > that has happened is that the point has moved? Is this well-defined > somewhere? LOW-MARK is at the end of the buffer and HIGH-MARK at the beginning. > * I would like to draw the element near the cursor in a different > colour. This doesn't interact trivially with incremental-redisplay, > at least as far as I can see; is there a way of selectively > invalidating one updating output record so that it is forced to be > redrawn? Sure, do what I do, give it a cache-value of (cons nil nil). > * Presentations are not active / highlighted in the normal command > loop. I'm given to understand that this is because until recently > mcclim defined a global presentation/command thing which would have > made this too painful. It would be good, however, to have the > presentations in my graphical window active without having to type > M-x (to establish a command input context (?)) Now that this has been fixed in McCLIM, we can again establish a conntext for commands in Climacs. > * I have some specialized keybindings, which I'm currently putting in > the global space; is there a mode-specific keybinding concept in > Climacs yet, or is this the only place for them? I haven't started thinking about this yet, simply because I am not convinced that the Emacs system of exactly one major mode and a bunch of minor modes is the right one. 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 csr21 at cam.ac.uk Wed Jan 26 23:38:55 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 26 Jan 2005 23:38:55 +0000 Subject: [climacs-devel] climacs-based application In-Reply-To: <16887.60737.791894.415198@serveur5.labri.fr> (Robert Strandh's message of "Wed, 26 Jan 2005 20:19:29 +0100") References: <16887.60737.791894.415198@serveur5.labri.fr> Message-ID: [ I will subscribe soon -- sorry about requiring another moderation ] Robert Strandh writes: > Christophe Rhodes writes: > > * Where are LOW-MARK and HIGH-MARK of a buffer positioned when all > > that has happened is that the point has moved? Is this well-defined > > somewhere? > > LOW-MARK is at the end of the buffer and HIGH-MARK at the beginning. Thanks. (Is this in a document somewhere? I'm afraid I couldn't get the climacs-internals texi to build, probably because I hadn't chased down enough dependencies for fig2whatever) > > * I would like to draw the element near the cursor in a different > > colour. This doesn't interact trivially with incremental-redisplay, > > at least as far as I can see; is there a way of selectively > > invalidating one updating output record so that it is forced to be > > redrawn? > > Sure, do what I do, give it a cache-value of (cons nil nil). ... oh, yes, you can request a different (unobtainable!) cache value. Devious. > > * I have some specialized keybindings, which I'm currently putting in > > the global space; is there a mode-specific keybinding concept in > > Climacs yet, or is this the only place for them? > > I haven't started thinking about this yet, simply because I am not > convinced that the Emacs system of exactly one major mode and a bunch > of minor modes is the right one. (Relatedly...) I knew there was something else I wanted to ask, but I forgot about it. I couldn't see if or how the display of the buffer contents in the textual-view (that is, in normal climacs operation) was to be extended -- for instance for fontifying syntactic markers. It would be nice if I could fontify syntactically incorrect or incomplete tabwords, for instance -- my parser is propagating that information to the syntax, in the form of distinct END and AFTER marks -- but I couldn't see any neat way of hooking into the display code. Am I simply the first to need this? (I seem to recall in the mists of time there being a texinfo mode, but maybe that got zapped somewhere along the line?) Cheers, Christophe From strandh at labri.fr Thu Jan 27 04:48:16 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 27 Jan 2005 05:48:16 +0100 Subject: [climacs-devel] climacs-based application In-Reply-To: References: <16887.60737.791894.415198@serveur5.labri.fr> Message-ID: <16888.29328.586247.531763@serveur5.labri.fr> Christophe Rhodes writes: > [ I will subscribe soon -- sorry about requiring another moderation ] It's OK. I added you to the accept filter. > > LOW-MARK is at the end of the buffer and HIGH-MARK at the beginning. > > Thanks. (Is this in a document somewhere? I'm afraid I couldn't get > the climacs-internals texi to build, probably because I hadn't chased > down enough dependencies for fig2whatever) Sorry about the dependencies. Yes, it is in the buffer modification protocol. > > Sure, do what I do, give it a cache-value of (cons nil nil). > > ... oh, yes, you can request a different (unobtainable!) cache value. > Devious. N'est-ce pas? > (Relatedly...) I knew there was something else I wanted to ask, but I > forgot about it. I couldn't see if or how the display of the buffer > contents in the textual-view (that is, in normal climacs operation) > was to be extended -- for instance for fontifying syntactic markers. > It would be nice if I could fontify syntactically incorrect or > incomplete tabwords, for instance -- my parser is propagating that > information to the syntax, in the form of distinct END and AFTER marks > -- but I couldn't see any neat way of hooking into the display code. > Am I simply the first to need this? (I seem to recall in the mists of > time there being a texinfo mode, but maybe that got zapped somewhere > along the line?) I removed the Texinfo mode, because it was a bit too trivial. The idea is that the display module will query the syntax module to know that there is an incorrect item at a particular place. The display module will then use whatever method it wants to display such errors. -- 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 csr21 at cam.ac.uk Thu Jan 27 12:33:33 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 27 Jan 2005 12:33:33 +0000 Subject: [climacs-devel] climacs-based application In-Reply-To: <16888.29328.586247.531763@serveur5.labri.fr> (Robert Strandh's message of "Thu, 27 Jan 2005 05:48:16 +0100") References: <16887.60737.791894.415198@serveur5.labri.fr> <16888.29328.586247.531763@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > (Relatedly...) I knew there was something else I wanted to ask, but I > > forgot about it. I couldn't see if or how the display of the buffer > > contents in the textual-view (that is, in normal climacs operation) > > was to be extended -- for instance for fontifying syntactic markers. > > It would be nice if I could fontify syntactically incorrect or > > incomplete tabwords, for instance -- my parser is propagating that > > information to the syntax, in the form of distinct END and AFTER marks > > -- but I couldn't see any neat way of hooking into the display code. > > Am I simply the first to need this? (I seem to recall in the mists of > > time there being a texinfo mode, but maybe that got zapped somewhere > > along the line?) > > I removed the Texinfo mode, because it was a bit too trivial. The > idea is that the display module will query the syntax module to know > that there is an incorrect item at a particular place. The display > module will then use whatever method it wants to display such errors. Right. So I guess this is another place where a protocol needs to be developed? The only generic function that looks reasonably specializeable at the moment is DISPLAY-LINE, right? However, that deals with a bunch of functionality that I don't think I should have to care about -- or at least not all in the same place: updating output cache stuff, breaking the string up into words, and the like -- but also seems to make the display very line-oriented. Here's a thought-experiment: what if I wanted a view which was just like the current view, except that in text mode I want to display the paragraph (which is a meaningful unit in the current text syntax) containing point in a different colour. I think currently there would be no way of doing this short of reimplementing the whole display-line thing, and possibly even more, whereas intuitively that ought to be a very small operation... I suppose what I'm asking is whether I'm right in thinking that this isn't currently easy. Cheers, Christophe From strandh at labri.fr Sat Jan 29 07:24:54 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 29 Jan 2005 08:24:54 +0100 Subject: [climacs-devel] adding forward- and backward object to the buffer protocol Message-ID: <16891.14918.998112.50500@serveur5.labri.fr> Hello, I am thinking of adding forward-object and backward-object to the buffer protocol. There are two reasons for this: * They are used much more often by client code than I hade initially imagined. * In a line-oriented buffer implementation, they can be implemented MUCH more efficiently that with the current method of using (incf (offset mark)). In fact the current method may be quite slow in such a buffer implementation. Any objections? -- 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 Sat Jan 29 10:02:59 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 29 Jan 2005 11:02:59 +0100 Subject: [climacs-devel] adding forward- and backward object to the buffer protocol In-Reply-To: <20050129100009.62529.qmail@web40627.mail.yahoo.com> References: <16891.14918.998112.50500@serveur5.labri.fr> <20050129100009.62529.qmail@web40627.mail.yahoo.com> Message-ID: <16891.24403.532188.580340@serveur5.labri.fr> Aleksandar Bakic writes: > > Any objections? > > I suppose the API would stay the same, It depends on what you mean by "the API". If it includes what is in base.lisp, then you are right. If not, the API will indeed change. > you only want to replace (incf (offset > mark)) with something more efficient. I do not see what would be bad about > that, i.e., I do not have objections. Good, thanks. > BTW, I added a comment to base.lisp, in connection with do-buffer-region and > (setf buffer-object). It seems to me that the reasoning is very similar here. > > Dare you use, say, obinseq instead of the 2-3-tree (unless you have already > written it), for the buffer of flexichain-based lines? That's a very good idea. I haven't written it yet, and it made me tired to imagine writing another 2-3-tree implementation anyway. -- 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 Sat Jan 29 10:00:09 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 29 Jan 2005 02:00:09 -0800 (PST) Subject: [climacs-devel] adding forward- and backward object to the buffer protocol In-Reply-To: <16891.14918.998112.50500@serveur5.labri.fr> Message-ID: <20050129100009.62529.qmail@web40627.mail.yahoo.com> > Any objections? I suppose the API would stay the same, you only want to replace (incf (offset mark)) with something more efficient. I do not see what would be bad about that, i.e., I do not have objections. BTW, I added a comment to base.lisp, in connection with do-buffer-region and (setf buffer-object). It seems to me that the reasoning is very similar here. Dare you use, say, obinseq instead of the 2-3-tree (unless you have already written it), for the buffer of flexichain-based lines? Alex __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From a_bakic at yahoo.com Sat Jan 29 10:38:21 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 29 Jan 2005 02:38:21 -0800 (PST) Subject: [climacs-devel] adding forward- and backward object to the buffer protocol In-Reply-To: <16891.24403.532188.580340@serveur5.labri.fr> Message-ID: <20050129103821.60879.qmail@web40621.mail.yahoo.com> > It depends on what you mean by "the API". If it includes what is in > base.lisp, then you are right. If not, the API will indeed change. Yes, I meant the API as in base.lisp. One more thing: perhaps I am missing something, but capitalize-word does not work like in Emacs. In Emacs, I frequently find useful to go to the middle of a word and type M-c in order to capitalize from that point to the end of the word (similar with upcase-word and downcase-word). Is this difference intentional? Alex __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From matthieu.villeneuve at free.fr Sat Jan 29 13:18:21 2005 From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr) Date: Sat, 29 Jan 2005 14:18:21 +0100 Subject: [climacs-devel] adding forward- and backward object to the buffer protocol In-Reply-To: <20050129103821.60879.qmail@web40621.mail.yahoo.com> References: <20050129103821.60879.qmail@web40621.mail.yahoo.com> Message-ID: <1107004701.41fb8d1d57aed@imp6-q.free.fr> Quoting Aleksandar Bakic : > One more thing: perhaps I am missing something, but capitalize-word does > not work like in Emacs. In Emacs, I frequently find useful to go to the > middle of a word and type M-c in order to capitalize from that point to > the end of the word (similar with upcase-word and downcase-word). Is > this difference intentional? No, it is fixed now. Thanks for reporting this. -- Matthieu Villeneuve From wencel at gmail.com Sun Jan 30 17:59:42 2005 From: wencel at gmail.com (Lawrence Mitchell) Date: Sun, 30 Jan 2005 17:59:42 +0000 Subject: [climacs-devel] Re: Regexs in climacs References: <2b1f8a5b05012404241142b98f@mail.gmail.com> Message-ID: Lawrence Mitchell wrote: > after my rather abortive attempts to try and define a > delete-other-windows the other day, I thought I'd look at maybe > supporting some kind of regex search in climacs. Here's a rather trivial buffer-string based idea to demonstrate that things [cw]ould work :). (define-named-command com-re-search-backward () (let ((regex (accept 'string :prompt "RE search backward"))) (re-search-backward regex (buffer (current-window)) (point (current-window))))) (defun re-search-forward (regex buffer offset) (let ((string (coerce (buffer-sequence buffer offset (size buffer)) 'string))) (multiple-value-bind (m-start m-end r-starts r-ends) (cl-pprcre:scan regex string) (when m-start (incf (offset (point buffer)) m-end))))) (defun re-search-backward (regex buffer mark) (let ((string (coerce (buffer-sequence buffer 0 (offset mark)) 'string))) (multiple-value-bind (m-start m-end r-starts r-ends) (cl-ppcre:scan regex string) (when m-start (decf (offset mark) (- (offset mark) m-start)))))) (define-named-command com-re-search-forward () (let ((regex (accept 'string :prompt "RE Search"))) (re-search-forward regex (buffer (current-window)) (point (current-window))))) [...] > Alternately, find a nice way of hooking the cl-ppcre way of doing > things into climacs' mode of operation. Well, I've emailed Edi about this, and I enclose what he had to say about the matter, both regarding Robert's worries of incompatible licenses, and implementation-wise. Basically, it would appear that we'd need to change cl-ppcre slightly for our needs (make string accesses via SCHAR into buffer accesses), other than that, probably not a big problem. Obviously, Edi is worried about something like this slowing cl-ppcre down, however, from our point of view, I think it would still be fast enough, as long as we can provide decently fast random access into a buffer. I think this would be done using BUFFER-OBJECT. Ideally, of course, we'd want to merge this back into cl-ppcre, so that we can take advantage of any changes that Edi makes --- his *feature* conditionalising sounds like a reasonable way of doing that. Any comments? If this seems like a good idea, I'll look at putting together something next weekend. Lawrence Edi's response to my mail follows: | Hi! | Lawrence Mitchell wrote: |> I'm looking at trying to use cl-ppcre to add regular expression |> support to the Climacs editor ( http://common-lisp.net/project/climacs/>). | Sounds cool... ) |> A few things spring to mind: |> |> o Licensing differences. Climacs is released under the LGPL, while |> cl-ppcre is under as BSD-style license. I don't think this is a |> problem (as far as I can tell from reading the licenses), but if you |> know otherwise, I'd be grateful to hear. | I don't see a problem but IANAL. It is my understanding that the BSD | license basically means that you can do with CL-PPCRE whatever you | want as long as you credit my original work - this is what I intended. | So you could, e.g., incorporate it into a LPGL project without a | problem. Of course, the original CL-PPCRE will still be available | under the old license. |> o How to best match up cl-ppcre's matching on strings with climacs' |> idea of a buffer. |> |> A climacs buffer is a sequence of objects (which may or may not be |> characters, but we'll ignore that for the moment). Now, I can |> easily generate a string of the contents of the buffer, and call |> SCAN (or whatever) on the string. However, this is going to be slow |> for large buffers (especially if we find something just after point, |> we've still constructed the whole buffer-string). |> |> The "obvious" solution to this is to use streams instead (probably), |> so, I wonder if cl-ppcre would be amenable to something like this? | Well, supporting all of Perl's regex facilities implies that you need | to have random access to the target - I don't think you can fit | streams into this picture. I'm not a CS guy but my understanding is | that CL-PPCRE is based on an NFA and you can't change that easily. | You can build a DFA that implements a subset of CL-PPCRE and that | would work with streams but that wouldn't be CL-PPCRE anymore... :) | Now, using another kind of structures (like, say, your buffers) that | aren't strings but are random-access - that wouldn't be /too/ hard. | It would involve going through three or four files and change SCHAR to | something else but basically I don't really see a problem. However, | as CL-PPCRE has a reputation for being quite fast I wouldn't want to | sacrifice this for greater flexibility (buffers instead of strings, | arbitrary objects instead of characters - you name it). I think the | right way to do it would be to offer the ability to build different | versions of CL-PPCRE based on *FEATURES*, i.e. at compile time you | decide whether you want a fast regex engine for strings or if you want | a not-so-fast regex engine for, say, buffers. Would that be OK for | you? [...] | Cheers, | Edi.