From strandh at labri.fr Thu Feb 3 05:42:19 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Feb 2005 06:42:19 +0100 Subject: [climacs-devel] Re: Regexs in climacs In-Reply-To: References: <2b1f8a5b05012404241142b98f@mail.gmail.com> Message-ID: <16897.47547.559134.456968@serveur5.labri.fr> Hello, Lawrence Mitchell writes: > 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))))) > > [...] Yes, I see. Nice, but probably not ready for prime time since the entire buffer is converted to a string. > |> 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. OK, It's OK with me to stick it in. Technically, there is a problem though, the LGPL says that any addition to the software must be LGPL, and cl-ppcre would be an addition, but it is not LGPL. I guess as the author, I can grant a special exception for cl-ppcre. > |> 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. I agree, replacing schar with calls to (buffer-object buffer offset) would probably be all that is required. > | 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? Probably the easiest way to accomplish this is to include a modified version of cl-ppcre in the Climacs distribution which is adapted to the buffer access method. -- 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 Feb 3 06:05:34 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 3 Feb 2005 07:05:34 +0100 Subject: [climacs-devel] more progress Message-ID: <16897.48942.215186.816594@serveur5.labri.fr> Dear mailing list members, We continue making amazing progress on Climacs, but we are definitely reaching the point where we are running out of small Emacs-like functionality that is easy to put in. I predict that future progress will be in the form of bigger chunks but perhaps not as frequent as up until now. Aleksandar Bakic committed his alternative buffer implementation this week. Since the buffer protocol is pretty well defined, I think several implementations could (and should) co-exist, and eventually the choice of implementation could be made dynamically based on the contents of what is to be edited. As you may have seen, Lawrence Mitchell is thinking of using CL-PPCRE as a regex library for Climacs. This will definitely give Climacs functionality a boost. Christphe Rhodes is making progress on his tabcode editor based on Climacs. This is an application with an incremental parser and two panes, one for editing tabcode notation as text, and the other one that displays a more user-friendly view of what is being edited. I have spent most of the week implementing a generalization of the Earley parsing algorithm for Climacs. This algorithm is naturally incremental and can handle ambiguous grammars, which is going to be necessary for error recovery. I am hoping this will be the basis of new syntax implementations, perhaps even of the Common Lisp syntax that my students are going to work on. This week's progress itemized: * alternative buffer implementation based on persistent data structures, and tests for this implementation. (thanks to Aleksandar Bakic) * query-replace (thanks to Matthieu Villeneuve) * code factoring of command loops (thanks to Matthieu Villeneuve) * The function downcase-region, upcase-region capitalize-region are now symmetric with respect to the order of the marks (thanks to Aleksandar Backic) * started adding optional count arguments to various functions and numeric arguments to the corresponding Climacs commands. * implemented an Earley syntax and an embryonic parser for HTML. * modified documentation to reflect a more complete syntax protocol. 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 a_bakic at yahoo.com Sat Feb 5 14:26:37 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 5 Feb 2005 06:26:37 -0800 (PST) Subject: [climacs-devel] forward/backward-object Message-ID: <20050205142637.80007.qmail@web40605.mail.yahoo.com> Hi, Just in case, I'd emphasize that these two generics, whose methods won't be specialized on buffers, should have methods that invoke methods from the buffer protocol if they work on buffers, even if it adds some overhead. Otherwise, they would end up like end-of-line, which only works with one buffer class at the moment. Alex __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From strandh at labri.fr Sat Feb 5 14:38:20 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 5 Feb 2005 15:38:20 +0100 Subject: [climacs-devel] forward/backward-object In-Reply-To: <20050205142637.80007.qmail@web40605.mail.yahoo.com> References: <20050205142637.80007.qmail@web40605.mail.yahoo.com> Message-ID: <16900.55900.19548.208872@serveur5.labri.fr> Aleksandar Bakic writes: > > Just in case, I'd emphasize that these two generics, whose methods won't be > specialized on buffers, should have methods that invoke methods from the buffer > protocol if they work on buffers, even if it adds some overhead. Otherwise, > they would end up like end-of-line, which only works with one buffer class at > the moment. Actually, the should probably have methods that specialize on buffer-specific marks. I'll look into 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 strandh at labri.fr Sat Feb 5 14:44:15 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 5 Feb 2005 15:44:15 +0100 Subject: [climacs-devel] forward/backward-object In-Reply-To: <20050205142637.80007.qmail@web40605.mail.yahoo.com> References: <20050205142637.80007.qmail@web40605.mail.yahoo.com> Message-ID: <16900.56255.539275.585443@serveur5.labri.fr> Aleksandar Bakic writes: > Hi, > > Just in case, I'd emphasize that these two generics, whose methods won't be > specialized on buffers, should have methods that invoke methods from the buffer > protocol if they work on buffers, even if it adds some overhead. Otherwise, > they would end up like end-of-line, which only works with one buffer class at > the moment. Correct. I changed forward-object and backward-object to specialize on mark-mixin which is an internal symbol in the buffer package, so is specific to the particular implementation. The end-of-line method is also specialized on mark-mixin which should be OK, 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 a_bakic at yahoo.com Sat Feb 5 15:28:35 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 5 Feb 2005 07:28:35 -0800 (PST) Subject: [climacs-devel] forward/backward-object In-Reply-To: <16900.56255.539275.585443@serveur5.labri.fr> Message-ID: <20050205152835.36871.qmail@web40628.mail.yahoo.com> > I changed forward-object and backward-object to specialize on > mark-mixin which is an internal symbol in the buffer package, so is > specific to the particular implementation. > > The end-of-line method is also specialized on mark-mixin which should > be OK, right? Aha(tm), I did not notice this detail (that mark-mixin is a per-buffer-class thing). I will update the affected code and make it work again. The end-of-line would then be fine, too. Thanks, Alex __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From strandh at labri.fr Sat Feb 5 17:40:19 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 5 Feb 2005 18:40:19 +0100 Subject: [climacs-devel] forward/backward-object In-Reply-To: <20050205152835.36871.qmail@web40628.mail.yahoo.com> References: <16900.56255.539275.585443@serveur5.labri.fr> <20050205152835.36871.qmail@web40628.mail.yahoo.com> Message-ID: <16901.1283.517666.995539@serveur5.labri.fr> Aleksandar Bakic writes: > I will update the affected code and make it work again. The end-of-line > would then be fine, too. Perfect! -- 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 Feb 5 23:57:05 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 5 Feb 2005 15:57:05 -0800 (PST) Subject: [climacs-devel] indent-line and left-sticky-marks Message-ID: <20050205235705.62320.qmail@web40623.mail.yahoo.com> Hi, If the mark passed to indent-line is a left-sticky-mark, indent-line will fill tabs-then-spaces from right to left. For example, if tab-width is 4 and indentation is 5, the result of calling indent-line with a left-sticky-mark starts with a space followed by a tab. Is this OK, or should it rather work like tabify-region, which replaces right-side spaces with tabs? Alex __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From a_bakic at yahoo.com Sun Feb 6 00:17:49 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 5 Feb 2005 16:17:49 -0800 (PST) Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050205235705.62320.qmail@web40623.mail.yahoo.com> Message-ID: <20050206001749.18873.qmail@web40621.mail.yahoo.com> > Is this OK, or should it rather work > like tabify-region, which replaces right-side spaces with tabs? Sorry, I meant to say, "replaces spaces on the left side of a space region, with tabs". Alex __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From a_bakic at yahoo.com Sun Feb 6 15:15:12 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 6 Feb 2005 07:15:12 -0800 (PST) Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050206001749.18873.qmail@web40621.mail.yahoo.com> Message-ID: <20050206151512.929.qmail@web40606.mail.yahoo.com> I'd rewrite indent-line to first insert spaces only, and then call tabify-buffer-region on the inserted space region if tab-width is non-nil. It should then render correctly, regardless of the kind of mark used (would be a bit slower, though). Please let me know if there is a problem with this solution. Alex __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From a_bakic at yahoo.com Sun Feb 6 15:46:02 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 6 Feb 2005 07:46:02 -0800 (PST) Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050206151512.929.qmail@web40606.mail.yahoo.com> Message-ID: <20050206154602.82146.qmail@web40612.mail.yahoo.com> Sorry for flooding you with messages. Perhaps writing methods that specialize on left-sticky-mark and right-sticky-mark might be preferred (like I did with open-line) for performance reasons. Code common to both methods could be factored out. Alex > I'd rewrite indent-line to first insert spaces only, and then call > tabify-buffer-region on the inserted space region if tab-width is non-nil. It > should then render correctly, regardless of the kind of mark used (would be a > bit slower, though). Please let me know if there is a problem with this > solution. __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From a_bakic at yahoo.com Sun Feb 6 17:34:20 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 6 Feb 2005 09:34:20 -0800 (PST) Subject: [climacs-devel] delete-indentation Message-ID: <20050206173421.14820.qmail@web40606.mail.yahoo.com> Hi, What exactly is delete-indentation supposed to do? Could indent-line call delete-indentation instead of deleting spaces and tabs by itself? If delete-indentation should just delete indentation of the line pointed to by mark (even though the code seems to do something different), I have these questions: Should delete-indentation not clone its mark argument? Why does it not do anything when operating on the first line (when beginning-of-line causes the first call to beginning-of-buffer-p to return true)? Why does it call (delete-range mark -1) when it starts with calling beginning-of-line? 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 Mon Feb 7 00:35:51 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 6 Feb 2005 16:35:51 -0800 (PST) Subject: [climacs-devel] fill-line questions Message-ID: <20050207003551.40416.qmail@web40612.mail.yahoo.com> Hi, Should fill-line remove trailing spaces when wrapping a line? Or should this depend on the syntax, similar to how indentation is handled by calling syntax-line-indentation function parameter? fill-line seems to have been designed to support the auto-fill-mode, i.e., it wraps a line when point reaches fill-column. If we want to make it usable from code, perhaps it should not stop when it reaches its mark parameter, but work until the end of line (pointed to by the mark parameter). Do you agree or think that there should be another function(s) for off-line reformatting lines (paragraphs, blocks of code, etc.)? Alex __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From strandh at labri.fr Mon Feb 7 05:07:26 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 7 Feb 2005 06:07:26 +0100 Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050205235705.62320.qmail@web40623.mail.yahoo.com> References: <20050205235705.62320.qmail@web40623.mail.yahoo.com> Message-ID: <16902.63374.892.567343@serveur5.labri.fr> Aleksandar Bakic writes: > Hi, > > If the mark passed to indent-line is a left-sticky-mark, indent-line will fill > tabs-then-spaces from right to left. For example, if tab-width is 4 and > indentation is 5, the result of calling indent-line with a left-sticky-mark > starts with a space followed by a tab. Is this OK, or should it rather work > like tabify-region, which replaces right-side spaces with tabs? The latter, I would say. The thing would be to pas a type argument to clone-mark so that it is clear that it will be a right-sticky 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 strandh at labri.fr Mon Feb 7 05:08:22 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 7 Feb 2005 06:08:22 +0100 Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050206151512.929.qmail@web40606.mail.yahoo.com> References: <20050206001749.18873.qmail@web40621.mail.yahoo.com> <20050206151512.929.qmail@web40606.mail.yahoo.com> Message-ID: <16902.63430.228423.818522@serveur5.labri.fr> Aleksandar Bakic writes: > I'd rewrite indent-line to first insert spaces only, and then call > tabify-buffer-region on the inserted space region if tab-width is non-nil. It > should then render correctly, regardless of the kind of mark used (would be a > bit slower, though). Please let me know if there is a problem with this > solution. That sounds good. -- 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 Feb 7 05:09:09 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 7 Feb 2005 06:09:09 +0100 Subject: [climacs-devel] indent-line and left-sticky-marks In-Reply-To: <20050206154602.82146.qmail@web40612.mail.yahoo.com> References: <20050206151512.929.qmail@web40606.mail.yahoo.com> <20050206154602.82146.qmail@web40612.mail.yahoo.com> Message-ID: <16902.63477.756008.696634@serveur5.labri.fr> Aleksandar Bakic writes: > Sorry for flooding you with messages. Perhaps writing methods that specialize > on left-sticky-mark and right-sticky-mark might be preferred (like I did with > open-line) for performance reasons. Code common to both methods could be > factored out. It is probably easier then to just make sure the cloned mark is right-sticky. -- 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 Feb 7 05:17:17 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 7 Feb 2005 06:17:17 +0100 Subject: [climacs-devel] delete-indentation In-Reply-To: <20050206173421.14820.qmail@web40606.mail.yahoo.com> References: <20050206173421.14820.qmail@web40606.mail.yahoo.com> Message-ID: <16902.63965.332726.616535@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > What exactly is delete-indentation supposed to do? Could indent-line call > delete-indentation instead of deleting spaces and tabs by itself? I think so yes. But it still has to check that it is not the first line. > If delete-indentation should just delete indentation of the line pointed to by > mark (even though the code seems to do something different), I have these > questions: > > Should delete-indentation not clone its mark argument? Emacs does not. Whether or not Climacs should is debatable. I have no personal preference. > Why does it not do anything when operating on the first line (when > beginning-of-line causes the first call to beginning-of-buffer-p to return > true)? Probably because that's what Emacs does. > Why does it call (delete-range mark -1) when it starts with calling > beginning-of-line? Because the definition of the function is to join the line with the previous one. Check out Emacs. -- 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 Feb 7 05:19:28 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 7 Feb 2005 06:19:28 +0100 Subject: [climacs-devel] fill-line questions In-Reply-To: <20050207003551.40416.qmail@web40612.mail.yahoo.com> References: <20050207003551.40416.qmail@web40612.mail.yahoo.com> Message-ID: <16902.64096.508312.244891@serveur5.labri.fr> Aleksandar Bakic writes: > Hi, > > Should fill-line remove trailing spaces when wrapping a line? Probably. > Or should this > depend on the syntax, similar to how indentation is handled by calling > syntax-line-indentation function parameter? I don't see why that would be necessary. > fill-line seems to have been designed to support the auto-fill-mode, i.e., it > wraps a line when point reaches fill-column. If we want to make it usable from > code, perhaps it should not stop when it reaches its mark parameter, but work > until the end of line (pointed to by the mark parameter). Do you agree or think > that there should be another function(s) for off-line reformatting lines > (paragraphs, blocks of code, etc.)? I have no personal preference. When in doubt, check what Emacs does. Gratuitous differences are best avoided. -- 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 Mon Feb 7 21:35:56 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Mon, 7 Feb 2005 13:35:56 -0800 (PST) Subject: [climacs-devel] delete-indentation In-Reply-To: <16902.63965.332726.616535@serveur5.labri.fr> Message-ID: <20050207213556.62500.qmail@web40609.mail.yahoo.com> > Because the definition of the function is to join the line with the > previous one. Check out Emacs. OK, I see. However, it does not seem to work as it should (ignoring special cases that I saw in Emacs code). You can see by the one test I checked in (the lines are not joined like in Emacs). I'll try to fix it. Alex __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From strandh at labri.fr Thu Feb 10 09:58:56 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 10 Feb 2005 10:58:56 +0100 Subject: [climacs-devel] recent progress Message-ID: <16907.12384.535469.267092@serveur5.labri.fr> Dear mailing list member, Progress on Climacs is still very fast. This week, Aleksandar Bakic has continued with his work on using an alternative buffer implementation based on persistent data structures. He has also continued his work on the test framework for validating the buffer protocol and the functionality in base.lisp. Personally, I started the work on Common Lisp syntax by implementing an incremental lexer. The incremental parser will be working directly from a representation of the buffer as syntactic elements that are incrementally updated at redisplay time. Here is an itemized list of what happened the past week: * more work on making regions symmetric with respect to the marks (thanks to Aleksandar Bakic) * forward-object and backward-object are now part of the buffer protocol. * improvements to indent-line and delete-indentation (thanks to Aleksandar Bakic) * Improvements to html-syntax * Implemented the new protocol for updating syntax * Implemented an incremental lexer for Common Lisp syntax -- 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 drc01 at hampshire.edu Tue Feb 15 21:09:14 2005 From: drc01 at hampshire.edu (David Christiansen) Date: Tue, 15 Feb 2005 13:09:14 -0800 Subject: [climacs-devel] New to the list Message-ID: <8b7f19a4f4381d759993c6253f89ca72@hampshire.edu> Greetings all, I've been following the Climacs project for about a month now through the Web site and I'm interested in helping out. My Lisp skills are still somewhat limited at this point, but I'd love to contribute documentation and test code contributed by others on my Mac. Does anyone have any pointers as to what I should get started with? Which sections of the code are relatively fixed, and which are still sufficiently in flux that I should avoid them for now? Thank you, -David Christiansen From csr21 at cam.ac.uk Thu Feb 17 13:47:20 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 17 Feb 2005 13:47:20 +0000 Subject: [climacs-devel] command input context Message-ID: Hi, This patch, basically from Tim Moore, places a command input context at the toplevel; this is needed for my tabcode app, so that mouse clicks in a separate window can run commands. Light testing hasn't revealed any problems with it. (Next most annoying climacs bug/feature, from my point of view: C-x b resets the syntax of buffers. :-) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: climacs.diff URL: -------------- next part -------------- Cheers, Christophe From strandh at labri.fr Wed Feb 23 07:14:27 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 23 Feb 2005 08:14:27 +0100 Subject: [climacs-devel] recent progress Message-ID: <16924.11603.482154.498696@serveur5.labri.fr> Dear mailing list member. It has been two weeks since the latest progress report, simply because for a week I was quite busy with other things, so had time neither to make any progress to speak of, nor to write about it. The other day I could not think of anything that needed to be worked on urgently, other than large projects such as syntax modules for various programming languages, and creating a custom scroller pane. Perhaps this is a sign that Climacs is getting quite usable. In reality, there are of course tons of things that could be worked on, including many Emacs-features that are not yet implemented, in particular various introspective commands such as describe-xxx, help, etc. I continue to think that such features can wait until the basic editing commands exist. However, any of those features would be a reasonable medium-sized project for someone outside of the set of core developers to work on, so if anyone feels like making a contribution like that, let me know. Here is an itemized list of what has happened since the previous report: * The Climacs top-level loop now establishes an input context for commands, meaning that presentations that can trigger commands are now clickable. This possibility is not yet exploited in the core Climacs code, but an important syntax module (tabcode, not in the Climacs distribution) uses it. (Thanks to Christophe Rhodes) * A command (com-single-window) was added to delete all windows except the current. (Thanks to Elliott Johnson) * Implemented flag *numeric-argument-p* to detect whether a numeric argument was given at all. * Implemented eval-expression, M-:, which uses numeric-argument-p to determine whether to show the result in the minibuffer or to insert it into the buffer itself. * Used the new *numeric-argument-p* feature to implement Emacs-like behavior for kill-line. * next-line, previous-line, and open-line now take an additional optional argument indicating how many lines to move. com-next-line, com-previous-line, and com-open-line now take numeric arguments and pass then on to next-line, previous-line, and open-line. * Redisplay is now invoked when the frame is resized. This fixes an annoying problem where after the users resized the main window, a key had to be hit in order for the rest of the buffer to be visible. * Lines are no longer wrapped by CLIM. * Simplified implementation of com-delete-window. * Finally found and fixed a problem with using the adjuster gadget to adjust the size of windows. Now, the adjuster gadget is inserted whenever a window is split, either vertically or horizontally. * Implemented the possibility of issuing an abort gesture (C-g) to abort out of an extended command or reading of arguments. -- 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 Feb 23 08:26:09 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 23 Feb 2005 09:26:09 +0100 Subject: [climacs-devel] proposal for better error handling Message-ID: <16924.15905.899188.616818@serveur5.labri.fr> Hello, I would like your reaction to the following proposal, because it alters the buffer protocol slightly: * keep the no-such-offset condition, but make it be signaled only when an attempt is made to get to an object before the beginning or after the end of the buffer. * introduce two new conditions that inherit from no-such-offset: offset-before-beginning and offset-after-end with the obvious interpretation. * introduce a new condition invalid-motion used when an attempt is made to move a mark to an offset before the beginning or after the end of the buffer. * introduce two new conditions that inherit from invalid-motion: motion-before-beginning and motion-after-end with the obvious interpretation. * leave unspecified what happens if an attempt is made to use a mark with an invalid offset (< 0 or > size), other than neither of the conditions above will be signaled. This is a fatal error that should never occur, but we can leave it to the underlying buffer implementation to detect and signal it, for instance in the form of an illegal array reference. Leaving this unspecified avoids having to test for it or establish a handler for some condition in the underlying implementation, which will improve performance. With this proposal, the top-level loop can handle these conditions and give some reasonable message. Climacs commands can choose either not to bother and let the top-level loop handle them or else to handle them and do something reasonable in case that turns out to be a better strategy. Let me know what you think. -- 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 Wed Feb 23 08:54:40 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Wed, 23 Feb 2005 00:54:40 -0800 (PST) Subject: [climacs-devel] proposal for better error handling In-Reply-To: <16924.15905.899188.616818@serveur5.labri.fr> Message-ID: <20050223085440.14589.qmail@web40606.mail.yahoo.com> > * keep the no-such-offset condition, but make it be signaled only > when an attempt is made to get to an object before the beginning > or after the end of the buffer. Perhaps also add a slot to the condition indicating which buffer is in question, unless it will always be obvious. Alex __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From strandh at labri.fr Wed Feb 23 11:51:01 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 23 Feb 2005 12:51:01 +0100 Subject: [climacs-devel] proposal for better error handling In-Reply-To: <20050223085440.14589.qmail@web40606.mail.yahoo.com> References: <16924.15905.899188.616818@serveur5.labri.fr> <20050223085440.14589.qmail@web40606.mail.yahoo.com> Message-ID: <16924.28197.493439.336007@serveur5.labri.fr> Aleksandar Bakic writes: > > * keep the no-such-offset condition, but make it be signaled only > > when an attempt is made to get to an object before the beginning > > or after the end of the buffer. > > Perhaps also add a slot to the condition indicating which buffer is in > question, unless it will always be obvious. Good point. It might come in handy and it doesn't cost a lot. -- 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 Thu Feb 24 08:00:32 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 24 Feb 2005 00:00:32 -0800 (PST) Subject: [climacs-devel] two buffer/mark proposals Message-ID: <20050224080032.52442.qmail@web40613.mail.yahoo.com> Hi, What do you think about the following? 1. Instead of climacs-buffer directly inheriting standard-buffer, make it inherit buffer and add a slot that will contain a buffer passed at initialization time (standard-buffer by default). Also add all methods from the buffer protocol to climacs-buffer that just delegate to the passed buffer. This might be a bit slower (but not much, I believe) and would not require changes at climacs-buffer use places. A consequence: buffer implementations can easily be specified at run time. 2. Extend the clone-mark gf with a keyword :stick-to: when one wants to clone a mark but make sure it is left- or right-sticky (there were a few cases where I needed this but got around it). This could also help at places similar to those in pane.lisp creating mark instances that I marked with "PB". Thanks, Alex __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From strandh at labri.fr Thu Feb 24 08:54:44 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 24 Feb 2005 09:54:44 +0100 Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <20050224080032.52442.qmail@web40613.mail.yahoo.com> References: <20050224080032.52442.qmail@web40613.mail.yahoo.com> Message-ID: <16925.38484.146488.685685@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > 1. Instead of climacs-buffer directly inheriting standard-buffer, make it > inherit buffer and add a slot that will contain a buffer passed at > initialization time (standard-buffer by default). Also add all methods from the > buffer protocol to climacs-buffer that just delegate to the passed buffer. This > might be a bit slower (but not much, I believe) and would not require changes > at climacs-buffer use places. A consequence: buffer implementations can easily > be specified at run time. Sounds good. > 2. Extend the clone-mark gf with a keyword :stick-to: when one wants to clone a > mark but make sure it is left- or right-sticky (there were a few cases where I > needed this but got around it). This could also help at places similar to those > in pane.lisp creating mark instances that I marked with "PB". Sure. You could then remove the current `type' argument which depends on the buffer implementation. -- 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 Feb 24 12:40:41 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 24 Feb 2005 13:40:41 +0100 Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <20050224080032.52442.qmail@web40613.mail.yahoo.com> References: <20050224080032.52442.qmail@web40613.mail.yahoo.com> Message-ID: <16925.52041.261045.220150@serveur5.labri.fr> Aleksandar Bakic writes: > 2. Extend the clone-mark gf with a keyword :stick-to: when one wants to clone a > mark but make sure it is left- or right-sticky (there were a few cases where I > needed this but got around it). This could also help at places similar to those > in pane.lisp creating mark instances that I marked with "PB". Are you planning to implement this any time soon? Otherwise, I am, because I am also going to optimize the code of clone-mark. Let me know as soon as possible. -- 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 Feb 25 00:03:33 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 24 Feb 2005 16:03:33 -0800 (PST) Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <16925.52041.261045.220150@serveur5.labri.fr> Message-ID: <20050225000333.18947.qmail@web40606.mail.yahoo.com> > Are you planning to implement this any time soon? > > Otherwise, I am, because I am also going to optimize the code of > clone-mark. Let me know as soon as possible. I can do it over the weekend. Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From strandh at labri.fr Fri Feb 25 05:00:47 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 25 Feb 2005 06:00:47 +0100 Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <20050225000333.18947.qmail@web40606.mail.yahoo.com> References: <16925.52041.261045.220150@serveur5.labri.fr> <20050225000333.18947.qmail@web40606.mail.yahoo.com> Message-ID: <16926.45311.561647.654064@serveur5.labri.fr> Aleksandar Bakic writes: > > Are you planning to implement this any time soon? > > > > Otherwise, I am, because I am also going to optimize the code of > > clone-mark. Let me know as soon as possible. > > I can do it over the weekend. Too late. I need it for my lexer speedup. I'll do it. You can do item number one over the weekend 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 a_bakic at yahoo.com Sat Feb 26 21:42:07 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 26 Feb 2005 13:42:07 -0800 (PST) Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <16926.45311.561647.654064@serveur5.labri.fr> Message-ID: <20050226214207.53460.qmail@web40625.mail.yahoo.com> > You can do item number one over the weekend if you like. I am working on it. I noticed the following so far: 1. buffer-column/line-number seems like a part of the buffer protocol, but is not documented. 2. possibly-expand-abbrev takes a mark and then expect that there is a method abbrev-expander for the buffer of the mark. It works thaks to the abbrev-mixin being inherited from by climacs-buffer. I wrote a delegating-buffer class, which inherits from the buffer class, and changed climacs-buffer to inherit from it instead of the standard-buffer class. I also wrote extended-standard-buffer class that inherits from standard-buffer and abbrev-mixin, and put an instance of it into the default initargs of climacs-buffer. This way, I can pass a different buffer implementation when instantiating climacs-buffer. I also had to make sure that all marks created in pane.lisp are getting an appropriate buffer implementation as their :buffer argument (using clone-mark and low/high-mark, because mark implementations know about the corresponding buffer implementations). I am learning about other pieces of climacs while doing this, so even if you think this is not a good approach, time is not wasted. However, perhaps it would be better to break the functionality into something like: 1. buffer protocol (buffer and mark implementations) 2. extended buffers (like the abbrev solution, unless it should be changed) 3. climacs-buffer with its gui-level stuff that can work with different implementations Currently, all the above is mixed together in climacs-buffer, so there may be application-specific code that has access to all the three layers above. I am debugging an undo-related problem right now. If I manage to fix it and similar issues (the problem is, I have to try all the functionality manually as there are no tests), I would check my changes in. I'll wait for some feedback first. 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 Sun Feb 27 12:03:26 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 27 Feb 2005 04:03:26 -0800 (PST) Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <20050226214207.53460.qmail@web40625.mail.yahoo.com> Message-ID: <20050227120327.29420.qmail@web40602.mail.yahoo.com> I solved the undo problem. Here are the essentials diffs besides the delegating-buffer class in its own file. Alex Index: pane.lisp =================================================================== RCS file: /project/climacs/cvsroot/climacs/pane.lisp,v retrieving revision 1.18 diff -c -r1.18 pane.lisp *** pane.lisp 5 Feb 2005 06:49:53 -0000 1.18 --- pane.lisp 27 Feb 2005 11:58:10 -0000 *************** *** 135,140 **** --- 135,157 ---- (mapc #'flip-undo-record records) (setf records (nreverse records)))) + ;;; undo-mixin delegation (here because of the package) + + (defmethod undo-tree ((buffer delegating-buffer)) + (undo-tree (implementation buffer))) + + (defmethod undo-accumulate ((buffer delegating-buffer)) + (undo-accumulate (implementation buffer))) + + (defmethod (setf undo-accumulate) (object (buffer delegating-buffer)) + (setf (undo-accumulate (implementation buffer)) object)) + + (defmethod performing-undo ((buffer delegating-buffer)) + (performing-undo (implementation buffer))) + + (defmethod (setf performing-undo) (object (buffer delegating-buffer)) + (setf (performing-undo (implementation buffer)) object)) + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Isearch *************** *** 165,176 **** ;(defgeneric indent-tabs-mode (climacs-buffer)) ! (defclass climacs-buffer (standard-buffer abbrev-mixin filename-mixin name-mixin undo-mixin) ;PB ((needs-saving :initform nil :accessor needs-saving) (syntax :accessor syntax) (indent-tabs-mode :initarg indent-tabs-mode :initform t :accessor indent-tabs-mode)) ! (:default-initargs :name "*scratch*")) (defmethod initialize-instance :after ((buffer climacs-buffer) &rest args) (declare (ignore args)) --- 182,201 ---- ;(defgeneric indent-tabs-mode (climacs-buffer)) ! (defclass extended-standard-buffer (standard-buffer undo-mixin abbrev-mixin) () ! (:documentation "Extensions accessible via marks.")) ! ! (defclass extended-obinseq-buffer (obinseq-buffer undo-mixin abbrev-mixin) () ! (:documentation "Extensions accessible via marks.")) ! ! (defclass climacs-buffer (delegating-buffer filename-mixin name-mixin) ((needs-saving :initform nil :accessor needs-saving) (syntax :accessor syntax) (indent-tabs-mode :initarg indent-tabs-mode :initform t :accessor indent-tabs-mode)) ! (:default-initargs ! :name "*scratch*" ! :implementation (make-instance 'extended-standard-buffer))) (defmethod initialize-instance :after ((buffer climacs-buffer) &rest args) (declare (ignore args)) *************** *** 210,223 **** (declare (ignore args)) (with-slots (buffer point mark) pane (when (null point) ! (setf point (make-instance 'standard-right-sticky-mark ;PB ! :buffer buffer))) (when (null mark) ! (setf mark (make-instance 'standard-right-sticky-mark ;PB ! :buffer buffer)))) (with-slots (buffer top bot scan) pane ! (setf top (make-instance 'standard-left-sticky-mark :buffer buffer) ;PB ! bot (make-instance 'standard-right-sticky-mark :buffer buffer))) ;PB (setf (stream-default-view pane) (make-instance 'climacs-textual-view)) (with-slots (space-width tab-width) (stream-default-view pane) (let* ((medium (sheet-medium pane)) --- 235,246 ---- (declare (ignore args)) (with-slots (buffer point mark) pane (when (null point) ! (setf point (clone-mark (low-mark buffer) :right))) (when (null mark) ! (setf mark (clone-mark (low-mark buffer) :right)))) (with-slots (buffer top bot scan) pane ! (setf top (clone-mark (low-mark buffer) :left) ! bot (clone-mark (high-mark buffer) :right))) (setf (stream-default-view pane) (make-instance 'climacs-textual-view)) (with-slots (space-width tab-width) (stream-default-view pane) (let* ((medium (sheet-medium pane)) *************** *** 227,238 **** (defmethod (setf buffer) :after (buffer (pane climacs-pane)) (with-slots (point mark top bot) pane ! (setf point (make-instance 'standard-right-sticky-mark ;PB ! :buffer buffer) ! mark (make-instance 'standard-right-sticky-mark ;PB ! :buffer buffer) ! top (make-instance 'standard-left-sticky-mark :buffer buffer) ;PB ! bot (make-instance 'standard-right-sticky-mark :buffer buffer)))) ;PB (define-presentation-type url () :inherit-from 'string) --- 250,259 ---- (defmethod (setf buffer) :after (buffer (pane climacs-pane)) (with-slots (point mark top bot) pane ! (setf point (clone-mark (low-mark (implementation buffer)) :right) ! mark (clone-mark (low-mark (implementation buffer)) :right) ! top (clone-mark (low-mark (implementation buffer)) :left) ! bot (clone-mark (high-mark (implementation buffer)) :right)))) __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From a_bakic at yahoo.com Sun Feb 27 18:59:38 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sun, 27 Feb 2005 10:59:38 -0800 (PST) Subject: [climacs-devel] delegating-buffer changes Message-ID: <20050227185938.1307.qmail@web40614.mail.yahoo.com> Hi, I committed my changes after manually testing Climacs commands. I had to add some delegation for syntax purposes, so I suppose we'll need to spend some more time on cleaning up the class hierarchy... I noticed the following issues (among others about which I need to learn more, both with the old and new code): 1. Transpose * and some other commands do not support undo correctly and break. 2. Switch To Buffer resets syntax to Basic (even when the buffer exists and has a different syntax). 3. Back To Indentation cannot be typed in. 4. Isearch Append Char breaks (and I do not know how to use it). 5. Query Replace breaks in some cases. Alex __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From strandh at labri.fr Mon Feb 28 08:58:37 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 28 Feb 2005 09:58:37 +0100 Subject: [climacs-devel] two buffer/mark proposals In-Reply-To: <20050226214207.53460.qmail@web40625.mail.yahoo.com> References: <16926.45311.561647.654064@serveur5.labri.fr> <20050226214207.53460.qmail@web40625.mail.yahoo.com> Message-ID: <16930.56637.287575.934175@serveur5.labri.fr> Hello, Aleksandar Bakic writes: > > You can do item number one over the weekend if you like. > > I am working on it. I noticed the following so far: > > 1. buffer-column/line-number seems like a part of the buffer protocol, but is > not documented. > > 2. possibly-expand-abbrev takes a mark and then expect that there is a method > abbrev-expander for the buffer of the mark. It works thaks to the abbrev-mixin > being inherited from by climacs-buffer. > > I wrote a delegating-buffer class, which inherits from the buffer class, and > changed climacs-buffer to inherit from it instead of the standard-buffer class. > I also wrote extended-standard-buffer class that inherits from standard-buffer > and abbrev-mixin, and put an instance of it into the default initargs of > climacs-buffer. This way, I can pass a different buffer implementation when > instantiating climacs-buffer. I also had to make sure that all marks created in > pane.lisp are getting an appropriate buffer implementation as their :buffer > argument (using clone-mark and low/high-mark, because mark implementations know > about the corresponding buffer implementations). > > I am learning about other pieces of climacs while doing this, so even if you > think this is not a good approach, time is not wasted. However, perhaps it > would be better to break the functionality into something like: > > 1. buffer protocol (buffer and mark implementations) > 2. extended buffers (like the abbrev solution, unless it should be changed) > 3. climacs-buffer with its gui-level stuff that can work with different > implementations > > Currently, all the above is mixed together in climacs-buffer, so there may be > application-specific code that has access to all the three layers above. I am > debugging an undo-related problem right now. If I manage to fix it and similar > issues (the problem is, I have to try all the functionality manually as there > are no tests), I would check my changes in. I'll wait for some feedback first. Your guesses are as good as mine. It often helps to implement something in order to see whether the architecture is supporting the implementation. If it doesn't work out, we'll change it 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. ---------------------------------------------------------------------