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: Bold by moving pixels problem

[Robert J. Chassell]

    .... That could be different colors, different font or whatever. ....

Speaking of fonts, has anyone permanently fixed the font problem I
reported last November?  I am still using the second patch from Miles
on 18 Dec 2002, which solves the problem for me personally.

I just checked. The font problem still exists with 

    Today's CVS snapshot, Mon, 2003 Aug 11  18:39 UTC
    GNU Emacs 21.3.50.29 (i686-pc-linux-gnu, X toolkit)

and is fixed when I patch emacs/src/xfaces.c with what Miles sent.


Miles said his second patch should not be widely used since it could
cause a race condition.  While I suffered initially, I have not
suffered any problems for several months and wonder if other changes
to the emacs/src/xfaces.c code have taken care of the potential
problem.  Or have I just been lucky?

To remind you, this is the font issue:

    Date: Wed, 20 Nov 2002 13:09:10 +0000 (UTC)
    Subject: Bold by moving pixels problem
    From: "Robert J. Chassell" <bob@rattlesnake.com>

    ... on 19 Nov 2002, mode-line-buffer-identification
    suddenly started showing buffer names in bold.

    This applies both to a plain vanilla instance of Emacs started
    with:

         /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

    and to the instance I start with a .emacs file.

    The change does not look too bad with the plain vanilla instance.

    However, there are three problems with the consequences of the
    change for instances of emacs started with my .emacs file:

      * the new bold creation technique fills in letters such as `m'
        so that they become unreadable rectangles

        I am using a `10x20' font,
            -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1
        which has been very clear for the screen I am using.

      * I cannot permanently change
            :weight bold
        to
            :weight normal
        in the variable `mode-line-buffer-identification', which is
        buffer-local.

        That is to say, when I reset the value of
        `mode-line-buffer-identification' so its face is :weight
        normal rather than :weight bold, that change is only
        temporary.  I don't know what to write in my .emacs file that
        can make a permanent global change to a variable that is
        buffer local.  If there is a method please tell me!

      * I do not know how to set the value that is associated with

            (face (:weight bold) ...

        in my .emacs.

        Put another way, evaluating the following works temporarily
        but not permanently:

            (setq
             mode-line-buffer-identification
             (quote
              (#("%14b" 0 4
                 (face
                  ;; (:weight bold)
                  (:weight normal)
                  help-echo
                  "mouse-1: other buffer, mouse-2: prev, M-mouse-2: next, mouse-3: buffer menu"
                  local-map
                  (keymap
                   (header-line keymap
                                (down-mouse-3 . mouse-buffer-menu)
                                (mouse-2 . bury-buffer)
                                (M-mouse-2 . mode-line-unbury-buffer)
                                (mouse-1 . mode-line-other-buffer))
                   (mode-line keymap
                              (down-mouse-3 . mouse-buffer-menu)
                              (mouse-2 . bury-buffer)
                              (M-mouse-2 . mode-line-unbury-buffer))))))
              ))


        On the other hand, the following produces the face that I
        specify when I evaluate it:

            (custom-set-faces
            ...
             '(bold ((t (:background "DodgerBlue4" :foreground "cyan"))))
            ...)

        How do I reset the bold characteristic of the face in
        `mode-line-buffer-identification' when it is a local variable?

We had another discussion about this in May 2003.

Miles' second patch is in this message:

    Subject: Re: Bold by moving pixels problem
    Date: 18 Dec 2002 19:01:01 +0900
    From: Miles Bader <miles@lsi.nec.co.jp>
    To: bob@rattlesnake.com
    Cc: emacs-devel@gnu.org
    Reply-To: Miles Bader <miles@gnu.org>
    In-Reply-To: <buoisxtazqu.fsf@mcspd15.ucom.lsi.nec.co.jp>

Thanks!

--
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

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.