last-sexp-toggle-display

last-sexp-toggle-display

[Ben North]

I came across two problems with `last-sexp-toggle-display':

1) Replaces wrong text if called when point before first
   character of togglable text, and a previous block of
   togglable text exists in the buffer.

To reproduce:

Start up fresh "emacs -q".  In *scratch*, type

(make-list 20 'a)[C-j]
(make-list 20 'b)[C-j]

You now should be looking at

(make-list 20 'a)
(a a a a a a a a a a a a ...)
(make-list 20 'b)
(b b b b b b b b b b b b ...)
-!-

Press C-p to move to "(" at start of "b" list:

(make-list 20 'a)
(a a a a a a a a a a a a ...)
(make-list 20 'b)
-!-(b b b b b b b b b b b b ...)

Press RET to call `last-sexp-toggle-display'.  You get

(make-list 20 'a)
(a a a a a a a a a a a a ...)(b b b b b b b b b -!-b b b b b b b b b b b)

which is not what you want.  This patch to CVS' lisp-mode.el
fixes this:


--- ORIG--lisp-mode.el  2003-04-04 11:10:58.000000000 +0100
+++ lisp-mode.el        2003-04-04 11:14:56.000000000 +0100
@@ -424,7 +424,9 @@
   (interactive)
   (let ((value (get-text-property (point) 'printed-value)))
     (when value
-      (let ((beg (or (previous-single-property-change (point) 'printed-value) (point)))
+      (let ((beg (or (previous-single-property-change (min (point-max) (1+ (point)))
+                                                      'printed-value)
+                     (point)))
            (end (or (next-single-char-property-change (point) 'printed-value) (point)))
            (standard-output (current-buffer))
            (point (point)))


(The `min' stuff may be unnecessary, but next problem is loosely
related.)

2) RET does nothing at (point-max) if togglable text extends to
   the very end of a buffer.

To reproduce:

In a fresh emacs, in *scratch*, type

(make-list 20 'a)[C-j]

to get

(make-list 20 'a)
(a a a a a a a a a a a a ...)
-!-

Press DEL to erase the final newline in the buffer, leaving you
with

(make-list 20 'a)
(a a a a a a a a a a a a ...)-!-

(and point at the end of the buffer).  Press RET.  Nothing
happens.

I don't have a fix for this one, but it is happening because at
the very end of a buffer, there is no character after point.
But Emacs looks up keypresses in the previous character's
`keymap' text property --- this is explicitly mentioned in
get_local_map() in intervals.c.  The previous character has a
`keymap' property mapping RET to `last-sexp-toggle-display',
which does

   (get-text-property (point) 'printed-value)

and finds nothing, because there is no character after point, so
`get-text-property' returns nil.

This inconsistency is what causes the confusion: get_local_map()
handles the case of (point-max) specially, but
`get-text-property' doesn't.  I must admit that this behaviour
of get_local_map() seems a bit strange to me, but of course I
looked at it for the first time just now so have no idea how
much code depends on this behaviour.  Perhaps somebody else can
suggest a fix to this second problem?

Thanks,

Ben.

last-sexp-toggle-display

[Richard Stallman]

What would people think of putting last-sexp-toggle-display in Lisp modes
on M-RET instead of on RET?

Re: last-sexp-toggle-display

[Luc Teirlinck]

Richard Stallman wrote:

   What would people think of putting last-sexp-toggle-display in Lisp modes
   on M-RET instead of on RET?

I believe that you are referring to local keymaps set up by
`eval-last-sexp-1', which can be produced in any mode whatsoever and
not just in Lisp modes.  These local keymaps are extremely confusing.
Some command like C-u C-x C-e produce them, whereas others such as 
C-u M-: produce identical output without the local keymap.  All
without any apparent rhyme or reason and without any way to
distinguish the two outputs other than to move one's mouse over them.
The `mouse-face' and `help-echo' text properties are only useful if
the user is using the mouse.  Maybe one should use a more "permanent"
face than `mouse-face' for regions with a local keymap.  Or maybe one
should just be a lot more reluctant to use local keymaps, especially
in ordinary buffers meant to be edited.

The proposed change would be an obvious improvement to a very bad
situation.  The current binding of RET in those local keymaps is both
extremely confusing and a real nuisance.  In Lisp interaction mode one
regularly wants to edit return values.  Also, one often wants to put a
newline in front of C-u C-x C-e output.  Clearly, basic editing
commands like RET should not be rebound using local keymaps, except in
read-only buffers.

Sincerely,

Luc.

Re: last-sexp-toggle-display

[Richard Stallman]

      These local keymaps are extremely confusing.
    Some command like C-u C-x C-e produce them, whereas others such as 
    C-u M-: produce identical output without the local keymap.

That's a bug--I will fix C-u M-:.

      All
    without any apparent rhyme or reason and without any way to
    distinguish the two outputs other than to move one's mouse over them.

Should they be given colors all the time, is that what you're
suggesting?

      Clearly, basic editing
    commands like RET should not be rebound using local keymaps, except in
    read-only buffers.

What do you think of M-RET, then?

Re: last-sexp-toggle-display

[Luc Teirlinck]

Richard Stallman wrote:

   That's a bug--I will fix C-u M-:.

That will improve the situation by making things more predictable.

	 All
       without any apparent rhyme or reason and without any way to
       distinguish the two outputs other than to move one's mouse over them.

   Should they be given colors all the time, is that what you're
   suggesting?

I believe that these regions should look clearly, but not necessarily
screamingly, different from ordinary text, because they are different
from ordinary text.  That could be different colors, different font or
whatever.  In case of a different color, this should be a customizable
face, because there are people around with all kinds of strange color
visions.  (I am one of them.  If you color it red, I barely will be
able to notice the color.  If you color it cyan, I will be able to
vaguely see the text, but not sufficiently to read it.  All of which
is no problem, as long I can customize the colors.)

	 Clearly, basic editing 
       commands like RET should not be rebound using local keymaps, except in
       read-only buffers.

   What do you think of M-RET, then?

M-RET would be a lot better.  The mouse-2 binding could still give some
confusion if people are using the mouse to yank text.

This feature should definitely be documented in the Emacs manual.  (I
do not believe it is.)

There are still bugs remaining in this feature.
 
Do:

emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &

(make-list 20 'a)
C-j
Result:
(a a a a a a a a a a a a ...)
Insert a `b':
(a b a a a a a a a a a a a ...)
Hit RET with point on the second `a':
Result:
(a b (a a a a a a a a a a a a a a a a a a a a)

If this feature can not be made to work satisfactorily with editing
the text, then I believe that the keymap should kill itself (and any
special coloring or fontification that would be associated with it)
upon editing of the text.  (That would automatically get rid of the
above bug.)  The feature is mainly useful immediately after the
original command anyway.

Sincerely,

Luc.

Re: last-sexp-toggle-display

[Richard Stallman]

    I believe that these regions should look clearly, but not necessarily
    screamingly, different from ordinary text, because they are different
    from ordinary text.  That could be different colors, different font or
    whatever.  In case of a different color, this should be a customizable
    face, because there are people around with all kinds of strange color
    visions.

Sure.

    M-RET would be a lot better.  The mouse-2 binding could still give some
    confusion if people are using the mouse to yank text.

We could take out the Mouse-2 binding if that is what people
generally want.  What do others think?

Re: last-sexp-toggle-display

[Richard Stallman]

    If this feature can not be made to work satisfactorily with editing
    the text, then I believe that the keymap should kill itself (and any
    special coloring or fontification that would be associated with it)
    upon editing of the text.

That might be a reasonable idea, but I don't think I want to try to
implement it now.

			       (That would automatically get rid of the
    above bug.)  The feature is mainly useful immediately after the
    original command anyway.

I don't agree about that.  The feature is usefu later too.