emacs-devel
[Top][All Lists]
Advanced

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

Re: Please, Restore Previous Behavior for jump-to-register


From: Daniel Colascione
Subject: Re: Please, Restore Previous Behavior for jump-to-register
Date: Sun, 10 Dec 2023 11:26:39 -0500
User-agent: mu4e 1.11.14; emacs 30.0.50

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eduardo Ochs <eduardoochs@gmail.com>
>> Date: Sun, 10 Dec 2023 09:34:32 -0300
>> Cc: Andreas Schwab <schwab@linux-m68k.org>, thievol@posteo.net,
>>  raman@google.com, 
>>  eller.helmut@gmail.com, tino.calancha@gmail.com, emacs-devel@gnu.org
>> 
>>   1) please introduce variables that would let us use the old behavior
>>      - the one without any RETs,
>
> Which situations currently require a RET when register-use-preview is
> set to 'never'?  You have shown one of them, but are there others, or
> is that the only one that needs to be solved for this item to be
> fulfilled?
>
>>   2) please write the functions in a way in which it would be easy -
>>      either with a bit of Lisp or with none - to define four key
>>      sequences, one for point-to-register-with-RETs, one for
>>      point-to-register-without-RETs, one for
>>      jump-to-register-with-RETs and one for
>>      jump-to-register-without-RETs,
>
> Why do you need separate functions?  Would a user option that allows
> to choose either with or without RET be enough?  If not, why not?
>
>>   3) add a few sentences to the docstrings of point-to-register and
>>      jump-to-register to explain that the old behavior was without any
>>      RETs - but with `?' showing previews - and some people prefer
>>      that way, and to configure the behavior see that variables such
>>      and such and the functions such and such. That would make
>>      everything easy to discover
>
> We will revisit the documentation once the code is in its final shape.

I have to concur with all the people decrying the new behavior.  I don't
understand why one would want to add friction to this core interaction.
I strongly prefer editing fluidity over any kind of preview mechanism.
Please keep the traditional behavior.



reply via email to

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