From a_bakic at yahoo.com Sat Dec 25 09:41:22 2004 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 25 Dec 2004 01:41:22 -0800 (PST) Subject: [climacs-devel] CLIM backend Message-ID: <20041225094122.87734.qmail@web40625.mail.yahoo.com> Hi, I commited a couple of minor changes to get Climacs work for me. One of them is the addition of a dependency on the clim-clx backend. Please feel free to remove/condition it if it breaks your setup, as I am not very familiar with CLIM and how other people use it. Alex __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com From strandh at labri.fr Sat Dec 25 15:14:23 2004 From: strandh at labri.fr (Robert Strandh) Date: Sat, 25 Dec 2004 16:14:23 +0100 Subject: [climacs-devel] CLIM backend In-Reply-To: <20041225094122.87734.qmail@web40625.mail.yahoo.com> References: <20041225094122.87734.qmail@web40625.mail.yahoo.com> Message-ID: <16845.33743.737183.840966@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > I commited a couple of minor changes to get Climacs work for me. One of them is > the addition of a dependency on the clim-clx backend. Please feel free to > remove/condition it if it breaks your setup, as I am not very familiar with > CLIM and how other people use it. Nothing is broken here, so thanks. As it turned out, we have made the same factoring of the c-x command table, so that generated a conflict, which took me two iterations to solve properly (our functions were identical). Please let me know what you think so far. -- 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 ejohnson at fasl.info Sun Dec 26 13:06:03 2004 From: ejohnson at fasl.info (Elliott Johnson) Date: Sun, 26 Dec 2004 05:06:03 -0800 Subject: [climacs-devel] A little on rings Message-ID: <20041226130603.GA29690@mail.fasl.info> Hi, Hope everyone's holidays have been going well. :) I've hardly had time but I've worked up a ring.lisp file. It's fairly simple. Classes for generic ring & kill-ring, plus generic functions for ring-push, ring-pop, rotate-ring, initialize-kill-ring, and kill-in-region. The kill-ring structure is nothing outstanding right now either, simply a slot-value for an array, a max size fixnum, and a offset fixnum. The kill-ring being a vector can handle any valid lisp structure, so weird cuts and inserts are no problem. If anyone else has cool ideas or better implementations for rings, please speak up. Things I still need to do: create a few helper functions (inspired by hemlock) and create the CLIM commands, keybindings, etc, so I'll have it down before leaving for LA. Cl.net guys havn't replied to my account email yet, so hopefully that comes togeather as well. If not I'll email it before I go :) Later, -Elliott -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Sun Dec 26 14:02:03 2004 From: strandh at labri.fr (Robert Strandh) Date: Sun, 26 Dec 2004 15:02:03 +0100 Subject: [climacs-devel] A little on rings In-Reply-To: <20041226130603.GA29690@mail.fasl.info> References: <20041226130603.GA29690@mail.fasl.info> Message-ID: <16846.50267.829018.445946@serveur5.labri.fr> Hello Elliott, Elliott Johnson writes: > > Hope everyone's holidays have been going well. :) Sure, lots of hacking. > I've hardly had time but I've worked up a ring.lisp file. It's > fairly simple. Classes for generic ring & kill-ring, plus generic > functions for ring-push, ring-pop, rotate-ring, initialize-kill-ring, > and kill-in-region. Sounds good. > The kill-ring structure is nothing outstanding right now either, > simply a slot-value for an array, a max size fixnum, and a offset > fixnum. The kill-ring being a vector can handle any valid lisp > structure, so weird cuts and inserts are no problem. > > If anyone else has cool ideas or better implementations for rings, > please speak up. Yes, in fact, if you are going to rotate it and/or do arbitrary inserts and deletes, a flexichain is particularly useful. And if you want an offset into the kill ring, you might do that with a flexicursor into a cursorchain. All of this is in the flexichain library already used for the buffer data structure, so no extra libraries necessary. > Things I still need to do: create a few helper functions (inspired > by hemlock) and create the CLIM commands, keybindings, etc, so I'll > have it down before leaving for LA. Cl.net guys havn't replied to > my account email yet, so hopefully that comes togeather as well. > If not I'll email it before I go :) No rush. I'd say wait for the account. Have a nice trip. -- 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 Dec 26 23:42:05 2004 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 26 Dec 2004 15:42:05 -0800 (PST) Subject: [climacs-devel] CLIM backend In-Reply-To: <16845.33743.737183.840966@serveur5.labri.fr> Message-ID: <20041226234206.48946.qmail@web40624.mail.yahoo.com> > Please let me know what you think so far. Very nice, this seems to be an even better playground for my persistent-stuff ideas than phemlock. Other than that, the incremental parsing sounds interesting, so I will spend some time investigating that soon. (I have implemented binary random access lists using Okasaki's book. I need to add more code and see how it fits with the buffer and undo protocols and how fast it is.) Alex __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From nyef at sc.am Mon Dec 27 02:09:57 2004 From: nyef at sc.am (nyef at sc.am) Date: Sun, 26 Dec 2004 21:09:57 -0500 Subject: [climacs-devel] C-x C-c Message-ID: <20041227020957.GA2404@sc.am> Hello all. Just spent a little time poking at McCLIM since the C-x C-q to quit thing was bothering me, and I came up with somewhat of a solution. A patch is attached. --Alastair Bridgewater -------------- next part -------------- Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.13 diff -u -r1.13 gui.lisp --- gui.lisp 24 Dec 2004 23:17:48 -0000 1.13 +++ gui.lisp 27 Dec 2004 01:58:55 -0000 @@ -86,7 +86,8 @@ (setf (slot-value frame 'win) (find-pane-named frame 'win)) (let ((*standard-output* (frame-standard-output frame)) (*standard-input* (frame-standard-input frame)) - (*print-pretty* nil)) + (*print-pretty* nil) + (*abort-gestures* nil)) (redisplay-frame-panes frame :force-p t) (loop with gestures = '() do (setf *current-gesture* (read-gesture :stream *standard-input*)) @@ -305,6 +306,6 @@ (add-command-to-command-table command 'c-x-climacs-table :keystroke gesture :errorp nil)) -(c-x-set-key '(#\q :control) 'com-quit) +(c-x-set-key '(#\c :control) 'com-quit) (c-x-set-key '(#\f :control) 'com-find-file) (c-x-set-key '(#\s :control) 'com-save-buffer) From strandh at labri.fr Mon Dec 27 04:27:08 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 27 Dec 2004 05:27:08 +0100 Subject: [climacs-devel] CLIM backend In-Reply-To: <20041226234206.48946.qmail@web40624.mail.yahoo.com> References: <16845.33743.737183.840966@serveur5.labri.fr> <20041226234206.48946.qmail@web40624.mail.yahoo.com> Message-ID: <16847.36636.986750.653770@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > Please let me know what you think so far. > > Very nice, this seems to be an even better playground for my persistent-stuff > ideas than phemlock. Other than that, the incremental parsing sounds > interesting, so I will spend some time investigating that soon. Thanks. That would be great. > (I have implemented binary random access lists using Okasaki's book. I need to > add more code and see how it fits with the buffer and undo protocols and how > fast it is.) I don't know about those, but I am willing to learn. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Dec 27 04:28:38 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 27 Dec 2004 05:28:38 +0100 Subject: [climacs-devel] C-x C-c In-Reply-To: <20041227020957.GA2404@sc.am> References: <20041227020957.GA2404@sc.am> Message-ID: <16847.36726.441129.710446@serveur5.labri.fr> Thanks, I'll put that in. Nice. nyef at sc.am writes: > Hello all. > > Just spent a little time poking at McCLIM since the C-x C-q to quit > thing was bothering me, and I came up with somewhat of a solution. A > patch is attached. > > --Alastair Bridgewater > Index: gui.lisp > =================================================================== > RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v > retrieving revision 1.13 > diff -u -r1.13 gui.lisp > --- gui.lisp 24 Dec 2004 23:17:48 -0000 1.13 > +++ gui.lisp 27 Dec 2004 01:58:55 -0000 > @@ -86,7 +86,8 @@ > (setf (slot-value frame 'win) (find-pane-named frame 'win)) > (let ((*standard-output* (frame-standard-output frame)) > (*standard-input* (frame-standard-input frame)) > - (*print-pretty* nil)) > + (*print-pretty* nil) > + (*abort-gestures* nil)) > (redisplay-frame-panes frame :force-p t) > (loop with gestures = '() > do (setf *current-gesture* (read-gesture :stream *standard-input*)) > @@ -305,6 +306,6 @@ > (add-command-to-command-table command 'c-x-climacs-table > :keystroke gesture :errorp nil)) > > -(c-x-set-key '(#\q :control) 'com-quit) > +(c-x-set-key '(#\c :control) 'com-quit) > (c-x-set-key '(#\f :control) 'com-find-file) > (c-x-set-key '(#\s :control) 'com-save-buffer) > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel -- 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 nyef at sc.am Mon Dec 27 05:50:25 2004 From: nyef at sc.am (Nyef) Date: Mon, 27 Dec 2004 00:50:25 -0500 Subject: [climacs-devel] C-x C-c In-Reply-To: <16847.36726.441129.710446@serveur5.labri.fr> References: <20041227020957.GA2404@sc.am> <16847.36726.441129.710446@serveur5.labri.fr> Message-ID: <20041227055025.GA20397@sc.am> And some more, which you helped with. Thank you. This set is most of the fun bits along the right side of my keyboard. Arrow keys, home, end, pgup, pgdn, del, backspace. On Mon, Dec 27, 2004 at 05:28:38AM +0100, Robert Strandh wrote: > Thanks, I'll put that in. Nice. > > nyef at sc.am writes: > > Hello all. > > > > Just spent a little time poking at McCLIM since the C-x C-q to quit > > thing was bothering me, and I came up with somewhat of a solution. A > > patch is attached. > > > > --Alastair Bridgewater > > -- > 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. > --------------------------------------------------------------------- -- --Alastair Bridgewater -------------- next part -------------- Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.18 diff -u -r1.18 gui.lisp --- gui.lisp 27 Dec 2004 04:32:43 -0000 1.18 +++ gui.lisp 27 Dec 2004 05:46:27 -0000 @@ -93,7 +93,15 @@ do (setf *current-gesture* (read-gesture :stream *standard-input*)) (when (or (characterp *current-gesture*) (and (typep *current-gesture* 'keyboard-event) - (keyboard-event-character *current-gesture*))) + (or (keyboard-event-character *current-gesture*) + (not (member (keyboard-event-key-name + *current-gesture*) + '(:control-left :control-right + :shift-left :shift-right + :meta-left :meta-right + :super-left :super-right + :hyper-left :hyper-right + :shift-lock :caps-lock)))))) (setf gestures (nconc gestures (list *current-gesture*))) (let ((item (find-gestures gestures 'global-climacs-table))) (cond ((not item) @@ -131,6 +139,9 @@ (define-command com-delete-object () (delete-range (point (win *application-frame*)))) +(define-command com-backward-delete-object () + (delete-range (point (win *application-frame*)) -1)) + (define-command com-previous-line () (previous-line (point (win *application-frame*)))) @@ -302,6 +313,19 @@ (global-set-key '(#\< :shift :meta) 'com-beginning-of-buffer) (global-set-key '(#\> :shift :meta) 'com-end-of-buffer) (global-set-key '(#\u :meta) 'com-browse-url) + +(global-set-key '(:up) 'com-previous-line) +(global-set-key '(:down) 'com-next-line) +(global-set-key '(:left) 'com-backward-object) +(global-set-key '(:right) 'com-forward-object) +(global-set-key '(:left :control) 'com-backward-word) +(global-set-key '(:right :control) 'com-forward-word) +(global-set-key '(:home) 'com-beginning-of-line) +(global-set-key '(:end) 'com-end-of-line) +(global-set-key '(:home :control) 'com-beginning-of-buffer) +(global-set-key '(:end :control) 'com-end-of-buffer) +(global-set-key #\Rubout 'com-delete-object) +(global-set-key #\Backspace 'com-backward-delete-object) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; From nyef at sc.am Mon Dec 27 16:20:56 2004 From: nyef at sc.am (Nyef) Date: Mon, 27 Dec 2004 11:20:56 -0500 Subject: [climacs-devel] Incremental redisplay Message-ID: <20041227162056.GA19019@sc.am> Hello all. Just spent some time poking around with incremental redisplay. I think I have it somewhat working now. The only problem I see currently is that the cursor keeps disappearing. I don't quite know what's up with that. Anyway, patch attached. I wouldn't recommend checking it in to CVS as is, but if something could be figured out about the cursor... Perhaps wrapping the DRAW-LINE* call in a maybe-updating-output? -- --Alastair Bridgewater -------------- next part -------------- Index: gui.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/gui.lisp,v retrieving revision 1.20 diff -u -r1.20 gui.lisp --- gui.lisp 27 Dec 2004 11:32:46 -0000 1.20 +++ gui.lisp 27 Dec 2004 16:09:00 -0000 @@ -48,7 +48,7 @@ (win (make-pane 'climacs-pane :width 900 :height 400 :name 'win -;;; :incremental-redisplay t + :incremental-redisplay t :display-function 'display-win)) (int :interactor :width 900 :height 50 :max-height 50)) (:layouts Index: syntax.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/syntax.lisp,v retrieving revision 1.8 diff -u -r1.8 syntax.lisp --- syntax.lisp 27 Dec 2004 11:32:46 -0000 1.8 +++ syntax.lisp 27 Dec 2004 16:09:00 -0000 @@ -66,11 +66,11 @@ 'string) :stream pane))) -(defmacro maybe-updating-output (stuff &body body) - `(progn , at body)) +;;(defmacro maybe-updating-output (stuff &body body) +;; `(progn , at body)) -;; (defmacro maybe-updating-output (stuff &body body) -;; `(updating-output ,stuff , at body)) + (defmacro maybe-updating-output (stuff &body body) + `(updating-output ,stuff , at body)) (defmethod display-line (pane (syntax basic-syntax)) (with-slots (saved-offset bot scan cursor-x cursor-y space-width tab-width) syntax @@ -81,12 +81,18 @@ (macrolet ((output-word (&body body) `(let ((contents (compute-contents))) (if (null contents) - (progn , at body) + ,(if body + `(maybe-updating-output (pane :unique-id (incf id)) + , at body) + `(progn)) + (progn (maybe-updating-output (pane :unique-id (incf id) :cache-value contents :cache-test #'string=) - (present-contents contents pane syntax) - , at body))))) + (present-contents contents pane syntax)) + ,(when body + `(maybe-updating-output (pane :unique-id (incf id)) + , at body))))))) (loop with id = 0 when (mark= scan (point pane)) do (multiple-value-bind (x y) (stream-cursor-position pane) From nyef at sc.am Mon Dec 27 17:39:41 2004 From: nyef at sc.am (Nyef) Date: Mon, 27 Dec 2004 12:39:41 -0500 Subject: [climacs-devel] Incremental redisplay cursor fix. Message-ID: <20041227173941.GA16407@sc.am> Hello all. Attached is a patch to fix the cursor display problem with incremental redisplay. This appears to work, except for the beginning of lines other than the second one. -- --Alastair Bridgewater -------------- next part -------------- Index: syntax.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/syntax.lisp,v retrieving revision 1.9 diff -u -r1.9 syntax.lisp --- syntax.lisp 27 Dec 2004 16:47:45 -0000 1.9 +++ syntax.lisp 27 Dec 2004 17:37:39 -0000 @@ -163,10 +163,13 @@ (multiple-value-bind (x y) (stream-cursor-position pane) (setf cursor-x x cursor-y y))) - (draw-line* pane - cursor-x (- cursor-y (* 0.2 height)) - cursor-x (+ cursor-y (* 0.8 height)) - :ink +red+)))))) + (maybe-updating-output (pane :all-new t :fixed-position t) + (draw-line* pane + ;; cursors with odd x-positions were invisible + ;; so we strip off the low bit to make them even. + (logand -2 cursor-x) (- cursor-y (* 0.2 height)) + (logand -2 cursor-x) (+ cursor-y (* 0.8 height)) + :ink +red+))))))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; From strandh at labri.fr Tue Dec 28 05:11:42 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 06:11:42 +0100 Subject: [climacs-devel] Climacs development Message-ID: <16848.60174.369755.48024@serveur5.labri.fr> Dear members of the climacs-devel mailing list, I am overwhelmed by the positive response on the part of the community with respect to this project. A few days after its creation, this mailing list now has more than a dozen members. While I understand that the majority is only interested in following what the developers are doing, I would still like to give you all an overview of who is working on what, and what still needs to be done. First, in case you have not seen it, the main reason for the creation of this project was to serve as a CVS site for three student projects that I have suggested, and that will be conducted starting end of January and finishing around the end of April, I would guess. You might start to get commits from them sometime in March at the earliest, I think, but there will no doubt be messages to this mailing list. It is then OK to answer questions, of course. The student projects cover the following areas, which I must then, unfortunately discourage everyone from working on before the month of May. * The "real" buffer implementation, using a 2-3-tree of lines, each line being a Flexichain. * Undo. * Common Lisp syntax. It is OK to suggest improvements to code committed by the students The second purpose for the creation of this project was to obtain something that could serve as a common base for Goatee and Portable Hemlock. I would like to see those two projects merged, if possible, and I would like for them to have a sound basis, in the form of decent protocols for fundamental things such as the buffer, undo, syntax highlighting, and more. By "sound", I mean ones that can be implemented efficiently in a variety of ways, and that can be used effectively by higher-level code. I am a little ambivalent about Climacs turning in to a fully-featured Common Lisp Emacs, because that would mean that, instead of merging Goatee and Portable Hemlock, we write a third one. On the other hand, it might turn out too difficult to replace the low-level protocols of Portable Hemlock by something else, as they tend to permeate the rest of the code (which is reasonable of course). For that reason, I am merely going to continue developing Climacs for now, and I am going to encourage others to pitch in. When we reach a level that is sufficient for some functionality from Portable Hemlock to be "grafted on top of the base" (to use Gilbert's words) it might be preferable to do that instead of rewriting it. One has to be careful with licensing when this is done. Importing compatible code (public domain, or LGPL) is OK, of course. Notice that Climacs is LGPL in order to fit into McCLIM, and to encourage developers to contribute their changes, while still allowing for very liberal use by commercial products. Aside from the three student projects above, here is a list of what I know to be worked on by someone on this list: * Kill ring implementation (Elliott Johnson). * Using CLIM incremental redisplay (Alastair Bridgewater). There is still a problem with the cursor disappearing, so if anyone wants to pitch in, that would be OK. * Performance improvements to file I/O (Me). It turns out, the problem is that adding objects one by one is too slow. We will need and upward-compatible addition to Flexichain (insert-sequence*). * Adding commands to the Climacs command table so that they will be available through M-x (Alastair Bridgewater). * Toggle character and words commands (Matthieu Villeneuve). Aside from those medium to large tasks, I am unaware of any other activity. If you plan to work on some other aspects, please submit your proposal here to avoid too many clashes. If you would like to work on something, there are tons of little and not-so-little things that need to be done. Here is a (partial) list: * Emacs has many, many commands at this point. Adding the most important ones is a laborious, but nevertheless important task. Most such commands are fairly simple. * We need to figure out what McCLIM wants in order to invoke redisplay when the size of the pane changes. * We need to get McCLIM scroll bars for the buffer working. * I would like to add a buffer syntax for text that recognizes not only words, but also sentences, paragraphs and perhaps pages. Contact me if you are interested in this. It's a big task which involves writing an incremental parser for the syntax of such a document. Granted, it will be much simpler than the CL syntax. It might be best to write a specification first. * Buffer syntax for other languages, in particular C, C++, and Java, would be very interesting tasks for those who use those languages. I am personally not going to work on this. * User feedback and error handling must be improved. Ringing the bell is not enough to inform the user what went wrong. also, the user needs to know which, if any, file is in the buffer. * I can't seem to figure out how to capture the parse-error from the filename completion code. Right now, it is therefore not possible to load a non-existing file. This should be fixed, of course, and involves understanding conditions and McCLIM completion. * We need a spell-checker protocol. A spell checker should not just return a boolean indicating whether a word exists in a dictionary, but also a value indicating that a sequence of characters is a valid prefix for some such word. This might involve writing a word completer for McCLIM, and augmenting the completer with :near-misses or something like that, in order to suggest the right word. Finally, to prepare for grammar checking, the spell checker should not just return a boolean, but a list of possible grammar categories. Like in English, submitting "flies" should return (at least) two entries: 1. noun, plural and 2. verb, second-person singular. * It would be great if someone would maintain this to-do list in some document in the hierarchy, for instance in a file called TODO. In fact, I am not very experienced with bug-tracking and the like, so that needs to be given some thought. * Documentation. While I am writing the text of the internals document, it still needs Texinfo structuring commands in it. It also needs better indexing, cross-referencing, word markup, etc. At some point, we need a user manual, which should also be in Texinfo. Documentation is boring to most people, but on the off-chance that someone likes to write it the way I do, please go ahead. Well, that's just what I can think of right now. Please do not hesitate adding to this list as you see fit. Oh, and if you plan to contribute, please get a common-lisp.net account so that you can commit directly to CVS. I will most likely not have time to review patches anyway, so you might as well commit, and have other review your commits after the fact. This message is already much longer than I intended, so I'll stop here. -- 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 amoroso at mclink.it Tue Dec 28 16:04:44 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 17:04:44 +0100 Subject: [climacs-devel] Climacs development References: <16848.60174.369755.48024@serveur5.labri.fr> Message-ID: <87llbixvc3.fsf@plato.moon.paoloamoroso.it> Robert Strandh writes: > I am a little ambivalent about Climacs turning in to a fully-featured > Common Lisp Emacs, because that would mean that, instead of merging > Goatee and Portable Hemlock, we write a third one. On the other hand, I think that having a decent Common Lisp text editor--be it Climacs, Portable Hemlock, a merge, or something different--would be useful. There are *now* enough end-user Common Lisp applications, that having some of them available in the same Lisp image would bring part of the integration power of Lisp Machine environments to our *current* systems--with the added benefit of using Common Lisp as a scripting language for free. For example, the Mel email program could call Climacs/Portable Hemlock/whatever to edit messages, in a way similar to Unix applications calling the user's preferred editor via $EDITOR. This could be done by providing protocols for accessing basic editing functionality such as loading a file in a buffer, placing the cursor at a specified location, getting back the edited text as a string, etc. Such a protocol would not need to be huge and expose all the functionality, just a minimal set of widely available features that may make it possible to use different editors in a more or less uniform way. This thin abstraction layer needs not be tied to Climacs or Portable Hemlock, it could well be a different project. > Well, that's just what I can think of right now. Please do not > hesitate adding to this list as you see fit. Oh, and if you plan to All the standard disclaimers apply: this is just brainstorming, I'm not working on this, it's not even vaporware, etc. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From strandh at labri.fr Tue Dec 28 16:27:16 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 17:27:16 +0100 Subject: [climacs-devel] Climacs development In-Reply-To: <87llbixvc3.fsf@plato.moon.paoloamoroso.it> References: <16848.60174.369755.48024@serveur5.labri.fr> <87llbixvc3.fsf@plato.moon.paoloamoroso.it> Message-ID: <16849.35172.647994.301952@serveur5.labri.fr> Paolo Amoroso writes: > Robert Strandh writes: > > > I am a little ambivalent about Climacs turning in to a fully-featured > > Common Lisp Emacs, because that would mean that, instead of merging > > Goatee and Portable Hemlock, we write a third one. On the other hand, > > I think that having a decent Common Lisp text editor--be it Climacs, > Portable Hemlock, a merge, or something different--would be useful. I absolutely agree. > There are *now* enough end-user Common Lisp applications, that having > some of them available in the same Lisp image would bring part of the > integration power of Lisp Machine environments to our *current* > systems--with the added benefit of using Common Lisp as a scripting > language for free. Yes. That's definitely what we want. > For example, the Mel email program could call Climacs/Portable > Hemlock/whatever to edit messages, in a way similar to Unix > applications calling the user's preferred editor via $EDITOR. Exactly. I have come to the conclusion that the main missing piece in this puzzle is the editor. Without the editor, nothing else will work. And we do have most of the rest: debugger pane, web/documentation browser, mail program, etc. > This could be done by providing protocols for accessing basic editing > functionality such as loading a file in a buffer, placing the cursor > at a specified location, getting back the edited text as a string, > etc. > > Such a protocol would not need to be huge and expose all the > functionality, just a minimal set of widely available features that > may make it possible to use different editors in a more or less > uniform way. Now, that's a good idea. We need to work on establishing such a protocol. > This thin abstraction layer needs not be tied to Climacs or Portable > Hemlock, it could well be a different project. Yes, definitely. > All the standard disclaimers apply: this is just brainstorming, I'm > not working on this, it's not even vaporware, etc. Sure, I understand. -- 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 amoroso at mclink.it Tue Dec 28 16:44:56 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 17:44:56 +0100 Subject: [climacs-devel] Climacs development In-Reply-To: <16848.60174.369755.48024@serveur5.labri.fr> (Robert Strandh's message of "Tue, 28 Dec 2004 06:11:42 +0100") References: <16848.60174.369755.48024@serveur5.labri.fr> Message-ID: <87sm5q8j93.fsf@plato.moon.paoloamoroso.it> Robert Strandh writes: > * It would be great if someone would maintain this to-do list in > some document in the hierarchy, for instance in a file called > TODO. In fact, I am not very experienced with bug-tracking and > the like, so that needs to be given some thought. An informal to-do list might be maintained as a CLiki or McCLIM CLiki page. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From strandh at labri.fr Tue Dec 28 17:04:38 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 18:04:38 +0100 Subject: [climacs-devel] Climacs development In-Reply-To: <87sm5q8j93.fsf@plato.moon.paoloamoroso.it> References: <16848.60174.369755.48024@serveur5.labri.fr> <87sm5q8j93.fsf@plato.moon.paoloamoroso.it> Message-ID: <16849.37414.287614.433820@serveur5.labri.fr> Paolo Amoroso writes: > Robert Strandh writes: > > > * It would be great if someone would maintain this to-do list in > > some document in the hierarchy, for instance in a file called > > TODO. In fact, I am not very experienced with bug-tracking and > > the like, so that needs to be given some thought. > > An informal to-do list might be maintained as a CLiki or McCLIM CLiki > page. Yes, but not quite yet. It would be too long and it would need to be updated every hour. -- 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 Tue Dec 28 18:02:19 2004 From: wencel at gmail.com (Lawrence Mitchell) Date: Tue, 28 Dec 2004 18:02:19 +0000 Subject: [climacs-devel] Minor change for com-save-buffer Message-ID: <2b1f8a5b04122810021c12cf88@mail.gmail.com> Hi there, this change only makes a save-buffer call actually save a buffer if it is needed, otherwise, nothing is done and a message is echoed to the screen indicating that no changes needed to be saved. I'm not sure if the DISPLAY-MESSAGE function is correct, I'm not particularly au fait with CLIM and have no lisp available at the moment to actually check if this works. The /idea/ is that one should echo a message to Climacs' equivalent of the minibuffer, which I think is the 'int pane in the *APPLICATION-FRAME*. Comments? -- Lawrence Mitchell -------------- next part -------------- A non-text attachment was scrubbed... Name: gui.lisp.patch Type: application/octet-stream Size: 1428 bytes Desc: not available URL: From strandh at labri.fr Wed Dec 29 15:03:56 2004 From: strandh at labri.fr (Robert Strandh) Date: Wed, 29 Dec 2004 16:03:56 +0100 Subject: [climacs-devel] latest progress Message-ID: <16850.51036.665083.618967@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. Progress is pretty fast. The following is a list of recent improvements: * improved reading and writing of files (save only if buffer is modified, etc) * status line with buffer name and buffer modification flag. * the cursor is visible again, though there is still some work to do on the redisplay algorithm * the buffer-modification protocol was modified because the current protocol could not handle empty buffers. The changes were implemented. * we have an initial kill-ring implementation with commands to go with it. * extended commands with M-x now work, so many new commands can be implemented. * probably some things I have forgotten. In the near future: * commands to toggle characters and words. * a much faster redisplay algorithm. The fraction-of-a-second typing delay is due to the relative slowness of the redisplay algorithm. I now know how to make it much faster, which should give a significant speed-up. * more commands, as people find out which ones of their favorite Emacs commands are missing. Sincerely, -- 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. ---------------------------------------------------------------------