bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#43489: [PATCH] Don't signal scan-error when moving by sexp interacti


From: Mattias Engdegård
Subject: bug#43489: [PATCH] Don't signal scan-error when moving by sexp interactively
Date: Fri, 18 Sep 2020 17:13:18 +0200

18 sep. 2020 kl. 15.13 skrev Lars Ingebrigtsen <larsi@gnus.org>:

First of all, thanks for looking at the patch!

> So you basically just `ding' in interactive usage?

Right. I probably owe you a deeper explanation! Please bear with me for a 
moment.

It would be acceptable to replace the dings with (user-error "appropriate 
message"); it would still be an improvement. However:

I'm a firm believer in positive design. Features should be motivated by their 
actual value rather than habit or tradition. From the user's point of view, it 
is not an error when the cursor refuses to move beyond its bounds. No other 
editor (except one) displays a message in these cases, and many don't even 
beep. The only exception I've found is ed, which should delight everybody.

These messages don't make the editor easier to use in any way; it is crystal 
clear what the reason is when the cursor doesn't move at the edge of the {line, 
buffer, sexp, list, ...}. I'd say the contrary: they are nuisance messages that 
obscure the echo area, clutter the *Messages* buffer, and needlessly cause 
distractive movement in the visual periphery (a big no-no for any serious 
industrial UI designer).

In fact, several of the commands in question don't even beep at the boundaries 
in some cases: for example, C-M-f after the last sexp of the buffer jumps to 
end-of-buffer and silently stays there. Should we add noise messages for such 
cases? Surely not.

In other words: I'm not strongly against messages instead of dings if that is 
the condition for applying the patch, but would like to hear the benefit of 
those messages argued positively.

There, I'm better now. And here's a hot cuppa, lovely.

> I wonder whether this would have any negative effect when people are
> using these commands in keyboard macros.  For instance, if you've
> recorded a macro that does `M-C-f M-DEL' or something, previously it
> would signal an error and then stop, while now it'll just continue and
> delete the wrong thing?

Actually, (ding) interrupts keyboard macros, so this does work.






reply via email to

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