From athas at sigkill.dk  Tue May  2 18:09:58 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 02 May 2006 20:09:58 +0200
Subject: [climacs-devel] Climacs - self documenting editor?
In-Reply-To: <87lktu94wx.fsf@sigkill.dk> (Troels Henriksen's message of
	"Mon, 24 Apr 2006 20:58:38 +0200")
References: <87lktu94wx.fsf@sigkill.dk>
Message-ID: <87r73cmh6x.fsf@sigkill.dk>

Troels Henriksen <athas at sigkill.dk> writes:

> Climacs is severely lacking in the self-documenting aspect of The
> Emacs Way. 

I have hopefully just alleviated this problem a bit (check C-h k and
C-h f). Please post if my recent commits cause any problems.

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From csr21 at cam.ac.uk  Wed May  3 09:22:16 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 03 May 2006 10:22:16 +0100
Subject: [climacs-devel] command handlers for parse errors
Message-ID: <sqiron31kn.fsf@cam.ac.uk>

Hi,

I exposed recently by altering some handler types the possibility of
lisp errors from accept methods when the user emits an activation
gesture when the object being can't be parsed (doesn't complete, has
an ambiguous completion, or isn't of the required type).

Troels' solution is (in his latest patch)

+    (handler-case (set-syntax buffer (accept 'syntax :prompt "Set Syntax"))
+                  (input-not-of-required-type 
+                   (message)
+                   (display-message "Invalid syntax: ~A." message)))))

but I think I have a better way, buried in amongst all the other
mutations I have accumulated.

The trick is to define a stream-accept method for the ESA minibuffer:
something like

(defmethod stream-accept :around ((pane minibuffer-pane) type &rest args)
  (declare (ignore args))
  ;; FIXME: this isn't the friendliest way of indicating a parse
  ;; error: there's no feedback, unlike emacs' quite nice "[no
  ;; match]".
  (loop
   (handler-case 
       (return (call-next-method))
     (parse-error ()
       nil))))

This causes the failing accept to be re-entered, which does almost the
right thing; with my command processor it clears the window and
re-prompts, but it doesn't re-insert the text the user entered because
there's no documented way of getting hold of that in a parse-error
(completion-error, input-not-of-required-type -- well, the latter
/might/ allow for getting hold of the string; it's not completely
clear to me).

I think that a unified, emacs-style method for handling input errors
is likely to be a win, from both reusability and maintainability
aspects.

Comments?

Cheers,

Christophe


From asf at boinkor.net  Wed May  3 18:09:39 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Wed, 03 May 2006 20:09:39 +0200
Subject: [climacs-devel] command handlers for parse errors
In-Reply-To: <sqiron31kn.fsf@cam.ac.uk>
References: <sqiron31kn.fsf@cam.ac.uk>
Message-ID: <87lktj3rq4.wl%asf@boinkor.net>

Today, Christophe Rhodes <csr21 at cam.ac.uk> wrote:
> but I think I have a better way, buried in amongst all the other
> mutations I have accumulated.
>
> The trick is to define a stream-accept method for the ESA
> minibuffer: something like
>
> (defmethod stream-accept :around ((pane minibuffer-pane) type &rest args)
>   (declare (ignore args))
>   ;; FIXME: this isn't the friendliest way of indicating a parse
>   ;; error: there's no feedback, unlike emacs' quite nice "[no
>   ;; match]".
>   (loop
>    (handler-case 
>        (return (call-next-method))
>      (parse-error ()
>        nil))))
>
> This causes the failing accept to be re-entered, which does almost
> the right thing; with my command processor it clears the window and
> re-prompts, but it doesn't re-insert the text the user entered
> because there's no documented way of getting hold of that in a
> parse-error (completion-error, input-not-of-required-type -- well,
> the latter /might/ allow for getting hold of the string; it's not
> completely clear to me).

As stream-accept operates on extended input streams, we should be able
to use the extended input stream protocol to get the string content of
the stream:

(defun save-input-line (stream frame)
  (when (current-receiver frame)
    (let ((buffer (stream-input-buffer stream)))
      (setf (incomplete-input (current-receiver frame))
            (with-output-to-string (s)
              (loop for elt across buffer
                    if (characterp elt)
                      do (write-char elt s))))
      (incomplete-input (current-receiver frame)))))

is what we use in beirc. Stream corresponds to the pane's extended
input stream, of course, and if that works, you can do with the input
whatever you want. (:

In beirc, we have to replace the input with :rescan t, which will barf
again on malformed input, but I'm sure your command reader is smart
enough not to do that (:

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs


From csr21 at cam.ac.uk  Thu May  4 08:00:01 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 04 May 2006 09:00:01 +0100
Subject: [climacs-devel] asdf-installability
Message-ID: <sqpsiucj9a.fsf@cam.ac.uk>

Hi,

I would like to take a snapshot of what we have and make it
asdf-installable.  I don't intend to do any release engineering, but I
would like something that minimally works (which probably means that
someone needs to sort out the situation with completion errors: is it
still the case that M-x Something RET gives a lisp error?  Is my
stream-accept method good enough?

(The point of this snapshot is to give a somewhat stable base that
works with a released, asdf-installable version of McCLIM.)

Cheers,

Christophe


From csr21 at cam.ac.uk  Thu May  4 10:55:30 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 04 May 2006 11:55:30 +0100
Subject: [climacs-devel] keyboard macros, display protocol
Message-ID: <sqvesmdpp9.fsf@cam.ac.uk>

Hi,

The below implements keyboard macros with the numeric argument.  It
seems to work, up to a point.

The point at which it stops working is if the keyboard macro changes
the number of lines in the display, and indeed the problem can be seen
without this patch: start climacs, type (say), abcdefg, put point at
the start of line, and do
  C-x ( C-f RET C-f RET C-f RET C-x ) C-x e
(BOOM).

The reason that this is a disaster is because we have multiple
commands, multiple update-syntaxes, and multiple clear-modifies
between successive redisplays, and this plays havoc with the cache
maintained in climacs pane.lisp.

I sat down and doodled a while this morning, thinking about it, and I
think that the answer is to define a new pair of marks for climacs
buffers: just as there is a call chain
  execute-frame-command -> update-syntax
                        -> clear-modify
where update-syntax can rely on low-mark and high-mark to work out
what needs to be reparsed, I think there needs to be
  redisplay-frame-panes -> update-syntax-for-display
                        -> clear-modify-for-display
where the new pair of marks isn't so much for
update-syntax-for-display's benefit as for some of the bookkeeping
code in pane.lisp

The point here is that there should be a complete separation between
the bookkeeping done at each command, and the bookkeeping done for
each redisplay, as commands and displays are not one-to-one.

Comments?

Cheers,

Christophe

;;; works fine with gsharp.
(define-command (com-call-last-kbd-macro
                 :name t
                 :command-table keyboard-macro-table)
    ((count 'integer))
  (setf (remaining-keys *application-frame*)
  (loop repeat count append (recorded-keys *application-frame*)))
  (setf (executingp *application-frame*) t))

(set-key `(com-call-last-kbd-macro ,*numeric-argument-marker*)
         'keyboard-macro-table '((#\x :control) #\e))



From csr21 at cam.ac.uk  Thu May  4 13:17:26 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 04 May 2006 14:17:26 +0100
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <sqvesmdpp9.fsf@cam.ac.uk> (Christophe Rhodes's message of "Thu, 
	04 May 2006 11:55:30 +0100")
References: <sqvesmdpp9.fsf@cam.ac.uk>
Message-ID: <sqvesmudy1.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> The point here is that there should be a complete separation between
> the bookkeeping done at each command, and the bookkeeping done for
> each redisplay, as commands and displays are not one-to-one.

Maybe to put people on the same page, I attach two diffs.  The first
is an implementation of low-display-mark and high-display-mark, and
use in the adjust-cache function used in basic-syntax.  The second is
essentially a complete removal of the cache for basic-syntax:
essentially, empty-cache will be run at each redisplay of a pane.

I favour the second patch, reworked for clarity, as a solution to the
problem, as it does not introduce knowledge into the buffer about what
is going to happen next: indeed, there are uses of climacs buffers
that do not involve a traditional display, such as a web application
we use to present tablature.  This will make basic-syntax a lot more
basic, but the essential functionality of cacheing lines and
incremental redisplay that was in basic-syntax is in fact available in
fundamental-syntax.

This raises another (low-urgency, probably) issue, though: at present,
it's not possible to extend syntaxes other than in interesting ways.
The display methods (e.g. redisplay-pane-with-syntax) will depend on
the invariants of their syntax being preserved, so it's not possible
to specialize e.g. update-syntax on a subclass of a syntax which uses
update-syntax itself to preserve invariants, without duplicating that
method (or explicitly doing call-next-method).  I think that
update-syntax, and probably update-syntax-for-display, should be
generic functions with progn :most-specific-last method combination to
solve this problem.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: climacs-display-cache.diff
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20060504/58db7e6a/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: climacs-basic-syntax.diff
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20060504/58db7e6a/attachment-0001.ksh>
-------------- next part --------------

Cheers,

Christophe

From splittist at yahoo.com  Fri May  5 07:12:16 2006
From: splittist at yahoo.com (John Q Splittist)
Date: Fri, 5 May 2006 07:12:16 +0000 (UTC)
Subject: [climacs-devel] Re: Climacs - self documenting editor?
References: <87lktu94wx.fsf@sigkill.dk>
	<loom.20060425T085638-175@post.gmane.org>
Message-ID: <loom.20060505T090427-600@post.gmane.org>

John Q Splittist <splittist <at> yahoo.com> writes:

> True. I present the attached as a start on the other end of the problem

These docstrings have now been added.

The general format I adopted was to begin each docstring with a short line, 
then (in most cases) have a more general set of information in the following 
line. I've also included some FIXME stuff, on the grounds that seeing it in a 
help message might prompt action.

The reasons for the two-line format are:

* A vague thought that splitting the docstring on the (first) #\Newline would 
give a short description suitable for the minibuffer or lists of commands; and

* Not including #\Newlines in the remainder of the string would encourage us 
to flow the text attractively across the available screen real-estate, 
whatever that might be in any particular case. (I find the Gnu Emacs docstring 
help presentation particularly ugly.)

As always, counter-arguments are welcome.

Cheers,
JQS





From csr21 at cam.ac.uk  Fri May  5 10:57:19 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Fri, 05 May 2006 11:57:19 +0100
Subject: [climacs-devel] asdf-installability
In-Reply-To: <sqpsiucj9a.fsf@cam.ac.uk> (Christophe Rhodes's message of "Thu, 
	04 May 2006 09:00:01 +0100")
References: <sqpsiucj9a.fsf@cam.ac.uk>
Message-ID: <sq64kkloxc.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> (The point of this snapshot is to give a somewhat stable base that
> works with a released, asdf-installable version of McCLIM.)

I got limited feedback on this yesterday on IRC, broadly positive, so
I have made it happen.  If someone objects, by all means remove the
package link on CLiki.

Cheers,

Christophe


From athas at sigkill.dk  Fri May  5 13:54:12 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 05 May 2006 15:54:12 +0200
Subject: [climacs-devel] Re: Climacs - self documenting editor?
In-Reply-To: <loom.20060505T090427-600@post.gmane.org> (John Q. Splittist's
	message of "Fri, 5 May 2006 07:12:16 +0000 (UTC)")
References: <87lktu94wx.fsf@sigkill.dk>
	<loom.20060425T085638-175@post.gmane.org>
	<loom.20060505T090427-600@post.gmane.org>
Message-ID: <8764kkziez.fsf@sigkill.dk>

John Q Splittist <splittist at yahoo.com> writes:

> As always, counter-arguments are welcome.

I don't think it is a good idea to put entire docstrings on one line
merely because we do not want hard word-wrapping when outputting
them. Instead, I think that the function `print-docstring-for-command'
should perform a bit of parsing before displaying the docstring, such
as removing single linebreaks (but preserving double linebreaks to
allow for paragraphs). That way the docstring will be properly folded
with respect to the size of the pane, but the docstrings can still be
written in a way that is easily editable in a text-editor (ie. under
80 characters in width per line).

Parsing the docstring in `print-docstring-for-command' would also
allow other neat tricks, such as hyperlinking word sets like
Uppercased Words to the documentation for the command with the
respective name (if any).

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From splittist at yahoo.com  Fri May  5 15:48:17 2006
From: splittist at yahoo.com (John Q Splittist)
Date: Fri, 5 May 2006 15:48:17 +0000 (UTC)
Subject: [climacs-devel] Re: Climacs - self documenting editor?
References: <87lktu94wx.fsf@sigkill.dk>
	<loom.20060425T085638-175@post.gmane.org>
	<loom.20060505T090427-600@post.gmane.org>
	<8764kkziez.fsf@sigkill.dk>
Message-ID: <loom.20060505T174521-201@post.gmane.org>

Troels Henriksen <athas <at> sigkill.dk> writes:

> I don't think it is a good idea to put entire docstrings on one line

I agree, for all the reasons you cite. But I would prefer that the intentional 
ugliness remain until we've written the parsing stuff (to incentivise us to do 
something.... But that's an argument about me and my motivation....).

> Parsing the docstring in `print-docstring-for-command' would also
> allow other neat tricks

Very true.

JQS





From strandh at labri.fr  Fri May  5 19:17:56 2006
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 5 May 2006 21:17:56 +0200
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <sqvesmdpp9.fsf@cam.ac.uk>
References: <sqvesmdpp9.fsf@cam.ac.uk>
Message-ID: <17499.42212.679910.245309@serveur5.labri.fr>

Christophe Rhodes writes:
 > 
 > The below implements keyboard macros with the numeric argument.  It
 > seems to work, up to a point.
 > 
 > The point at which it stops working is if the keyboard macro changes
 > the number of lines in the display, and indeed the problem can be seen
 > without this patch: start climacs, type (say), abcdefg, put point at
 > the start of line, and do
 >   C-x ( C-f RET C-f RET C-f RET C-x ) C-x e
 > (BOOM).
 > 
 > The reason that this is a disaster is because we have multiple
 > commands, multiple update-syntaxes, and multiple clear-modifies
 > between successive redisplays, and this plays havoc with the cache
 > maintained in climacs pane.lisp.

That should not be the case.  The syntax should be updated and the
modification cleared only after each user interaction.  Executing a
command as a result of executing a keyboard macro should not update
the 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 strandh at labri.fr  Fri May  5 20:19:41 2006
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 5 May 2006 22:19:41 +0200
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <sqvesmudy1.fsf@cam.ac.uk>
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<sqvesmudy1.fsf@cam.ac.uk>
Message-ID: <17499.45917.281202.638924@serveur5.labri.fr>

Christophe Rhodes writes:
 > 
 > Maybe to put people on the same page, I attach two diffs.  The first
 > is an implementation of low-display-mark and high-display-mark, and
 > use in the adjust-cache function used in basic-syntax.

Unless I have missed something, introducing these new marks does not
look like the right solution to me.  The buffer protocol should not
have to know about the complications that arise because of keyboard
macros. 

Perhaps we should instead make sure (say by checking executingp) that
redisplay is not called while a keyboard macro is being executed. 

-- 
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 May  5 19:59:27 2006
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 5 May 2006 21:59:27 +0200
Subject: [climacs-devel] execute-frame-command
In-Reply-To: <sqzmjf7wab.fsf@cam.ac.uk>
References: <sqzmjf7wab.fsf@cam.ac.uk>
Message-ID: <17499.44703.675827.302033@serveur5.labri.fr>

Hello,

Christophe Rhodes writes:
 > 
 > The CLIM spec allows execute-frame-command to be called on a frame
 > from threads not associated with that frame, apparently to implement
 > cross-application scripting or something along those lines: for
 > instance, a file manager could send a user's request to edit a file to
 > an already-running text editor.
 > 
 > This means that execute-frame-command methods should not use special
 > variables such as *application-frame* and *standard-output*, as they
 > could be executed in the wrong thread: 

OK, sounds good. 

 > and indeed
 > execute-frame-command should not assume that anything has been
 > executed.

I don't understand what you mean here. 

 > I'm not able to do really interesting things with this yet, because
 > many of the gsharp or esa commands don't take arguments but instead
 > prompt (accept) explicitly.  Why was it done this way?  My hypothesis
 > is that it's done this way so that we don't overrun the minibuffer:
 > hitting RET doesn't cause some accepting-values dialog to pop up or
 > similar.  I mentioned this on IRC to Tim Moore, and he mumbled
 > something about *partial-command-parser*: I think his idea is that we
 > should bind that (and possibly also *command-parser*) to get the
 > minibuffer behaviour we want, and then the commands' arglists should
 > reflect all the information needed from the user.
 > 
 > Does that make any sense?

Yes.  I think it was done that way because either McCLIM was not able
to acquire the arguments at all, or it did it in a way that was not
acceptable to Climacs.  Writing our own partial command parser sounds
like the right thing to do (and I believe you have already done this,
at least partially (no pun intended)). 

 > PS: My kingdom for only one copy of ESA...

I agree that it would be nice to break out ESA and turn it into its
own cl.net project.  The problem with this is that someone has to have
the project created, administer the mailing lists, etc.  Furthermore,
it will add another dependency, but I guess that is not too much of a
problem compared to maintaining two copies.

Does anyone want to become the proud owner of a cl.net project?

-- 
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  Fri May  5 22:08:28 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Fri, 05 May 2006 23:08:28 +0100
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <17499.42212.679910.245309@serveur5.labri.fr> (Robert Strandh's
	message of "Fri, 5 May 2006 21:17:56 +0200")
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<17499.42212.679910.245309@serveur5.labri.fr>
Message-ID: <squ0846s6b.fsf@cam.ac.uk>

Robert Strandh <strandh at labri.fr> writes:

> Christophe Rhodes writes:
>  > 
>  > The below implements keyboard macros with the numeric argument.  It
>  > seems to work, up to a point.
>  > 
>  > The point at which it stops working is if the keyboard macro changes
>  > the number of lines in the display, and indeed the problem can be seen
>  > without this patch: start climacs, type (say), abcdefg, put point at
>  > the start of line, and do
>  >   C-x ( C-f RET C-f RET C-f RET C-x ) C-x e
>  > (BOOM).
>  > 
>  > The reason that this is a disaster is because we have multiple
>  > commands, multiple update-syntaxes, and multiple clear-modifies
>  > between successive redisplays, and this plays havoc with the cache
>  > maintained in climacs pane.lisp.
>
> That should not be the case.  The syntax should be updated and the
> modification cleared only after each user interaction.  Executing a
> command as a result of executing a keyboard macro should not update
> the syntax. 

I don't think this can be right.  If you do that, then sequences of
commands (such as, say "Insert Open Paren" followed by "Up List") will
do different things depending on whether they are executed by
keystrokes or by keyboard macros.  Instead, I think that the syntax
must be updated after each command.

Cheers,

Christophe


From strandh at labri.fr  Fri May  5 22:59:36 2006
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 6 May 2006 00:59:36 +0200
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <squ0846s6b.fsf@cam.ac.uk>
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<17499.42212.679910.245309@serveur5.labri.fr>
	<squ0846s6b.fsf@cam.ac.uk>
Message-ID: <17499.55512.908145.594858@serveur5.labri.fr>

Christophe Rhodes writes:
 > > That should not be the case.  The syntax should be updated and the
 > > modification cleared only after each user interaction.  Executing a
 > > command as a result of executing a keyboard macro should not update
 > > the syntax. 
 > 
 > I don't think this can be right.  If you do that, then sequences of
 > commands (such as, say "Insert Open Paren" followed by "Up List") will
 > do different things depending on whether they are executed by
 > keystrokes or by keyboard macros.  Instead, I think that the syntax
 > must be updated after each command.

I would prefer that this case be handled by having the commands that
require the syntax to be up to date explicitly call whatever function
updates the 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 splittist at yahoo.com  Sat May  6 14:41:21 2006
From: splittist at yahoo.com (John Q Splittist)
Date: Sat, 06 May 2006 16:41:21 +0200
Subject: [climacs-devel] Re: Number recognition in the Lisp syntax module
In-Reply-To: <87ejzos68t.fsf@sigkill.dk>
References: <87slo94rmv.fsf@sigkill.dk>	<loom.20060419T174809-655@post.gmane.org>
	<87hd4pl3m8.fsf@sigkill.dk> <87ejzos68t.fsf@sigkill.dk>
Message-ID: <445CB591.5040009@yahoo.com>

Troels Henriksen wrote:

> Well, done. Climacs now supports something like Emacs' local buffer
> variables

I started making a few changes to the parsing part of this that ended up 
being a bit bigger than I intended, so apologies if you think I've gone 
too far.

One thing that would be nice is to be able to do a Set Option (and View 
Option) [or ... Attribute], which would query the relevant Syntax about 
what options could be set, and what their current values were. (And it 
might be nice if it kept the list of all options, whether understood or 
not.)

(Zmacs also had Update Attribute List, which would rewrite your -*- line 
for you...)

Cheers,
JQS


From athas at sigkill.dk  Sat May  6 15:39:28 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 06 May 2006 17:39:28 +0200
Subject: [climacs-devel] Re: Number recognition in the Lisp syntax module
In-Reply-To: <445CB591.5040009@yahoo.com> (John Q. Splittist's message of
	"Sat, 06 May 2006 16:41:21 +0200")
References: <87slo94rmv.fsf@sigkill.dk>
	<loom.20060419T174809-655@post.gmane.org> <87hd4pl3m8.fsf@sigkill.dk>
	<87ejzos68t.fsf@sigkill.dk> <445CB591.5040009@yahoo.com>
Message-ID: <87slnnf9hr.fsf@sigkill.dk>

John Q Splittist <splittist at yahoo.com> writes:

> I started making a few changes to the parsing part of this that ended
> up being a bit bigger than I intended, so apologies if you think I've
> gone too far.

I think your patch is great - and thank you for creating a more
sensible terminology, I didn't really have time to properly consider
names when I wrote the original code, and I found Emacs' "local-buffer
variable"-concept to be disjunct from what we actually want in
Climacs.

> (Zmacs also had Update Attribute List, which would rewrite your -*-
> line for you...)

This would be nice, but would it really be useful? Perhaps if we add
more options - what kind of attributes did Zmacs support?

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From csr21 at cam.ac.uk  Sat May  6 15:43:34 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sat, 06 May 2006 16:43:34 +0100
Subject: [climacs-devel] Re: Number recognition in the Lisp syntax module
In-Reply-To: <445CB591.5040009@yahoo.com> (John Q. Splittist's message of
	"Sat, 06 May 2006 16:41:21 +0200")
References: <87slo94rmv.fsf@sigkill.dk>
	<loom.20060419T174809-655@post.gmane.org> <87hd4pl3m8.fsf@sigkill.dk>
	<87ejzos68t.fsf@sigkill.dk> <445CB591.5040009@yahoo.com>
Message-ID: <sqpsir6tw9.fsf@cam.ac.uk>

John Q Splittist <splittist at yahoo.com> writes:

> Troels Henriksen wrote:
>
>> Well, done. Climacs now supports something like Emacs' local buffer
>> variables
>
> I started making a few changes to the parsing part of this that ended
> up being a bit bigger than I intended, so apologies if you think I've
> gone too far.
>
> One thing that would be nice is to be able to do a Set Option (and
> View Option) [or ... Attribute], which would query the relevant Syntax
> about what options could be set, and what their current values
> were. (And it might be nice if it kept the list of all options,
> whether understood or not.)
>
> (Zmacs also had Update Attribute List, which would rewrite your -*-
> line for you...)

I don't exactly know what you're discussing here, but the lute
tablature editor that we have has something much like buffer-local
variables; pardon the syntax, but the top of a tabcode file looks much like

{<rules>
   <notation>italian</notation>
   <tuning>...</tuning>
 </rules>}

(where {...} introduces a tabcode comment).  What we do, which I think
is nice, is arrange for this to be part of the buffer syntax: it's
parsed and updated along with everything else.  This allows for the
cool demo of editing the "italian" in the above snippet to read
"french", and as the last character is typed to watch the rendered
tablature window change its notation completely.

Cheers,

Christophe


From strandh at labri.fr  Sat May  6 18:09:13 2006
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 6 May 2006 20:09:13 +0200
Subject: [climacs-devel] the buffer modification protocol
Message-ID: <17500.58953.109920.42165@serveur5.labri.fr>

After some thinking (and some sleep) I know think the
buffer-modification protocol was a mistake and that I got it right in
Gsharp.  

The reason I think it was a mistake is that several independent
"clients" might want to keep independent information of what part of
the buffer has been modified since "last time" (a concept that depends
on the view) the client was invoked and of what needs to be done to
update this information.

What Gsharp does (Gilbert Baumann made this happen) is that each
client programmatically adds a mixin class to the buffer, and then
adds :after methods on that mixin class for the generic functions that
update the buffer.  Thus there can be many independent clients, and
each client can independently capture buffer modifications.  

The mechanism that makes this work is that an :around method is
defined on clim-mop:ensure-class-using-class so that whenever the
class (the buffer in this case) is defined or altered, the "stealth"
mixin classes are added in.  I must say, I have not had a single
problem with this mechanism over the years I have worked on Gsharp,
and it is a great tool for preserving modularity. 

Comments?
-- 
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 nikodemus at random-state.net  Sun May  7 12:17:38 2006
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sun, 07 May 2006 15:17:38 +0300
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <17499.55512.908145.594858@serveur5.labri.fr> (Robert Strandh's
	message of "Sat, 6 May 2006 00:59:36 +0200")
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<17499.42212.679910.245309@serveur5.labri.fr>
	<squ0846s6b.fsf@cam.ac.uk>
	<17499.55512.908145.594858@serveur5.labri.fr>
Message-ID: <873bfmt4f1.fsf@logxor.random-state.net>

Robert Strandh <strandh at labri.fr> writes:

> I would prefer that this case be handled by having the commands that
> require the syntax to be up to date explicitly call whatever function
> updates the syntax.

I'm not following Climacs too closely, so sorry for butting in, but...

Why on earth? Isn't that the classic recipe for commands that only work
under magic assumptions, and duplicating work?

I'm obviously missing something here.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."


From csr21 at cam.ac.uk  Sun May  7 17:53:20 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sun, 07 May 2006 18:53:20 +0100
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <873bfmt4f1.fsf@logxor.random-state.net> (Nikodemus Siivola's
	message of "Sun, 07 May 2006 15:17:38 +0300")
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<17499.42212.679910.245309@serveur5.labri.fr>
	<squ0846s6b.fsf@cam.ac.uk>
	<17499.55512.908145.594858@serveur5.labri.fr>
	<873bfmt4f1.fsf@logxor.random-state.net>
Message-ID: <sqac9t4t7z.fsf@cam.ac.uk>

Nikodemus Siivola <nikodemus at random-state.net> writes:

> Robert Strandh <strandh at labri.fr> writes:
>
>> I would prefer that this case be handled by having the commands that
>> require the syntax to be up to date explicitly call whatever function
>> updates the syntax.
>
> I'm not following Climacs too closely, so sorry for butting in, but...
>
> Why on earth? Isn't that the classic recipe for commands that only work
> under magic assumptions, and duplicating work?
>
> I'm obviously missing something here.

Whether or not you're missing something, there are multiple clients
for an up to date syntax, and they have different needs; we start from
the observation that doing a complete parse of the entire buffer at
every keystroke (or even more often: again, consider keyboard macros)
is not acceptable in terms of performance for arbitrary grammar.
Therefore, there cannot be a general automagic system that ensures
that the syntax is sufficiently up to date for a given command to
operate correctly.  (Stop me there if there's something you want to
disagree with).

Since only each individual client of a syntax knows how much of the
syntax needs to be up to date (and there we will need to extend the
current support, so that it is reasonable to say "please update the
syntax until you find the end of this top-level form" or similar), the
logical place to put the calls to extend the up-to-date syntax region
is where they're needed.

Cheers,

Christophe


From nikodemus at random-state.net  Sun May  7 21:38:19 2006
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 08 May 2006 00:38:19 +0300
Subject: [climacs-devel] keyboard macros, display protocol
In-Reply-To: <sqac9t4t7z.fsf@cam.ac.uk> (Christophe Rhodes's message of "Sun,
	07 May 2006 18:53:20 +0100")
References: <sqvesmdpp9.fsf@cam.ac.uk>
	<17499.42212.679910.245309@serveur5.labri.fr>
	<squ0846s6b.fsf@cam.ac.uk>
	<17499.55512.908145.594858@serveur5.labri.fr>
	<873bfmt4f1.fsf@logxor.random-state.net> <sqac9t4t7z.fsf@cam.ac.uk>
Message-ID: <87slnlfrck.fsf@logxor.random-state.net>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Whether or not you're missing something, there are multiple clients
> for an up to date syntax, and they have different needs; we start from
> the observation that doing a complete parse of the entire buffer at
> every keystroke (or even more often: again, consider keyboard macros)
> is not acceptable in terms of performance for arbitrary grammar.
> Therefore, there cannot be a general automagic system that ensures
> that the syntax is sufficiently up to date for a given command to
> operate correctly.  (Stop me there if there's something you want to
> disagree with).

No disagreement, just couple of questions:

1. Can there be a magic mechanism to answer questions like "does X have
   an up to date syntax?", where X is a semi-arbitrary position indicator,
   including things like line J, column K, and "end of current toplevel
   form"? 

   I'm sort of assuming that this is not a reasonable thing to have (or
   at least not something you'd want to invoke continuously), but I've
   no idea really.

2. What is a "client" here? (a) Is part of the syntax that answers queries about
   the syntax a client? (b) Is a function that uses these queries in order to
   implement some syntax-aware motion a client? (c) Is a command that uses that
   function a client? (d) Is a mode that includes that command a client?

> Since only each individual client of a syntax knows how much of the
> syntax needs to be up to date (and there we will need to extend the
> current support, so that it is reasonable to say "please update the
> syntax until you find the end of this top-level form" or similar), the
> logical place to put the calls to extend the up-to-date syntax region
> is where they're needed.

What I'm getting at here is, that is it unreasonable to have the parts
that answer questions like "where is the end of this top-level form?"
take care of also updating the syntax so that they can give the
correct answer?

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."


From campbell at mumble.net  Mon May  8 02:26:36 2006
From: campbell at mumble.net (Taylor R. Campbell)
Date: Mon, 8 May 2006 02:26:36 +0000
Subject: [climacs-devel] paredit.lisp, regularization of motion commands,
	and more
Message-ID: <20060508022636.8A0909800B@pluto.mumble.net>

I started working yesterday on a paredit.lisp for Climacs.  This is
the first time I've ever looked very deeply into it, and I've
encountered a number of small issues which I discussed briefly on IRC.
The most prominent of these is the irregularity of the motion
functions and commands, such as FORWARD-EXPRESSION; there are a few
other minor things, too.

Right now, there's a bit of a hodgepodge of motion commands, scattered
throughout different packages, with different parameter conventions
and such.  Some accept a syntax instance parameter; some accept a
parameter for the number of motions; none, I think, actually accept
both.  Some examples are:

  (CLIMACS-BUFFER:FORWARD-OBJECT <mark> &OPTIONAL <count>)   [generic]
  (CLIMACS-BASE:FORWARD-WORD <mark> &OPTIONAL <count>)      [function]
  (CLIMACS-SYNTAX:FORWARD-EXPRESSION <mark> <syntax>)        [generic]

Based on Edwin, MIT Scheme's Emacs clone, I've thrown together a much
more regular pattern for these operations and couple macros for
automatically generating generic functions of the signature

  (<mark> <syntax> &OPTIONAL <count> <limit-action>),

where the <limit-action> specifies what to do if the motion cannot
proceed due to the buffer or other limit.  For more details, see
<http://mumble.net/~campbell/tmp/motion.lisp>, which is a collection
of what I have started to build into the rest of Climacs locally.

Another problem fixed in motion.lisp is that UP-LIST (there called
FORWARD-UP) doesn't work correctly if it is at the limit of the
enclosing list, since it will take the parent of *that* list and go to
its end offset.  The fix in motion.lisp is rudimentary, and it ought
to be done better, but it works for the purposes of paredit.lisp, the
first two operations of which (Open Parenthesis and Close Parenthesis)
I got working last night after my initial foray into Climacs.

In order to implement these, I also wanted to use several functions
whose symbols are only internal to CLIMACS-BASE and CLIMACS-GUI.  Is
there any reason that these are not exported?

  CLIMACS-GUI::BACK-TO-INDENTATION
  CLIMACS-GUI::DELETE-INDENTATION
  CLIMACS-GUI::INDENT-CURRENT-LINE
  CLIMACS-GUI::CURRENT-POINT              (These two are unnecessary,
  CLIMACS-GUI::CURRENT-BUFFER              but convenient.)
  CLIMACS-BASE::FORWARD-TO-WORD-BOUNDARY  (Motion.lisp uses these two,
  CLIMACS-BASE::BACKWARD-TO-WORD-BOUNDARY  not paredit.lisp.)

The last two, and the current definitions of FORWARD-WORD &
BACKWARD-WORD, also posed a bit of an annoyance as I was using
Climacs: they skip over hyphens, because hyphens are constituents in
the sense of CLIMACS-BASE:CONSTITUENTP, which is really a predicate
for written Lisp symbols.  Would it not make more sense to have
several generic functions that take objects from buffers and syntax
instances to classify the objects?  I'm thinking:

  WORD-CONSTITUENT-P
  SYMBOL-CONSTITUENT-P
  LEFT-BRACKET-P
  RIGHT-BRACKET-P
  MATCHING-BRACKET

Any thoughts & comments on any of these ideas?  (Give me another week
to hack and I can have patches to implement these within Climacs's
source rather than in my ephemeral Emacs buffers.)


From splittist at yahoo.com  Mon May  8 15:12:03 2006
From: splittist at yahoo.com (John Q Splittist)
Date: Mon, 8 May 2006 15:12:03 +0000 (UTC)
Subject: [climacs-devel] Re: paredit.lisp, regularization of motion
	commands,	and more
References: <20060508022636.8A0909800B@pluto.mumble.net>
Message-ID: <loom.20060508T164618-272@post.gmane.org>

Taylor R. Campbell <campbell <at> mumble.net> writes:
 
> I started working yesterday on a paredit.lisp for Climacs.

Hooray!

> Right now, there's a bit of a hodgepodge of motion commands

I think consistency is a great idea, and including the syntax in the signature 
is a win.

I wonder whether it would be more useful for the functions (and quite possibly 
the commands) to return MARK on success, rather than T.

> In order to implement these, I also wanted to use several functions
> whose symbols are only internal to CLIMACS-BASE and CLIMACS-GUI.  Is
> there any reason that these are not exported?

In the case of CLIMACS-GUI, only because it's never really had any clients 
before. (That's why I split Swine into swine.lisp in the LISP-SYNTAX package 
and swine-commands.lisp in the CLIMACS-GUI package; it was a quick hack.)

> Would it not make more sense to have
> several generic functions that take objects from buffers and syntax
> instances to classify the objects?  I'm thinking:
> 
>   WORD-CONSTITUENT-P
>   ...

I'd hate for this kind of thing to turn into the monster that is emacs syntax-
tables just to save a bit of typing from having to reimplement the word motion 
commands in syntaxes with a different idea of what amounts to a constituent or 
a bracket. The word motion commands in basic syntax should obviously use 
an 'English' notion of what amounts to a constituent. I would then prefer that 
lisp-syntax implement a method that uses the lisp notion of constituent etc. I 
would favour this strategy over one that tried to create a super-generalised 
word motion function that depended on the method equivalent of regular 
expressions to come up with the actual movement for a syntax. (But that's just 
me.)

Cheers,
JQS (v. much looking forward to paredit for climacs)






From campbell at mumble.net  Mon May  8 16:25:36 2006
From: campbell at mumble.net (Taylor R. Campbell)
Date: Mon, 8 May 2006 16:25:36 +0000
Subject: [climacs-devel] Re: paredit.lisp, regularization of motion
	commands,	and more
In-Reply-To: <loom.20060508T164618-272@post.gmane.org> (splittist@yahoo.com)
Message-ID: <20060508162536.F03D79800A@pluto.mumble.net>

   Date: Mon, 8 May 2006 15:12:03 +0000 (UTC)
   From: John Q Splittist <splittist at yahoo.com>

   Taylor R. Campbell <campbell <at> mumble.net> writes:

   > Right now, there's a bit of a hodgepodge of motion commands

   I think consistency is a great idea, and including the syntax in
   the signature is a win.

   I wonder whether it would be more useful for the functions (and
   quite possibly the commands) to return MARK on success, rather than
   T.

Any particular reason?  Usually you'll already have the mark anyway;
for those cases where you don't, the difference is between

  (LET ((MARK (COMPUTE-MARK-HAIRILY))
    (COND ((FORWARD-FROB MARK SYNTAX 1 NIL) ...)
          ...))

and

  (LET ((MARK (FORWARD-FROB (COMPUTE-MARK-HAIRILY) SYNTAX 1 NIL)))
    (COND (MARK ...)
          ...)),

except that the latter is less general, since it doesn't allow
references to the mark if the motion failed, so you'd have to go for
something longer or something identical to my current suggested idiom.

   > In order to implement these, I also wanted to use several functions
   > whose symbols are only internal to CLIMACS-BASE and CLIMACS-GUI.  Is
   > there any reason that these are not exported?

   In the case of CLIMACS-GUI, only because it's never really had any
   clients before. (That's why I split Swine into swine.lisp in the
   LISP-SYNTAX package and swine-commands.lisp in the CLIMACS-GUI
   package; it was a quick hack.)

So would you recommend just exporting (most of) them, then?

   > Would it not make more sense to have
   > several generic functions that take objects from buffers and syntax
   > instances to classify the objects?  I'm thinking:
   > 
   >   WORD-CONSTITUENT-P
   >   ...

   I'd hate for this kind of thing to turn into the monster that is
   emacs syntax-tables just to save a bit of typing from having to
   reimplement the word motion commands in syntaxes with a different
   idea of what amounts to a constituent or a bracket.

Well, one property of GNU Emacs that I find to be very nice is that
all these motion commands work everywhere, with special meaning only
where appropriate (e.g., expression motion in Lisp).  It would be nice
to provide this property in Climacs, too, by reasonable defaults, I
think.

   The word motion commands in basic syntax should obviously use an
   'English' notion of what amounts to a constituent. I would then
   prefer that lisp-syntax implement a method that uses the lisp
   notion of constituent etc.

Actually, I disagree here.  While some highly syntax-specific
operations, such as the incremental parser should of course look at
the Lisp (or Prolog, or whatever) meaning of constituents, I still
want word commands to use English word constituents -- I frequently
operate on words within identifiers separated by hyphens, for example,
which is what made me think of this in the first place.

   I would favour this strategy over one that tried to create a
   super-generalised word motion function that depended on the method
   equivalent of regular expressions to come up with the actual
   movement for a syntax. (But that's just me.)

While one always can specialize on FORWARD-ONE-WORD and FORWARD-WORD,
I think it would be simpler to provide a default method that used a
simpler generic function such as WORD-CONSTITUENT-P.  Then, if the
meaning of `word constituent' is different in some syntax, but not the
meaning of `word' as a whole or motion over words, that syntax can
specialize WORD-CONSTITUENT-P without having to duplicate an entire
FORWARD-ONE-WORD method that differs only by the predicate of word
constituents.

As for brackets, I actually want something a bit higher-level, which I
need to think harder about.


From csr21 at cam.ac.uk  Tue May  9 17:16:30 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 09 May 2006 18:16:30 +0100
Subject: [climacs-devel] Re: Climacs - self documenting editor?
In-Reply-To: <sqaca8ifma.fsf@cam.ac.uk> (Christophe Rhodes's message of "Wed, 
	26 Apr 2006 15:19:25 +0100")
References: <87lktu94wx.fsf@sigkill.dk> <sqirowisl1.fsf@cam.ac.uk>
	<sqejzkiqlm.fsf@cam.ac.uk> <loom.20060426T153604-274@post.gmane.org>
	<sqaca8ifma.fsf@cam.ac.uk>
Message-ID: <sqr7336rv5.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> The good news is that the changes to climacs (and other application)
> commands can be made incrementally; the changes to ESA are backwards
> compatible.  (The bad news is that all of this is blocked on a problem
> in its interaction with goatee in mcclim itself... If you want to play
> with these patches, add NIL to the call to erase-output-record in the
> method on climi::finalize in mcclim/Goatee/editing-stream.lisp)

I've worked around, I think, the problems in Goatee.  I attach a patch
against ESA implementing

* esa-command-parser and esa-partial-command-parser functions
  ** call accept for the constituent parts (command-name, arguments) on 
     the encapsulated stream

* modified stream-accept/accept-1 for the minibuffer, to support above
  ** turn off the input sensitizer for the stream.

These two parts are currently coupled, in that you don't get good
behaviour for the command parser without the modified accept machinery
for the minibuffer.  (And indeed the command parser assumes that it's
running on the minibuffer; I don't know whether that makes sense, or
what one could do to generalize it.)

Oh, the bonus code this time

* make numeric arguments and keyboard macros play nice together.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: esa.diff
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20060509/050b17c0/attachment.ksh>
-------------- next part --------------

Please test, review, post feedback, suggest how to couple these things
less tightly...

Cheers,

Christophe

From athas at sigkill.dk  Thu May 11 18:34:46 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 11 May 2006 20:34:46 +0200
Subject: [climacs-devel] (Patch included) Recognition of literal cons-cells
 in the Lisp syntax module
Message-ID: <87r7308l6h.fsf@sigkill.dk>

I have been hacking a bit at the Lisp syntax module and tried to
understand how it works (not easy given the lack of comments), but I
think I've gotten a general hang of it. My reason for doing so is
that the syntax module does not recognize literal cons cells (eg. (1
. 2)), parsing them as complete-list-forms. The attached patch makes
the syntax module recognize cons cells, but because I'm not sure I've
done this properly, I'm going to post it here for discussion and
criticism before I commit anything.

Comments?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cons-cells.patch
Type: text/x-patch
Size: 2819 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20060511/58338139/attachment.bin>
-------------- next part --------------

(I know `lex-token' is becoming very ugly, but from looking at other
definitions of token lexing functions, I am led to believe that
uglyness is almost a necessity.)

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature

From athas at sigkill.dk  Thu May 11 19:03:08 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 11 May 2006 21:03:08 +0200
Subject: [climacs-devel] (Patch included) Recognition of literal
	cons-cells in the Lisp syntax module
In-Reply-To: <87r7308l6h.fsf@sigkill.dk> (Troels Henriksen's message of
	"Thu, 11 May 2006 20:34:46 +0200")
References: <87r7308l6h.fsf@sigkill.dk>
Message-ID: <87lkt88jv7.fsf@sigkill.dk>

Troels Henriksen <athas at sigkill.dk> writes:

> The attached patch makes the syntax module recognize cons cells

It seems that I was a bit too quick to post - after applying that
patch, put the following class definition somewhere in
lisp-syntax.lisp:

(defclass dot-lexeme (lisp-lexeme) ())
-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From athas at sigkill.dk  Tue May 16 21:53:55 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 16 May 2006 23:53:55 +0200
Subject: [climacs-devel] Neat hack exploiting `token-to-object' and CLIM
	presentation types.
Message-ID: <87zmhhd4b0.fsf@sigkill.dk>

The following hack will wrap each display of a form-token in Lisp
syntax in a `with-output-as-presentation' form that `present's it as
an expression. Also, it will define a presentation translator, so a
single click enables evaluation of the form:

(in-package :climacs-lisp-syntax)

(defmethod display-parse-tree :around ((parse-symbol form) syntax pane)
  (let ((obj (token-to-object syntax parse-symbol :no-error t)))
    (if obj
        (with-output-as-presentation (pane obj 'expression)
          (call-next-method))
        (call-next-method))))

(define-presentation-to-command-translator evaluate-expression
    (expression climacs-gui::com-eval-expression lisp-table)
    (object)
    (list object nil))

This hack is obviously quite inefficient, but I think something like
this, ie. presenting the contents of Lisp buffers as true objects, has
potential. Do you think it is a good idea? If so, how should it be
implemented?

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From splittist at yahoo.com  Mon May 22 13:17:42 2006
From: splittist at yahoo.com (John Q Splittist)
Date: Mon, 22 May 2006 13:17:42 +0000 (UTC)
Subject: [climacs-devel] Re: Climacs - self documenting editor?
References: <87lktu94wx.fsf@sigkill.dk>
Message-ID: <loom.20060522T150948-846@post.gmane.org>

Troels Henriksen <athas <at> sigkill.dk> wrote:

> Climacs is severely lacking in the self-documenting aspect of The
> Emacs Way.

And now it isn't. (Severely lacking, that is.)

One thing that would be nice to add to the Describe Command/Describe Key 
output would be a link to the source file that defines the relevant command - 
clicking on that (a general cross-reference presentation type?) would visit 
the relevant file/switch to the relevant buffer, and put point at the logical 
place. 

Thoughts on the best way to do this? One possibility is to rely on the general 
source-tracking facilities of lisp implementations (as abstracted by Swank?); 
another would be to explicitly add the information to the relevant symbol (COM-
FOO-BAR) when compiling and then search.

JQS





From athas at sigkill.dk  Mon May 22 15:49:20 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 22 May 2006 17:49:20 +0200
Subject: [climacs-devel] Re: Climacs - self documenting editor?
In-Reply-To: <loom.20060522T150948-846@post.gmane.org> (John Q. Splittist's
	message of "Mon, 22 May 2006 13:17:42 +0000 (UTC)")
References: <87lktu94wx.fsf@sigkill.dk>
	<loom.20060522T150948-846@post.gmane.org>
Message-ID: <87bqtqjbzz.fsf@sigkill.dk>

John Q Splittist <splittist at yahoo.com> writes:

> One thing that would be nice to add to the Describe Command/Describe
> Key
> output would be a link to the source file that defines the relevant
> command -
> clicking on that (a general cross-reference presentation type?) would
> visit
> the relevant file/switch to the relevant buffer, and put point at the
> logical
> place. 

This already partly works, I think. Just load Swine (from
CLIM-desktop) and, when displaying documentation for a command, you
should be able to click on the name of the function called by the
command, to go to the definition of the command.

Is this what you mean?

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From splittist at yahoo.com  Mon May 22 15:54:57 2006
From: splittist at yahoo.com (John Q)
Date: Mon, 22 May 2006 08:54:57 -0700 (PDT)
Subject: [climacs-devel] Re: Climacs - self documenting editor?
In-Reply-To: <87bqtqjbzz.fsf@sigkill.dk>
Message-ID: <20060522155458.9369.qmail@web33512.mail.mud.yahoo.com>

--- Troels Henriksen <athas at sigkill.dk> wrote:

> John Q Splittist <splittist at yahoo.com> writes:
> 
> > One thing that would be nice to add to the
> Describe Command/Describe
> > Key
> > output would be a link to the source file

> This already partly works, I think. Just load
Swine...
> Is this what you mean?

Exactly, yes (:

JQS

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From athas at sigkill.dk  Mon May 22 20:02:59 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 22 May 2006 22:02:59 +0200
Subject: [climacs-devel] Re: Climacs - self documenting editor?
In-Reply-To: <20060522155458.9369.qmail@web33512.mail.mud.yahoo.com> (John
	Q.'s message of "Mon, 22 May 2006 08:54:57 -0700 (PDT)")
References: <20060522155458.9369.qmail@web33512.mail.mud.yahoo.com>
Message-ID: <87lkstj098.fsf@sigkill.dk>

John Q <splittist at yahoo.com> writes:

> --- Troels Henriksen <athas at sigkill.dk> wrote:
>> Is this what you mean?
>
> Exactly, yes (:

Also note that you can click on symbols in Lisp buffers - in fact,
anything presented with the `symbol' presentation type inside Climacs
will be hyperlinked to its definition. Unfortunately, this does not
extend to other applications - what I would like is for everything
presented as a `symbol', in any CLIM application, to be hyperlinked to
its definition in Climacs. However, this would probably require
modification of a global command table - I think (Mc)CLIM has one of
these, but is it considered poor style to do add new commands to it?
And if yes, how should this kind of integration be done? (I would also
like to add global commands for editing properly presented classes,
command names, functions, etc, so it's more interesting than just a
fancy form of Meta-point.)

Of course, these things are more related to CLIM-Desktop than Climacs,
but since we all pretty much agree that Swine should be moved to
Climacs at some point, I think it fits on this list as well.

-- 
\  Troels "Athas" Henriksen
/\ - Insert witty signature


From tuchol at gmail.com  Mon May 29 10:22:41 2006
From: tuchol at gmail.com (Boris Tschirschwitz)
Date: Mon, 29 May 2006 12:22:41 +0200
Subject: [climacs-devel] dvi display in Climacs
Message-ID: <651881340605290322l19657657j13a795675a94cf38@mail.gmail.com>

Hi.

I'm--as probably most Lisp fans writing lots of LaTeX--toying with
that idea of having a better live preview of TeX in my editor.
I think that the pytex tex demon might make it possible to do a much
better job than preview.
For me this is mostly about writing math, but I could also see this as
being useful for literate programming, which is for my taste just too
ugly in the  editor.

Could you provide me with a few pointers into McCLIM and Climacs about
how to get them to use dvi or pdf in a  text stream?

Thanks,
Tucho.