[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: last-sexp-toggle-display

From: Luc Teirlinck
Subject: Re: last-sexp-toggle-display
Date: Mon, 11 Aug 2003 12:59:36 -0500 (CDT)

Richard Stallman wrote:

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

That will improve the situation by making things more predictable.

       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

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.

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

(make-list 20 'a)
(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':
(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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]