Please, Restore Previous Behavior for jump-to-register

Please, Restore Previous Behavior for jump-to-register

[Tino Calancha]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Dear Emacs maintainers,

I am writing to express my concern about a recent change in the
behavior of the jump-to-register and point-to-register commands in the
master branch (Bug#66394).

Previously, these commands allowed users to seamlessly navigate
without the need to press the RET key every time. Unfortunately, the
recent modification has introduced a requirement to press RET with
every use, which has proven to be quite cumbersome for me.

This change has impacted my workflow to the extent that I have opted
to discontinue using the master branch.

I kindly request the restoration of the previous behavior for
jump-to-register and point-to-register commands. This adjustment would
greatly enhance usability and ensure a smoother experience for users
who have grown accustomed to the previous functionality.

Thank you
Tino

[-- Attachment #2: Type: text/html, Size: 942 bytes --]

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

[Helmut Eller]

On Thu, Dec 07 2023, Tino Calancha wrote:

> Previously, these commands allowed users to seamlessly navigate
> without the need to press the RET key every time. Unfortunately, the
> recent modification has introduced a requirement to press RET with
> every use, which has proven to be quite cumbersome for me.

I fully concur with this.  This change is driving me nuts.

Helmut

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

[Eduardo Ochs]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

+1 here - I was even planning to file a bug
report on that, but with "wishlist" severity...
I think that there should a be a variable
controlling if jump-to-register uses RETs
or not - I looked at the code and AFAICT
at this moment there isn't an easy way
to select the old behavior...



On Fri, 8 Dec 2023, 12:04 Helmut Eller, <eller.helmut@gmail.com> wrote:

> On Thu, Dec 07 2023, Tino Calancha wrote:
>
> > Previously, these commands allowed users to seamlessly navigate
> > without the need to press the RET key every time. Unfortunately, the
> > recent modification has introduced a requirement to press RET with
> > every use, which has proven to be quite cumbersome for me.
>
> I fully concur with this.  This change is driving me nuts.
>
> Helmut
>
>

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

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

[T.V Raman]

Eduardo Ochs <eduardoochs@gmail.com> writes:


1+, and rather than one more knob, I think the old behavior was perfect.> +1 here - I was even planning to file a bug
> report on that, but with "wishlist" severity...
> I think that there should a be a variable
> controlling if jump-to-register uses RETs
> or not - I looked at the code and AFAICT
> at this moment there isn't an easy way
> to select the old behavior...
>
> On Fri, 8 Dec 2023, 12:04 Helmut Eller, <eller.helmut@gmail.com>
> wrote:
>
>     On Thu, Dec 07 2023, Tino Calancha wrote:
>
>     > Previously, these commands allowed users to seamlessly navigate
>     > without the need to press the RET key every time. Unfortunately,
>     the
>     > recent modification has introduced a requirement to press RET
>     with
>     > every use, which has proven to be quite cumbersome for me.
>
>     I fully concur with this.  This change is driving me nuts.
>
>     Helmut
>

-- 

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

[Eduardo Ochs]

Just an addendum to my +1...
I think that the new behaviour is fantastic, and it is something that
I plan to teach to beginners...
but I would like to have a way to toggle between the two!
  Cheers =),
    Eduardo

On Fri, 8 Dec 2023 at 17:35, T.V Raman <raman@google.com> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
>
> 1+, and rather than one more knob, I think the old behavior was perfect.> +1 here - I was even planning to file a bug
> > report on that, but with "wishlist" severity...
> > I think that there should a be a variable
> > controlling if jump-to-register uses RETs
> > or not - I looked at the code and AFAICT
> > at this moment there isn't an easy way
> > to select the old behavior...
> >
> > On Fri, 8 Dec 2023, 12:04 Helmut Eller, <eller.helmut@gmail.com>
> > wrote:
> >
> >     On Thu, Dec 07 2023, Tino Calancha wrote:
> >
> >     > Previously, these commands allowed users to seamlessly navigate
> >     > without the need to press the RET key every time. Unfortunately,
> >     the
> >     > recent modification has introduced a requirement to press RET
> >     with
> >     > every use, which has proven to be quite cumbersome for me.
> >
> >     I fully concur with this.  This change is driving me nuts.
> >
> >     Helmut
> >
>
> --

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]


You can now have the previous behavior by customizing
`register-use-preview`.

It will be soon visible in NEWS and INFO.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[T.V Raman]

nice, thanks for all your work!

Thierry Volpiatto writes:
 > 
 > You can now have the previous behavior by customizing
 > `register-use-preview`.
 > 
 > It will be soon visible in NEWS and INFO.
 > 
 > -- 
 > Thierry
 > application/pgp-signature [Press RETURN to save to a file]

-- 

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

[Eduardo Ochs]

On Sat, 9 Dec 2023 at 03:58, Thierry Volpiatto <thievol@posteo.net> wrote:
>
> You can now have the previous behavior by customizing
> `register-use-preview`.
>
> It will be soon visible in NEWS and INFO.

Hi Thierry,

AFAICS a part of the problem still remains...
Try this in an emacs30 -q:

  (setq register-use-preview 'never)
  C-x r SPC a
  C-x r SPC a

The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
a RET to confirm. This is annoying to the people who were used to
using always the same few registers and never typing the RET...

  Thanks in advance =P,
    Edrx

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> On Sat, 9 Dec 2023 at 03:58, Thierry Volpiatto <thievol@posteo.net> wrote:
>>
>> You can now have the previous behavior by customizing
>> `register-use-preview`.
>>
>> It will be soon visible in NEWS and INFO.
>
> Hi Thierry,
>
> AFAICS a part of the problem still remains...
> Try this in an emacs30 -q:
>
>   (setq register-use-preview 'never)
>   C-x r SPC a
>   C-x r SPC a
>
> The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
> a RET to confirm.

This is the wanted behavior when you are about to overwrite a register.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Eduardo Ochs]

On Sun, 10 Dec 2023 at 02:15, Thierry Volpiatto <thievol@posteo.net> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
> > On Sat, 9 Dec 2023 at 03:58, Thierry Volpiatto <thievol@posteo.net> wrote:
> >>
> >> You can now have the previous behavior by customizing
> >> `register-use-preview`.
> >>
> >> It will be soon visible in NEWS and INFO.
> >
> > Hi Thierry,
> >
> > AFAICS a part of the problem still remains...
> > Try this in an emacs30 -q:
> >
> >   (setq register-use-preview 'never)
> >   C-x r SPC a
> >   C-x r SPC a
> >
> > The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
> > a RET to confirm.
>
> This is the wanted behavior when you are about to overwrite a register.

The old behavior is to not ask for confirmation when overwriting a
register, and some people - including me - would like to have a simple
way to make `C-x r SPC' (`point-to-register') behave in the old way...
Is there a way to do that by just setting variables?
If not, can you implement a way to do that?

  Thanks in advance (hopefully),
    Eduardo Ochs

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

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

   The old behavior is to not ask for confirmation when overwriting a
   register, and some people - including me - would like to have a simple
   way to make `C-x r SPC' (`point-to-register') behave in the old way...
   Is there a way to do that by just setting variables?
   If not, can you implement a way to do that?

More importantly, the documentation for how registers behave is out of
sync with this new behaviour.  The old behaviour should really be made
default until.


  ‘C-x r <SPC> R’
       Record the position of point and the current buffer in register R
       (‘point-to-register’).
  ‘C-x r j R’
       Jump to the position and buffer saved in register R
       (‘jump-to-register’).
  
     Typing ‘C-x r <SPC>’ (‘point-to-register’), followed by a character
  ‘R’, saves both the position of point and the current buffer in register
  R.  The register retains this information until you store something else
  in it.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: thievol@posteo.net, raman@google.com, eller.helmut@gmail.com,
>  tino.calancha@gmail.com, emacs-devel@gnu.org
> Date: Sun, 10 Dec 2023 03:28:17 -0500
> 
>    The old behavior is to not ask for confirmation when overwriting a
>    register, and some people - including me - would like to have a simple
>    way to make `C-x r SPC' (`point-to-register') behave in the old way...
>    Is there a way to do that by just setting variables?
>    If not, can you implement a way to do that?
> 
> More importantly, the documentation for how registers behave is out of
> sync with this new behaviour.

This can legitimately happen as long as the release cycle of Emacs 30
didn't start.  We don't (or cannot, really) demand that each code
change will include all the necessary updates to the manuals.  So
people who track the master branch must get used to look in NEWS for
any such changes; we don't promise that the manuals on master will be
always up-to-date.

AFAIR, Thierry plans to update the manuals later, but for now let's
leave this particular aspect out of this discussion, to avoid too many
tangents.

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

[Alfred M. Szmidt]

   So people who track the master branch must get used to look in NEWS
   for any such changes; we don't promise that the manuals on master
   will be always up-to-date.

NEWS doesn't mention the new behaviour.

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

[João Távora]

On Sun, Dec 10, 2023 at 8:28 AM Alfred M. Szmidt <ams@gnu.org> wrote:
>
>    The old behavior is to not ask for confirmation when overwriting a
>    register, and some people - including me - would like to have a simple
>    way to make `C-x r SPC' (`point-to-register') behave in the old way...
>    Is there a way to do that by just setting variables?
>    If not, can you implement a way to do that?
>
> More importantly, the documentation for how registers behave is out of
> sync with this new behaviour.  The old behaviour should really be made
> default until.

I'm hoping the old behavior stays the default and the new behaviour
is what users can opt in with a variable.

If that is what normally happens for much less disruptive changes,
why isn't it happening for this deep impacting one?

João

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 10 Dec 2023 09:37:16 +0000
> Cc: Eduardo Ochs <eduardoochs@gmail.com>, thievol@posteo.net, raman@google.com,
>  eller.helmut@gmail.com, tino.calancha@gmail.com, emacs-devel@gnu.org
> 
> I'm hoping the old behavior stays the default and the new behaviour
> is what users can opt in with a variable.
> 
> If that is what normally happens for much less disruptive changes,
> why isn't it happening for this deep impacting one?

Because the original discussion of these changes, between two people
who were interested and involved, indicated that the new behavior
makes much more sense than the old one.  Now, that others chimed in
with the opposite views, we are still discussing what should be the
behavior, and once that is concluded, we can talk about the defaults.

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

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

* 2023-12-10 05:15:49+0000, Thierry Volpiatto wrote:

> Eduardo Ochs <eduardoochs@gmail.com> writes:
>> The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
>> a RET to confirm.
>
> This is the wanted behavior when you are about to overwrite a
> register.

Not necessarily "the" wanted behavior. To me registers are a quick
temporary throw-away stores. This quickness goes partially away if I
need to confirm the action when reusing a register. I would like to have
this quickness reimplemented (as an option).

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

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

[Alfred M. Szmidt]

   [1:text/plain Hide]

   Eduardo Ochs <eduardoochs@gmail.com> writes:

   > On Sat, 9 Dec 2023 at 03:58, Thierry Volpiatto <thievol@posteo.net> wrote:
   >>
   >> You can now have the previous behavior by customizing
   >> `register-use-preview`.
   >>
   >> It will be soon visible in NEWS and INFO.
   >
   > Hi Thierry,
   >
   > AFAICS a part of the problem still remains...
   > Try this in an emacs30 -q:
   >
   >   (setq register-use-preview 'never)
   >   C-x r SPC a
   >   C-x r SPC a
   >
   > The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
   > a RET to confirm.

   This is the wanted behavior when you are about to overwrite a register.

It really is not.  The whole story of registers, since its dawn, was
to have a very quick way of setting them.  That includes overwriting
them quickly, this is specially important in keyboard macros where you
wish to record specific points to jump back and forth too ..  now, you
cannot reuse one register in a keyboard macro without having to deal
the interactive question .. which only occurs on the second invocation
of the keyboard macro.

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

[Rudolf Schlatte]

Thierry Volpiatto <thievol@posteo.net> writes:

> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
>> On Sat, 9 Dec 2023 at 03:58, Thierry Volpiatto <thievol@posteo.net> wrote:
>>>
>>> You can now have the previous behavior by customizing
>>> `register-use-preview`.
>>>
>>> It will be soon visible in NEWS and INFO.
>>
>> Hi Thierry,
>>
>> AFAICS a part of the problem still remains...
>> Try this in an emacs30 -q:
>>
>>   (setq register-use-preview 'never)
>>   C-x r SPC a
>>   C-x r SPC a
>>
>> The second `C-x r SPC a' says "[Overwrite register `a']" and asks for
>> a RET to confirm.
>
> This is the wanted behavior when you are about to overwrite a register.

Adding my voice to the choir here to say that I would very much like the
current behavior to stay (either by default or as an option I can set).
Having `point-to-register' sometimes ask for confirmation and sometimes
not would be even more disruptive to me, so the `'never' option as
described above would not help me.

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

[Andreas Schwab]

On Dez 10 2023, Thierry Volpiatto wrote:

> This is the wanted behavior when you are about to overwrite a register.

Registers are primarily ephemeral storage, thus they should be altered
easily.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Alfred M. Szmidt]

   > This is the wanted behavior when you are about to overwrite a register.

   Registers are primarily ephemeral storage, thus they should be altered
   easily.

And for non-ephemeral, we have bookmarks.  

Do people really have that many registers that they need to have a
preview on all the time?  You can already hit ? to get a list of
whatever you have when you jump-to-register if you get confused.

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

[Eduardo Ochs]

On Sun, 10 Dec 2023 at 08:30, Alfred M. Szmidt <ams@gnu.org> wrote:
>
>    > This is the wanted behavior when you are about to overwrite a register.
>
>    Registers are primarily ephemeral storage, thus they should be altered
>    easily.
>
> And for non-ephemeral, we have bookmarks.
>
> Do people really have that many registers that they need to have a
> preview on all the time?  You can already hit ? to get a list of
> whatever you have when you jump-to-register if you get confused.

Hi all,

I got used to using only one register - `a' - because I couldn't
remember more than that and I didn't know about `C-x r SPC ?'... =(

The tools for previewing registers are great and I'm probably going to
start using them at some point, but I _guess_ that for some workflows
I will still prefer the behavior without any RETs... so let me add two
points - 2 and 3 - to my wishlist:

  1) please introduce variables that would let us use the old behavior
     - the one without any RETs,

  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,

  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

  Cheers, many thanks for these features, and probably thanks in
  advance =),
    Eduardo Ochs
    http://anggtwu.net/eepitch.html


P.S.: what was the thread in which the new behavior was discussed? I
missed it completely, sorry...

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

[Eli Zaretskii]

> 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.

Thanks.

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

[Daniel Colascione]

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.

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

> Which situations currently require a RET when register-use-preview is
> set to 'never'?

The only situations are when you overwrite a register or when you modify
it (increment etc..), this with the three options register-use-preview
propose.

I think it is important to have a kind of warning and confirm when doing
so.  I have personally often overwrited registers I was working with
inadvertantly.

After reading the complaints here, I have the impressions most of those
people had build a workflow based on really few registers because it was
hard with previous UI to figure out which one to use.

Now when you set a new register you can use M-n and there it will set
the register without the need to press RET.

I think the current behavior is sane, specially for new users - it is
really surprizing that when hitting "a" for example there is no
confirmation at all -, so I think the default for register-use-preview
should be `t`.

If needed I can disable RET easily for register overwrite as well, this
for the two remaining options of register-use-preview (nil and 'never)
but I think it would be an error.

Eli let me know what you think is the best option.

Thanks.

> We will revisit the documentation once the code is in its final shape.

Exactly.

PS: I remind people here that they are using the development branch of
Emacs where "Work in progress" among other things can happen, so please
be patient.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Rudolf Schlatte]

Thierry Volpiatto <thievol@posteo.net> writes:

> After reading the complaints here, I have the impressions most of those
> people had build a workflow based on really few registers because it was
> hard with previous UI to figure out which one to use.

[...]

> If needed I can disable RET easily for register overwrite as well, this
> for the two remaining options of register-use-preview (nil and 'never)
> but I think it would be an error.

Thank you in advance for this willingness to consider different users'
needs, even when you think them misguided.  I can empathize that it can
be hard to introduce a feature in good faith and then discover it's
disliked by many vocal users ...

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

Thierry Volpiatto <thievol@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Which situations currently require a RET when register-use-preview is
>> set to 'never'?
>
> The only situations are when you overwrite a register or when you modify
> it (increment etc..), this with the three options register-use-preview
> propose.
>
> I think it is important to have a kind of warning and confirm when doing
> so.  I have personally often overwrited registers I was working with
> inadvertantly.
>
> After reading the complaints here, I have the impressions most of those
> people had build a workflow based on really few registers because it was
> hard with previous UI to figure out which one to use.
>
> Now when you set a new register you can use M-n and there it will set
> the register without the need to press RET.
>
> I think the current behavior is sane, specially for new users - it is
> really surprizing that when hitting "a" for example there is no
> confirmation at all -, so I think the default for register-use-preview
> should be `t`.
>
> If needed I can disable RET easily for register overwrite as well, this
> for the two remaining options of register-use-preview (nil and 'never)
> but I think it would be an error.
>
> Eli let me know what you think is the best option.
>
> Thanks.

Note also that in addition to register-use-preview setting, one can use

    (cl-defmethod register-preview-command-info ((_command (eql copy-to-register)))
      (make-register-preview-info
       :types '(string number)
       :msg "Set register `%s'"))

to have the wanted behavior (no RET when overwriting) for
copy-to-register command.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Thierry Volpiatto <thievol@posteo.net> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:

> Note also that in addition to register-use-preview setting, one can use
>
>     (cl-defmethod register-preview-command-info ((_command (eql copy-to-register)))
>       (make-register-preview-info
>        :types '(string number)
>        :msg "Set register `%s'"))
>
> to have the wanted behavior (no RET when overwriting) for
> copy-to-register command.

Sorry, it is register-command-info, not register-preview-command-info.

Even better the customization can be make only when for example
register-use-preview is nil with:

    (cl-defmethod register-command-info ((_command (eql copy-to-register))
                                         &context (register-use-preview (eql nil)))
      (make-register-preview-info
       :types '(string number)
       :msg "Set register `%s'"))

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[João Távora]

On Sun, Dec 10, 2023 at 4:57 PM Thierry Volpiatto <thievol@posteo.net> wrote:

> PS: I remind people here that they are using the development branch of
> Emacs where "Work in progress" among other things can happen, so please
> be patient.

Fair, but consider that many among us use master as their daily driver,
especially when developing for Emacs itself, so for changes with such
strong impact on users' muscle memory, it is much better IMO to work
off a branch.  Unless you were intentionally probing for feedback, in
which case I think you got it :-)

João

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

[T.V Raman]

Also, when this ships and surprizes users, how  do we expect those
users to discover this use-preview knob; even if I found that knob,
I'd never guess that it waas the means of getting rid of the newly
introduced friction, ie need to press the enter key.


João Távora writes:
 > On Sun, Dec 10, 2023 at 4:57 PM Thierry Volpiatto <thievol@posteo.net> wrote:
 > 
 > > PS: I remind people here that they are using the development branch of
 > > Emacs where "Work in progress" among other things can happen, so please
 > > be patient.
 > 
 > Fair, but consider that many among us use master as their daily driver,
 > especially when developing for Emacs itself, so for changes with such
 > strong impact on users' muscle memory, it is much better IMO to work
 > off a branch.  Unless you were intentionally probing for feedback, in
 > which case I think you got it :-)
 > 
 > João

-- 

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

[João Távora]

On Sun, Dec 10, 2023 at 7:44 PM T.V Raman <raman@google.com> wrote:
>
>
> Also, when this ships and surprizes users, how  do we expect those
> users to discover this use-preview knob; even if I found that knob,
> I'd never guess that it waas the means of getting rid of the newly
> introduced friction, ie need to press the enter key.

Yes, exactly.  Though users are sort of expected to read "Incompatible
changes" sections of NEWS, not all do and it is easy to misunderstand
the real relevance of each section.  In this case, the impact is
pretty big, though personally I'm still trying to incorporate this
feature (I know, I've been missing out) and I could probably rewire my
brain more easily than others.

Anyway, I sometimes toy with the idea of proposing doing this much
more conservative remapping by default.

   (global-set-key [remap just-one-space] 'cycle-spacing)

But even this would probably set off alarms in someone's
workflow.

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

[Alfred M. Szmidt]

   > Also, when this ships and surprizes users, how  do we expect those
   > users to discover this use-preview knob; even if I found that knob,
   > I'd never guess that it waas the means of getting rid of the newly
   > introduced friction, ie need to press the enter key.

   Yes, exactly.  Though users are sort of expected to read "Incompatible
   changes" sections of NEWS, not all do and it is easy to misunderstand
   the real relevance of each section.  

It is very easy to miss, since it is under incompatible _Lisp_ changes
making one think it only matters if you're touching Lisp code.  If
anything, this should be under "Changes in Emacs", with a big blurb of
what happens, and how to restore the existing behaviour to exactly how
it was before.

   Anyway, I sometimes toy with the idea of proposing doing this much
   more conservative remapping by default.

      (global-set-key [remap just-one-space] 'cycle-spacing)

   But even this would probably set off alarms in someone's
   workflow.

Don't we have eough hornets ... but that one seems nice since it
doesn't break the "normal" case?

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

[João Távora]

On Sun, Dec 10, 2023 at 8:30 PM Alfred M. Szmidt <ams@gnu.org> wrote:

>    But even this would probably set off alarms in someone's
>    workflow.
>
> Don't we have eough hornets ... but that one seems nice since it
> doesn't break the "normal" case?

Precisely, that's why I say it's more tame/conservative.  But I'm
sure someone would find it a hornet.  https://xkcd.com/1172/

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

[T.V Raman]

thinking through this again, let's view the  picture:

1. Register preview requires users to hit an additional enter key.
   2. people who work by muscle memory find that extra key introduces
      friction.

      Conjecture to be verified --

      People who look at the preview -- even if they just glance at it
      -- are not the ones who work by muscle memory --- AKA  if you
      are used to hitting C-x r s a and continuing, you likely will
      not see the preview.

      

João Távora writes:
 > On Sun, Dec 10, 2023 at 7:44 PM T.V Raman <raman@google.com> wrote:
 > >
 > >
 > > Also, when this ships and surprizes users, how  do we expect those
 > > users to discover this use-preview knob; even if I found that knob,
 > > I'd never guess that it waas the means of getting rid of the newly
 > > introduced friction, ie need to press the enter key.
 > 
 > Yes, exactly.  Though users are sort of expected to read "Incompatible
 > changes" sections of NEWS, not all do and it is easy to misunderstand
 > the real relevance of each section.  In this case, the impact is
 > pretty big, though personally I'm still trying to incorporate this
 > feature (I know, I've been missing out) and I could probably rewire my
 > brain more easily than others.
 > 
 > Anyway, I sometimes toy with the idea of proposing doing this much
 > more conservative remapping by default.
 > 
 >    (global-set-key [remap just-one-space] 'cycle-spacing)
 > 
 > But even this would probably set off alarms in someone's
 > workflow.

-- 

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

[Alfred M. Szmidt]

   1. Register preview requires users to hit an additional enter key.
      2. people who work by muscle memory find that extra key introduces
	 friction.

	 Conjecture to be verified --

	 People who look at the preview -- even if they just glance at it
	 -- are not the ones who work by muscle memory --- AKA  if you
	 are used to hitting C-x r s a and continuing, you likely will
	 not see the preview.

Before, you would have a delay .. so if you waited for 1 second (I
think that was the default); you'd get the preview.  Still not
breaking the standard behaviour, and in a sense useful if you forgot
what register was what -- you'd just wait for a bit and be presented
with the preview.  So I think your conjecture is false that it is just
a matter of "muscle memory".  Not to mention that you forget that this
breaks recording keyboard macros.

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

[Eli Zaretskii]

People who are interested in registers are kindly requested to try the
latest two patches prepared by Thierry and posted by him in these two
messages:

  https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00644.html
  https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00650.html

Please provide opinions on these two alternative patches.  By
"opinions" I mean not only "like" or "dislike", but also arguments for
why you like/dislike this or that implementation.

I'm also interested to hear arguments why should the new behavior be
the default, if there are people who think the new behavior is better
in some circumstances.

When you reply to the messages, please keep the Subject line:

   bug#66394: 29.1; Make register-read-with-preview more useful

intact, and please CC bug-gnu-emacs@gnu.org.  Preferably, download the
messages in their mbox format:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394;mbox=yes;msg=216
  https://debbugs.gnu.org/cgi/bugreport.cgi?msg=219;bug=66394;mbox=yes

then open them in your MUA, and use the Reply All function to reply to
all the addresses with the correct Subject.

It is important for us to hear opinions about these two patches in
order to make an informed decision which will make this feature
acceptable for users.

TIA

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

[Dmitry Gutov]

On 11/12/2023 14:27, Eli Zaretskii wrote:
> I'm also interested to hear arguments why should the new behavior be
> the default, if there are people who think the new behavior is better
> in some circumstances.

FWIW, the recent blog post (setting aside its overall tone) sparked at 
least two discussions: on Reddit and on Hacker News.

And among comments there, I noticed a few saying something like "this 
could make registers usable for me".

And the idea of prompting when overriding a register seems good for 
default behavior, at least in theory.

Take this with a armful of salt, since I'm one of those that never used 
registers, though this change (a better, visual preview) might make them 
more attractive for me too. Whether that can make them a regular tool, 
is still to be seen.

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

[Colin Baxter]

>>>>> Dmitry Gutov <dmitry@gutov.dev> writes:

    > On 11/12/2023 14:27, Eli Zaretskii wrote:
    >> I'm also interested to hear arguments why should the new behavior
    >> be the default, if there are people who think the new behavior is
    >> better in some circumstances.

    > FWIW, the recent blog post (setting aside its overall tone)
    > sparked at least two discussions: on Reddit and on Hacker News.

    > And among comments there, I noticed a few saying something like
    > "this could make registers usable for me".

    > And the idea of prompting when overriding a register seems good
    > for default behavior, at least in theory.

    > Take this with a armful of salt, since I'm one of those that never
    > used registers, though this change (a better, visual preview)
    > might make them more attractive for me too. Whether that can make
    > them a regular tool, is still to be seen.
 
I'm pleased you wrote this because I too have never used
registers. Having now tried point-to-register for the first time, I
think it will prove to be very useful. Perhaps experienced users don't
need it, but I especially like the confirmation provided by the visual
preview.

Colin Baxter.

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

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 11/12/2023 14:27, Eli Zaretskii wrote:
>> I'm also interested to hear arguments why should the new behavior be
>> the default, if there are people who think the new behavior is better
>> in some circumstances.
>
> FWIW, the recent blog post (setting aside its overall tone) sparked at
> least two discussions: on Reddit and on Hacker News.
>
> And among comments there, I noticed a few saying something like "this
> could make registers usable for me".
>
> And the idea of prompting when overriding a register seems good for
> default behavior, at least in theory.
>
> Take this with a armful of salt, since I'm one of those that never
> used registers, though this change (a better, visual preview) might
> make them more attractive for me too. Whether that can make them a
> regular tool, is still to be seen.

Having upgraded, I prefer the new behavior.  And I can live with its
being the default.

Overwriting previous registers by accident has always been a frequent
blunder for me, and one extra RET is a small price to pay for its
prevention.

Nevertheless there should be an option to disable it, for those who
disagree, but the dithyramb posted to Reddit was uncalled-for.

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

[Alfred M. Szmidt]

   And the idea of prompting when overriding a register seems good for 
   default behavior, at least in theory.

It breaks predictive behaviour of how registers work, specially in
keyboard macros. 

   Take this with a armful of salt, since I'm one of those that never used 
   registers, though this change (a better, visual preview) might make them 
   more attractive for me too. Whether that can make them a regular tool, 
   is still to be seen.

The visual preview already existed before this change.  If you had
learnt about registers before the "RET" changes, it seems that it
would have been equally attractive, no?

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

[João Távora]

On Mon, Dec 11, 2023 at 12:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> People who are interested in registers are kindly requested to try the
> latest two patches prepared by Thierry and posted by him in these two
> messages:
>
>   https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00644.html
>   https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00650.html

Hi.  I've tried the former (msg00644), as the latter seems basically to change
the default of register-use-preview.  My opinion is that if the
default were 'nil',
I would be happy.

It's a  change in behaviour vs Emacs 29, but things stay "keystroke compatible".
IOW if I have my eyes closed and type the same keys, I get the same
end result when I open them.

I think changes should be evaluated systematically in (at least) two axes:

a) keystroke incompatibility to previous defaults
b) visual incompatibility to previous defaults

To be multiplied by the feature's

c) estimated frequency of use

I think the original change was received poorly because it a) was fairly
high, b) is nonzero and c) for is very high.

Needless to say, the change of msg00650 scores 0 because a) and b) are
both 0.  If the default were 'nil' b) would still be nonzero, but since
a) is 0, the final value is something I'm personally OK with.

João

PS: an example of a good past change to a default was when ElDoc
started showing documentation in the mode-line when the echo area
was occupied by minibuffer prompting.  I think around Emacs 225?
There was some visual incompatibility, but the keystroke
incompatibility was 0.

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

[Eli Zaretskii]

What do people who opined on these matters think about the default
proposed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394#249,
in the 3rd patch there?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394#276 seems to
indicate at least two people think it's a good default.

Please post your opinions either here or in that bug discussion (but
not both).

Thanks.

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

[Alfred M. Szmidt]

Unless it wasn't clear -- I think it is a bad idea, it makes registers
the same as bookmarks.  Thierry hasn't addressed any of the questions
I raised either.

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

[João Távora]

On Thu, Dec 14, 2023 at 3:16 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>
> Unless it wasn't clear -- I think it is a bad idea, it makes registers
> the same as bookmarks.

I can really emphatize with this.  If we want confirmation prompts, visual
popups, etc, why don't we add those to bookmark.el?  It already has a
completing-read UI that is much more suitable for this, and would
allow these features much more naturally.  There are a bunch of
completing-read-friendly extensions for bells and whistles out there.

This would keep the register workflow intact, solve the same code-navigation
problems and relieve us of multiple patch iterations with complicated
customization options noone seems to agree on.

João

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

[T.V Raman]

1+.

Bookmarks is  a good place to address this and it will also get some
well-needed attention

João Távora writes:
 > On Thu, Dec 14, 2023 at 3:16 PM Alfred M. Szmidt <ams@gnu.org> wrote:
 > >
 > > Unless it wasn't clear -- I think it is a bad idea, it makes registers
 > > the same as bookmarks.
 > 
 > I can really emphatize with this.  If we want confirmation prompts, visual
 > popups, etc, why don't we add those to bookmark.el?  It already has a
 > completing-read UI that is much more suitable for this, and would
 > allow these features much more naturally.  There are a bunch of
 > completing-read-friendly extensions for bells and whistles out there.
 > 
 > This would keep the register workflow intact, solve the same code-navigation
 > problems and relieve us of multiple patch iterations with complicated
 > customization options noone seems to agree on.
 > 
 > João

-- 

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

[Dmitry Gutov]

On 14/12/2023 17:31, João Távora wrote:
> If we want confirmation prompts, visual
> popups, etc, why don't we add those to bookmark.el?  It already has a
> completing-read UI that is much more suitable for this, and would
> allow these features much more naturally.  There are a bunch of
> completing-read-friendly extensions for bells and whistles out there.

IIUC bookmarks don't contain all the same kind of information. They're 
only for file positions. So you can't even save a point to bookmarks 
when the buffer doesn't visit a file.

Nor can you store strings or numbers there.

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

[João Távora]

On Thu, Dec 14, 2023 at 3:45 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 14/12/2023 17:31, João Távora wrote:
> > If we want confirmation prompts, visual
> > popups, etc, why don't we add those to bookmark.el?  It already has a
> > completing-read UI that is much more suitable for this, and would
> > allow these features much more naturally.  There are a bunch of
> > completing-read-friendly extensions for bells and whistles out there.
>
> IIUC bookmarks don't contain all the same kind of information. They're
> only for file positions. So you can't even save a point to bookmarks
> when the buffer doesn't visit a file.
>
> Nor can you store strings or numbers there.

This could be added, likely with much less code than the ever growing
register patch, by simply allowing bookmark.el access to the register
database, to set and read registers with its better UI.  Reuse, don't
reinvent, and respect workflows.

João

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

[João Távora]

On Thu, Dec 14, 2023 at 4:22 PM João Távora <joaotavora@gmail.com> wrote:

> This could be added, likely with much less code than the ever growing
> register patch, by simply allowing bookmark.el access to the register
> database, to set and read registers with its better UI.  Reuse, don't
> reinvent, and respect workflows.

OTOH, registers can store window configurations, frameset, and arbitrary
things, so "bookmarks" would become "generalized bookmarks".... There is a
lot of overlap between the two things though and like Raman said, bookmark.el
could use some love, and this could be the chance.  I think it's clear that
completing-read UI is clearly more natural for these types of visual
feedback and confirmation things.

That said, like you, I don't use either much.  I was just getting into
registers though, for saving window configurations, but not long enough
to have built muscle-memory.

João

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

[Ihor Radchenko]

João Távora <joaotavora@gmail.com> writes:

> OTOH, registers can store window configurations, frameset, and arbitrary
> things, so "bookmarks" would become "generalized bookmarks".... There is a
> lot of overlap between the two things though and like Raman said, bookmark.el
> could use some love, and this could be the chance.

FYI, there is a package extending bookmarks to store window
configurations as well https://github.com/alphapapa/burly.el
So, generalizing bookmarks is certainly something doable.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> OTOH, registers can store window configurations, frameset, and arbitrary
> things, so "bookmarks" would become "generalized bookmarks".... 

Bookmarks are already "generalized".  You can
store and restore such configs.  E.g. desktop
bookmarks.  A bookmark is just a function.  It
can store arbitrary things - whatever you can
write and read as Lisp (indirectly even things
that have no Lisp representation).

> like Raman said, bookmark.el could use some love,
> and this could be the chance.

Frankly, I hope not.

<opinion>

[ I don't encourage messing more with bookmark.el,
  as Bookmark+ extends/enhances it, and experience
  shows that vanilla changes to improve something
  like this just wreaks havoc with libraries that
  build upon it.

  The less people mess with bookmark.el, the
  better for Bookmark+ maintenance.

  If something in Bookmark+ can help, it could be
  used by bookmark.el.  But again, experience
  shows that the adoption of ideas from 3rd-party
  code also ends up making things worse for that
  3rd-party code.  Unless the code itself is taken
  more or less as is, instead of changed to fit
  someone's idea of even "better", things are made
  worse. ]

</opinion>

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> like Raman said, bookmark.el could use some love,
>> and this could be the chance.
>
> Frankly, I hope not.
>
> <opinion>
>
> [ I don't encourage messing more with bookmark.el,
>   as Bookmark+ extends/enhances it, and experience
>   shows that vanilla changes to improve something
>   like this just wreaks havoc with libraries that
>   build upon it.
>
>   The less people mess with bookmark.el, the
>   better for Bookmark+ maintenance.

I don't think we can really slow down the development of Emacs.  If
changes are proposed, and they are deemed good, we will accept them.

If you want to reduce your maintenance burden, you should not to ask us
to slow down Emacs development.  Instead, you should start working on
merging bookmark+.el features into Emacs itself.

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

[João Távora]

On Thu, Dec 14, 2023 at 8:18 PM Stefan Kangas <stefankangas@gmail.com> wrote:

> If you want to reduce your maintenance burden, you should not to ask us
> to slow down Emacs development.  Instead, you should start working on
> merging bookmark+.el features into Emacs itself.

Exactly.  Or alternatively, curating bookmark.el so that it opens
up an external API that bookmark+.el -- and others -- can rely upon
for a longer period of time.  This is hard work, but it pays off.
The parts that are left as internal implementation details are of
course free for Emacs devs to change.

João

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> > If you want to reduce your maintenance burden, you should not to ask us
> > to slow down Emacs development.  Instead, you should start working on
> > merging bookmark+.el features into Emacs itself.
> 
> Exactly.  Or alternatively, curating bookmark.el so that it opens
> up an external API that bookmark+.el -- and others -- can rely upon
> for a longer period of time.  This is hard work, but it pays off.
> The parts that are left as internal implementation details are of
> course free for Emacs devs to change.

My latest set of patches submitted for bookmark.el (which
improves the "external API" aspect, among other things):

https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00500.html

Last post of that thread:

https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01841.html

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

[João Távora]

On Thu, Dec 14, 2023 at 10:54 PM Drew Adams <drew.adams@oracle.com> wrote:

> > Exactly.  Or alternatively, curating bookmark.el so that it opens
> > up an external API that bookmark+.el -- and others -- can rely upon
> > for a longer period of time.  This is hard work, but it pays off.
> > The parts that are left as internal implementation details are of
> > course free for Emacs devs to change.
>
> My latest set of patches submitted for bookmark.el (which
> improves the "external API" aspect, among other things):
>
> https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00500.html
>
> Last post of that thread:
>
> https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01841.html

:-) It's nice that we agree.

I don't have time to review those patches, but I gather it is some
kind of backward-compatibility concern.  Indeed that is though, one
must first analyze exactly what is potentially broken, and gauge how
much fallout there will be.  Then be prepared to help whoever is affected
deal with it.  We do this more often than one would think ;-)
Anyway, if you're a bookmark.el specialist and you have that time
you are probably the most qualified person to do it, so from a
10000 ft perspective I'd say go that thread again and insist
that your patch is responsible enough.

João

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

[Dmitry Gutov]

On 15/12/2023 00:54, Drew Adams wrote:
>>> If you want to reduce your maintenance burden, you should not to ask us
>>> to slow down Emacs development.  Instead, you should start working on
>>> merging bookmark+.el features into Emacs itself.
>> Exactly.  Or alternatively, curating bookmark.el so that it opens
>> up an external API that bookmark+.el -- and others -- can rely upon
>> for a longer period of time.  This is hard work, but it pays off.
>> The parts that are left as internal implementation details are of
>> course free for Emacs devs to change.
> My latest set of patches submitted for bookmark.el (which
> improves the "external API" aspect, among other things):
> 
> https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00500.html
> 
> Last post of that thread:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01841.html

You posted a patch, got a round of review comments, but didn't follow up 
with any revised versions. The result is as expected.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Adam Porter]

> My latest set of patches submitted for bookmark.el (which
> improves the "external API" aspect, among other things):
> 
> https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00500.html
> 
> Last post of that thread:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01841.html

FWIW, without commenting on the specifics of that patch, I would greatly 
appreciate having what it implements be merged.

In my work on packages using the bookmark system 
(org-bookmark-heading[0], burly[1], and bufler[2], as well as others 
which implement bookmark handlers relevant to their own specific needs 
like Ement[3]), I have often encountered the extreme awkwardness of 
having to work around the bookmark library's own setting of buffers and 
such, having to resort to hacks such as using a 0-second timer to switch 
buffers or windows immediately after bookmark-jump returns.

It would make such extensions, as well as major modes' handlers, much 
easier and less hacky to write if only the default bookmark handler did 
those things, leaving other, bespoke handlers alone.

Some of these footnotes illustrate the use of such hacks:

0: https://github.com/alphapapa/org-bookmark-heading
1: 
https://github.com/alphapapa/burly.el/blob/f503fdc3af2f4e4a2a9023c763f71582e09eee8c/burly.el#L373-L391
2: 
https://github.com/alphapapa/bufler.el/blob/2e57f56068d18b2ee5832a6c3e2cec0c5279a812/bufler-workspace.el#L288-L344
3: 
https://github.com/alphapapa/ement.el/blob/e509dc958ca90e239b060d8ca31ed240beb0871d/ement-room.el#L1063-L1083

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> >> like Raman said, bookmark.el could use some love,
> >> and this could be the chance.
> >
> > Frankly, I hope not.
> >
> > <opinion>
> >
> > [ I don't encourage messing more with bookmark.el,
> >   as Bookmark+ extends/enhances it, and experience
> >   shows that vanilla changes to improve something
> >   like this just wreaks havoc with libraries that
> >   build upon it.
> >
> >   The less people mess with bookmark.el, the
> >   better for Bookmark+ maintenance.
> >   If something in Bookmark+ can help, it could be
> >   used by bookmark.el.  But again, experience
> >   shows that the adoption of ideas from 3rd-party
> >   code also ends up making things worse for that
> >   3rd-party code.  Unless the code itself is taken
> >   more or less as is, instead of changed to fit
> >   someone's idea of even "better", things are made
> >   worse. ]
> >
> > </opinion>
> 
> I don't think we can really slow down the development of Emacs.

No, of course not.  Just expressing an opinion.

> you should start working on
> merging bookmark+.el features into Emacs itself.

Tried that.  (At one point Stefan even said
that Bookmark+ should replace bookmark.el.)

The source code is there, if someone wants to
update vanilla Emacs (your "Emacs itself") to
use some or all of Bookmark+.  But don't hold
your breath.

Merging bookmark+ features into Emacs itself

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> >> like Raman said, bookmark.el could use some love,
>> >> and this could be the chance.
>> >
>> > Frankly, I hope not.
>> >
>> > <opinion>
>> >
>> > [ I don't encourage messing more with bookmark.el,
>> >   as Bookmark+ extends/enhances it, and experience
>> >   shows that vanilla changes to improve something
>> >   like this just wreaks havoc with libraries that
>> >   build upon it.
>> >
>> >   The less people mess with bookmark.el, the
>> >   better for Bookmark+ maintenance.
>> >   If something in Bookmark+ can help, it could be
>> >   used by bookmark.el.  But again, experience
>> >   shows that the adoption of ideas from 3rd-party
>> >   code also ends up making things worse for that
>> >   3rd-party code.  Unless the code itself is taken
>> >   more or less as is, instead of changed to fit
>> >   someone's idea of even "better", things are made
>> >   worse. ]
>> >
>> > </opinion>
>>
>> I don't think we can really slow down the development of Emacs.
>
> No, of course not.  Just expressing an opinion.
>
>> you should start working on
>> merging bookmark+.el features into Emacs itself.
>
> Tried that.

Where can I find those attempts?  Why did your attempts fail?

Are you willing to try again?

> (At one point Stefan even said that Bookmark+ should replace
> bookmark.el.)

I can't really comment on that idea, as I haven't thought about it.

I'm not ruling it out a priori or anything like that, but my thinking
was that merging it one feature at a time would make it easier to review
the new features, ensure they are integrated properly, update the
documentation, and so on.

Copying Stefan Monnier in case he has anything to add.

RE: [External] : Merging bookmark+ features into Emacs itself

[Drew Adams]

> >> you should start working on merging
> >> bookmark+.el features into Emacs itself.
> >
> > Tried that.
> 
> Where can I find those attempts?  Why did your attempts fail?

I meant that I submitted the patches for the
fix.  I already referenced the mail that has
those patches:

https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00500.html

> Are you willing to try again?

I won't be merging anything, myself.  If
someone wants to apply the patches, and has
questions, I'll try to find the time to
answer them.  If you're actually interested
then I suggest you start with that message
and read the full (short) thread.

FWIW, for the case at hand I prefer the use
of a defvar to the alternative of depending
on a closure variable.  That gives Bookmark+
backward compatibility (support for old
Emacs versions), and it's more flexible: you
can bind the variable anywhere to affect the
code the way you want (a plus and a potential
minus, of course).

But if, as Karl expressed, vanilla Emacs
prefers to use a closure variable instead,
feel free to do so.  In that case, I'll just
have to keep the Bookmark+ version of (at
least some of) the fix code, even if the fix
is added to Emacs.

If changes are made to Emacs that mess with
what Bookmark+ does, then I'll have to work
around those.  And I don't have much time
for that.  Without Emacs getting fixed for
this I don't have to worry about that.  IMO
it makes sense for Emacs to be fixed for
this, but I'm wary of what I might have to
do afterward to mitigate the damage.

Maybe not the response you were looking for,
but hopefully it's clear at least.  I hope
the problem and the fix are also clear; I
think they should be.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[T.V Raman]

That sounds reasonable, but also feels contradictory to the sentiment
that "shrinking the core, providing a strong platform and then
enabling extensions" reduces overall  maintenance burden?



Stefan Kangas writes:
 > Drew Adams <drew.adams@oracle.com> writes:
 > 
 > >> like Raman said, bookmark.el could use some love,
 > >> and this could be the chance.
 > >
 > > Frankly, I hope not.
 > >
 > > <opinion>
 > >
 > > [ I don't encourage messing more with bookmark.el,
 > >   as Bookmark+ extends/enhances it, and experience
 > >   shows that vanilla changes to improve something
 > >   like this just wreaks havoc with libraries that
 > >   build upon it.
 > >
 > >   The less people mess with bookmark.el, the
 > >   better for Bookmark+ maintenance.
 > 
 > I don't think we can really slow down the development of Emacs.  If
 > changes are proposed, and they are deemed good, we will accept them.
 > 
 > If you want to reduce your maintenance burden, you should not to ask us
 > to slow down Emacs development.  Instead, you should start working on
 > merging bookmark+.el features into Emacs itself.

-- 

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 14 Dec 2023 16:22:10 +0000
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, raman@google.com, 
> 	thievol@posteo.net, eduardoochs@gmail.com, schwab@linux-m68k.org, 
> 	eller.helmut@gmail.com, tino.calancha@gmail.com
> 
> On Thu, Dec 14, 2023 at 3:45 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > On 14/12/2023 17:31, João Távora wrote:
> > > If we want confirmation prompts, visual
> > > popups, etc, why don't we add those to bookmark.el?  It already has a
> > > completing-read UI that is much more suitable for this, and would
> > > allow these features much more naturally.  There are a bunch of
> > > completing-read-friendly extensions for bells and whistles out there.
> >
> > IIUC bookmarks don't contain all the same kind of information. They're
> > only for file positions. So you can't even save a point to bookmarks
> > when the buffer doesn't visit a file.
> >
> > Nor can you store strings or numbers there.
> 
> This could be added

It could, but it shouldn't.  Bookmarks are not for storing arbitrary
stuff, let's not take a nearly-perfect feature and add random stuff to
it that doesn't belong.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> > Nor can you store strings or numbers there.

Yes, you can.

> > This could be added
> 
> It could, but it shouldn't.  Bookmarks are not for storing arbitrary
> stuff, let's not take a nearly-perfect feature and add random stuff to
> it that doesn't belong.

<cough, cough>

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

[Eli Zaretskii]

> Date: Thu, 14 Dec 2023 17:45:21 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, raman@google.com,
>  thievol@posteo.net, eduardoochs@gmail.com, schwab@linux-m68k.org,
>  eller.helmut@gmail.com, tino.calancha@gmail.com
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 14/12/2023 17:31, João Távora wrote:
> > If we want confirmation prompts, visual
> > popups, etc, why don't we add those to bookmark.el?  It already has a
> > completing-read UI that is much more suitable for this, and would
> > allow these features much more naturally.  There are a bunch of
> > completing-read-friendly extensions for bells and whistles out there.
> 
> IIUC bookmarks don't contain all the same kind of information.

They don't, and neither should they.

> They're only for file positions.

Exactly.

This idea is a non-starter.

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

[Alfred M. Szmidt]

   > > If we want confirmation prompts, visual
   > > popups, etc, why don't we add those to bookmark.el?  It already has a
   > > completing-read UI that is much more suitable for this, and would
   > > allow these features much more naturally.  There are a bunch of
   > > completing-read-friendly extensions for bells and whistles out there.
   > 
   > IIUC bookmarks don't contain all the same kind of information.

   They don't, and neither should they.

You provide no explanation why they shouldn't -- storing text region
in a bookmark would be immensly useful for example.  Instead, you
simply dismiss the idea without even the remote possibility to explore
it, while at the same time forcing through the patch of registers
having confirmation -- whose entire purpose is to not be interactive.

Seems like this discussion is at a impase and pointless since you've
already made the decision, and the whole notion of havign a discussion
is a smoke screen.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org,
> 	raman@google.com, thievol@posteo.net, eduardoochs@gmail.com,
> 	schwab@linux-m68k.org, eller.helmut@gmail.com,
> 	tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 12:10:49 -0500
> 
>    > > If we want confirmation prompts, visual
>    > > popups, etc, why don't we add those to bookmark.el?  It already has a
>    > > completing-read UI that is much more suitable for this, and would
>    > > allow these features much more naturally.  There are a bunch of
>    > > completing-read-friendly extensions for bells and whistles out there.
>    > 
>    > IIUC bookmarks don't contain all the same kind of information.
> 
>    They don't, and neither should they.
> 
> You provide no explanation why they shouldn't

I did, but in another message in this very thread.

To recap: bookmarks are for saving places in files.

> Seems like this discussion is at a impase and pointless since you've
> already made the decision, and the whole notion of havign a discussion
> is a smoke screen.

I already made the decision about bookmarks, yes.  And I said so
several days ago.  I did NOT yet make the decision about registers,
which is why this discussion is very important for me (and I hope for
others as well), and is anything but a smoke screen.

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

[Alfred M. Szmidt]

   To recap: bookmarks are for saving places in files.

And registers are saving points in places without confirmation.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> To recap: bookmarks are for saving places in files.
> 
> > Seems like this discussion is at a impase and pointless since you've
> > already made the decision, and the whole notion of havign a discussion
> > is a smoke screen.
> 
> I already made the decision about bookmarks, yes.

Glad to hear it; seriously.  A reprieve for 
Bookmark+ maintenance.

Not sarcasm at all, BTW.  I'm glad that folks
won't be messing up bookmark.el, making its
base code unusable by/for Bookmark+.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> IIUC bookmarks don't contain all the same kind of information. They're
> only for file positions. So you can't even save a point to bookmarks
> when the buffer doesn't visit a file.
> Nor can you store strings or numbers there.

None of that is true.  A bookmark can contain
anything, and it can be, but it need not be,
persisted.

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

[Alfred M. Szmidt]

   > Unless it wasn't clear -- I think it is a bad idea, it makes registers
   > the same as bookmarks.

   I can really emphatize with this.  If we want confirmation prompts, visual
   popups, etc, why don't we add those to bookmark.el?  It already has a
   completing-read UI that is much more suitable for this, and would
   allow these features much more naturally.  There are a bunch of
   completing-read-friendly extensions for bells and whistles out there.

   This would keep the register workflow intact, solve the same code-navigation
   problems and relieve us of multiple patch iterations with complicated
   customization options noone seems to agree on.

E.g., bookmarks does not warn about overwriting an existing bookmark.
That would be a good place for such a warning, and even prompt would
make sense and a change I think nobody would even object to.

Bookmarks doesn't do the whole preview thing, which in it self is nice
even for registers when you only have a delay.  And for bookmarks it
would make even _more_ sense, where for registers it mostly does not
--- "position 17777777" is not very useful in the output even
misleading if you are narrowing your view, for bookmarks this could be
actual line or something.


If the issue is the temporary aspect of registers or not being able to
set bookmarks in some contexts (buffers without a associated file,
e.g.), I'm sure that can be solved by allowing bookmarks and registers
to co-exist in some form and showing that in the bookmark-list/preview
accordingly and then hooking bookmark-set/jump to use the relevant
register functions instead under the hood.


I'm beyond convinced that those who want to use registers with
confirmation really should be using bookmarks and that this change is
simply not needed.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> E.g., bookmarks does not warn about overwriting an existing bookmark.

If you use a prefix arg with `bookmark-set'
then you don't overwrite any bookmark with
the same name.  Instead you add a new one
with the same name.  IOW, bookmarks are
handled like alist entries (which they are).  

You can also use `bookmark-set-no-overwrite'
instead of `bookmark-set', in which case an
error is raised if you provide the same name
as an existing bookmark, and a prefix arg
pushes the new bookmark with the same name.

Being able to have multiple bookmarks with
the same name is a _feature_, not a bug.

> That would be a good place for such a warning, and even prompt would
> make sense and a change I think nobody would even object to.
> 
> Bookmarks doesn't do the whole preview thing

Bookmarks can do anything you want them to.
They're just functions.

> If the issue is the temporary aspect of registers or not being able to
> set bookmarks in some contexts (buffers without a associated file,
> e.g.),

Not an issue.

With Bookmark+, you can have temporary
bookmarks.  (And even with vanilla
bookmark.el you need not save a bookmark
file, and you can remove bookmarks from it
before saving.)

And with Bookmark+ you can bookmark non-file
buffers.  (Even vanilla bookmark.el does
that, for Dired buffers, though it doesn't
do it well.  someone will say a directory is
also a file, but that's irrelevant here.)

You can really bookmark anything.  Again, a
bookmark is just a function - it can do
anything at all.  It need not have anything
to do with any notion of "location", or the
"location" can be as bizarre or unusual as
you like.

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 14 Dec 2023 15:31:43 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, raman@google.com, thievol@posteo.net, 
> 	eduardoochs@gmail.com, schwab@linux-m68k.org, eller.helmut@gmail.com, 
> 	tino.calancha@gmail.com
> 
> On Thu, Dec 14, 2023 at 3:16 PM Alfred M. Szmidt <ams@gnu.org> wrote:
> >
> > Unless it wasn't clear -- I think it is a bad idea, it makes registers
> > the same as bookmarks.
> 
> I can really emphatize with this.  If we want confirmation prompts, visual
> popups, etc, why don't we add those to bookmark.el?  It already has a
> completing-read UI that is much more suitable for this, and would
> allow these features much more naturally.  There are a bunch of
> completing-read-friendly extensions for bells and whistles out there.
> 
> This would keep the register workflow intact, solve the same code-navigation
> problems and relieve us of multiple patch iterations with complicated
> customization options noone seems to agree on.

Thanks, but I already said I'm not interested in contemplating this
idea.  For starters, IMO it is against the very nature of bookmarks
and their purpose.

Let's stay focused on registers here, so we could finalize the changes
to make people more happy than they are now.

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

[Alfred M. Szmidt]

   Thanks, but I already said I'm not interested in contemplating this
   idea.  For starters, IMO it is against the very nature of bookmarks
   and their purpose.

And it is against the very nature of registers and their purpose to
ask for confirmation.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
> 	thievol@posteo.net, eduardoochs@gmail.com,
> 	schwab@linux-m68k.org, eller.helmut@gmail.com,
> 	tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 12:01:52 -0500
> 
>    Thanks, but I already said I'm not interested in contemplating this
>    idea.  For starters, IMO it is against the very nature of bookmarks
>    and their purpose.
> 
> And it is against the very nature of registers and their purpose to
> ask for confirmation.

Yes, I understand that many users of registers share this opinion, and
I assure you it will be given the most careful and serious
consideration so that the end result will allow confirmation-less
behavior for those who want it.

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

[Alfred M. Szmidt]

   > From: "Alfred M. Szmidt" <ams@gnu.org>
   > Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
   > 	thievol@posteo.net, eduardoochs@gmail.com,
   > 	schwab@linux-m68k.org, eller.helmut@gmail.com,
   > 	tino.calancha@gmail.com
   > Date: Thu, 14 Dec 2023 12:01:52 -0500
   > 
   >    Thanks, but I already said I'm not interested in contemplating this
   >    idea.  For starters, IMO it is against the very nature of bookmarks
   >    and their purpose.
   > 
   > And it is against the very nature of registers and their purpose to
   > ask for confirmation.

   Yes, I understand that many users of registers share this opinion, and
   I assure you it will be given the most careful and serious
   consideration so that the end result will allow confirmation-less
   behavior for those who want it.

Sorry, I do not beileve you for a second.  You're just saying that
there will be a frob, ignoring the whole topic that the whole intent
of registers has now become bookmarks.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
> 	thievol@posteo.net, eduardoochs@gmail.com,
> 	schwab@linux-m68k.org, eller.helmut@gmail.com,
> 	tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 12:10:49 -0500
> 
>    > And it is against the very nature of registers and their purpose to
>    > ask for confirmation.
> 
>    Yes, I understand that many users of registers share this opinion, and
>    I assure you it will be given the most careful and serious
>    consideration so that the end result will allow confirmation-less
>    behavior for those who want it.
> 
> Sorry, I do not beileve you for a second.

You have no reason to think I'm not telling the truth.

But even if you do, please be civilized enough to keep such ad-hominem
attacks out of this discussion.  If anything, it doesn't help your
opinions to sound more convincing.

> You're just saying that there will be a frob, ignoring the whole
> topic that the whole intent of registers has now become bookmarks.

I'm not ignoring anything.  That I don't respond to every opinion
voiced here doesn't mean I ignore them.  And please reserve your harsh
judgment about what became of registers until you see the final form
they will take (hopefully, soon).

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

[Alfred M. Szmidt]

   >    > And it is against the very nature of registers and their purpose to
   >    > ask for confirmation.
   > 
   >    Yes, I understand that many users of registers share this opinion, and
   >    I assure you it will be given the most careful and serious
   >    consideration so that the end result will allow confirmation-less
   >    behavior for those who want it.
   > 
   > Sorry, I do not beileve you for a second.

   You have no reason to think I'm not telling the truth.

It has nothing to do with truth, you blindly dimsissed the idea of
improving bookmarks to handle the workflow that people wish to have
for "registers with confirmation" -- that is why I don't believe you.

The rest is your usual bullying, that same you tried to exert in
private, there was nothing uncivlized, ad-hominem or harsh in my
message -- not everything is about you.

I'm out of this discussion, best of luck with Elimacs.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
>  thievol@posteo.net, eduardoochs@gmail.com,
>  schwab@linux-m68k.org, eller.helmut@gmail.com, tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 13:05:00 -0500
> 
>    > Sorry, I do not beileve you for a second.
> 
>    You have no reason to think I'm not telling the truth.
> 
> It has nothing to do with truth, you blindly dimsissed the idea of
> improving bookmarks to handle the workflow that people wish to have
> for "registers with confirmation" -- that is why I don't believe you.
> 
> The rest is your usual bullying, that same you tried to exert in
> private, there was nothing uncivlized, ad-hominem or harsh in my
> message -- not everything is about you.

How is this in line with the Gnu Kind Communications Guidelines, may I
ask?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> The rest is your usual bullying, that same you tried to exert in
>> private, there was nothing uncivlized, ad-hominem or harsh in my
>> message -- not everything is about you.
>
> How is this in line with the Gnu Kind Communications Guidelines, may I
> ask?

It's not.

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

[Alfred M. Szmidt]

   It's not.

Indeed:

  If others have irritated you, perhaps by disregarding these
  guidelines, please don't excoriate them, and especially please don't
  hold a grudge against them. The constructive approach is to encourage
  and help other people to do better. When they are trying to learn to
  do better, please give them plenty of chances.

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
>  thievol@posteo.net, eduardoochs@gmail.com,
>  schwab@linux-m68k.org, eller.helmut@gmail.com, tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 10:16:39 -0500
> 
> Unless it wasn't clear -- I think it is a bad idea, it makes registers
> the same as bookmarks.

Thanks, but please elaborate: which patch are you alluding to here?

> Thierry hasn't addressed any of the questions I raised either.

Where can I find those questions, please?

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

[Alfred M. Szmidt]

   > Unless it wasn't clear -- I think it is a bad idea, it makes registers
   > the same as bookmarks.

   Thanks, but please elaborate: which patch are you alluding to here?

Which patch doesn't matter -- the patch is miguided.  Registers are
not supposed to ask for confirmation.

   > Thierry hasn't addressed any of the questions I raised either.

   Where can I find those questions, please?

It is in the bug report, as you requested.
https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00694.html

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

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
> 	thievol@posteo.net, eduardoochs@gmail.com,
> 	schwab@linux-m68k.org, eller.helmut@gmail.com,
> 	tino.calancha@gmail.com
> Date: Thu, 14 Dec 2023 12:01:52 -0500
> 
>    > Unless it wasn't clear -- I think it is a bad idea, it makes registers
>    > the same as bookmarks.
> 
>    Thanks, but please elaborate: which patch are you alluding to here?
> 
> Which patch doesn't matter -- the patch is miguided.  Registers are
> not supposed to ask for confirmation.

One of the patches makes Emacs not ask for confirmation by default.
Does the above mean you consider that one a bad idea as well?

>    > Thierry hasn't addressed any of the questions I raised either.
> 
>    Where can I find those questions, please?
> 
> It is in the bug report, as you requested.
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-12/msg00694.html

Thanks.

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

[Alfred M. Szmidt]

   > From: "Alfred M. Szmidt" <ams@gnu.org>
   > Cc: joaotavora@gmail.com, emacs-devel@gnu.org, raman@google.com,
   > 	thievol@posteo.net, eduardoochs@gmail.com,
   > 	schwab@linux-m68k.org, eller.helmut@gmail.com,
   > 	tino.calancha@gmail.com
   > Date: Thu, 14 Dec 2023 12:01:52 -0500
   > 
   >    > Unless it wasn't clear -- I think it is a bad idea, it makes registers
   >    > the same as bookmarks.
   > 
   >    Thanks, but please elaborate: which patch are you alluding to here?
   > 
   > Which patch doesn't matter -- the patch is miguided.  Registers are
   > not supposed to ask for confirmation.

   One of the patches makes Emacs not ask for confirmation by default.
   Does the above mean you consider that one a bad idea as well?

Yes, we have bookmarks for that.  If anything, despite your blind
dismissal, bookmarks should be extended to handle more scenarios of
what registers are capable of where possible.

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

[Stefan Kangas]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    One of the patches makes Emacs not ask for confirmation by default.
>    Does the above mean you consider that one a bad idea as well?
>
> Yes, we have bookmarks for that.

Did you test the second patch?

It seems to make registers work exactly like they did in 29.1 by
default, so I'm not sure that I understand what you're saying.

Is the Emacs 29.1 behavior bad also, in your opinion?

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

[Alfred M. Szmidt]

   >    One of the patches makes Emacs not ask for confirmation by default.
   >    Does the above mean you consider that one a bad idea as well?
   >
   > Yes, we have bookmarks for that.

   Did you test the second patch?

I have no reason to test it -- the whole notion of the patch is
backwards.  The current behaviour is the correct one.

   It seems to make registers work exactly like they did in 29.1 by
   default, so I'm not sure that I understand what you're saying.

They don't, as has been previpously explained multiple times -- they
remove one useful feature (delays), and they add confirmation (via
tiwddle) to registers where the whole intent of registers is not to
have such confirmation -- use bookmarks for that.  

   Is the Emacs 29.1 behavior bad also, in your opinion?

I think already answered that, the behaviour that was in 29 (and at
least back to 25) is the correct one.

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

[Alfred M. Szmidt]

   I think it is important to have a kind of warning and confirm when doing
   so.  I have personally often overwrited registers I was working with
   inadvertantly.

A warning, without confirmation (i.e. keeping the normal behaviour)
seems like a nice addition.

   Now when you set a new register you can use M-n and there it will set
   the register without the need to press RET.

The behaviour of this is sporadic.  M-n on the first invocation will
insert a, silently (how do you know which register it uses?).  On the
second, when trying to insert b, it will query the user.  Making this
hard to use in macros, or in any reliable fashion.

   I think the current behavior is sane, specially for new users - it is
   really surprizing that when hitting "a" for example there is no
   confirmation at all -, so I think the default for register-use-preview
   should be `t`.

That is the documented way registers work, why would it be remotley
suprising?

   If needed I can disable RET easily for register overwrite as well, this
   for the two remaining options of register-use-preview (nil and 'never)
   but I think it would be an error.

register-use-preview should disable "preview" -- it seems that this
variable is being used for other purposes, like making registers more
interactive.  Maybe those two behaviours should be split, have a
"register-warn-if-trashing-p" variable.

But it should be clear that some means of restoring the old behaviour,
exactly like it was, is needed with an easy toggle.

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

[Eduardo Ochs]

On Sun, 10 Dec 2023 at 11:57, Eli Zaretskii <eliz@gnu.org> wrote:
>
> >   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?

Hi Eli,

Sorry, you are right... I was sleepy when I wrote my e-mail and I
didn't realize that I can write the functions that I imagined -
jump-to-register-with-RET, jump-to-register-no-RET,
point-to-register-with-RET and point-to-register-no-RET - by just
wrapping the default functions inside `let's like this:

  (let ((register-use-preview ...)) ...)

Apologies for the sleepo! Cheers,
  Eduardo

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> > Previously, these commands allowed users to seamlessly navigate
> > without the need to press the RET key every time. Unfortunately, the
> > recent modification has introduced a requirement to press RET with
> > every use, which has proven to be quite cumbersome for me.
> 
> I fully concur with this.  This change is driving me nuts.

I've already weighed in on this, back when
themove to use the minibuffer for reading 
almost everything was first introduced.
Just repeating here for the record, that I
too concur.

Reading a char in the minibuffer is an
obstacle, not an aid.

Same with Isearch; it should never have
been changed to use the minibuffer instead
of the echo area.

(At least we have non-option defvar
`y-or-n-p-use-read-key'...)

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Emacs developers <emacs-devel@gnu.org>, Thierry Volpiatto
>  <thievol@posteo.net>
> Date: Fri, 8 Dec 2023 15:32:43 +0000
> 
> I've already weighed in on this, back when
> themove to use the minibuffer for reading 
> almost everything was first introduced.

This is unfair at best: Thierry did NOT make these changes as part of
"moving to use the minibuffer for reading almost everything".  He made
the changes as part of adding a new feature to the registers support,
and for reasons that are technical, not ideological or anything else.
I'm not yet sure the feature he added can be implemented without this
change; this is currently being discussed.

It is okay to say that you are unhappy about this aspect of the
change, but please give Thierry the credit for doing this for valid
technical reasons.

RE: [External] : Re: Please, Restore Previous Behavior for jump-to-register

[Drew Adams]

> > I've already weighed in on this, back when
> > themove to use the minibuffer for reading
> > almost everything was first introduced.
> 
> This is unfair at best: Thierry did NOT make these changes as part of
> "moving to use the minibuffer for reading almost everything".

I didn't say he did.  I didn't say he's done
anything wrong.  I'm not familiar with just
what's been done in this regard.

My point is general: some interactions should
not go through the minibuffer.  `read-key' is
one such, Isearch is another (apart from `M-e').
If this thread is about yet another then the
general remark might apply here as well.

If some "technical reasons" make it imperative
to use the minibuffer, so be it.

In that case, there's apparently no way to
make the change optional (nothing like defvar
`y-or-n-p-use-read-key' is possible).  And in
that case there's no need for this thread, the
answer in that case would be "can't be done".

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

[James Thomas]

+10!

Tino Calancha wrote:

> Dear Emacs maintainers,
>
> I am writing to express my concern about a recent change in the
> behavior of the jump-to-register and point-to-register commands in the
> master branch (Bug#66394).
>
> Previously, these commands allowed users to seamlessly navigate
> without the need to press the RET key every time. Unfortunately, the
> recent modification has introduced a requirement to press RET with
> every use, which has proven to be quite cumbersome for me.
>
> This change has impacted my workflow to the extent that I have opted
> to discontinue using the master branch.
>
> I kindly request the restoration of the previous behavior for
> jump-to-register and point-to-register commands. This adjustment would
> greatly enhance usability and ensure a smoother experience for users
> who have grown accustomed to the previous functionality.
>
> Thank you
> Tino

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

[João Pedro]

Hi,

Just chiming in with a suggestion! The amazing Jinx[1] package by Daniel
Mendler has a way to quickly select a suggestion from the minibuffer
without having to type RET. Although it makes more sense in the context
of Jinx, something like that could possibly be achieved for this case,
retaining the minibuffer information and completion, while also
(optionally) getting rid of the extra key press! The related code could
be seen in `jinx--add-suggestions'[2] where it adds the hints to the
candidates list, and `jinx-correct-select'[3].

[1] https://github.com/minad/jinx
[2] https://github.com/minad/jinx/blob/2533991bfe9da75aa6adad73770fe5b196ea0bb1/jinx.el#L661
[3] https://github.com/minad/jinx/blob/2533991bfe9da75aa6adad73770fe5b196ea0bb1/jinx.el#L942

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Just chiming in with a suggestion! The amazing Jinx[1] package by Daniel
  > Mendler has a way to quickly select a suggestion from the minibuffer
  > without having to type RET.

That sounds intriguing, but can someone describe less tersely what
that facility does and how one uses it?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Jean Louis]

How to disable the preview and asking me for RET?

I have tried to disable `register-use-preview' but again I am asked
for register and I am expected to press RET, so how to make it default
how it was before?

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Eli Zaretskii]

> Date: Sat, 16 Dec 2023 13:28:37 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> How to disable the preview and asking me for RET?
> 
> I have tried to disable `register-use-preview' but again I am asked
> for register and I am expected to press RET, so how to make it default
> how it was before?

For now, if you cannot endure the changes in registers on master even
when register-use-preview is customized to 'never', my recommendation
is to "git reset" to the revision before the changes were installed,
and wait for us to arrive at the final version, where there will be a
way to get back the old behavior.

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

[João Pedro]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Em sexta, 15/12/2023 às 23:22, Richard Stallman <rms@gnu.org> escreveu:

> That sounds intriguing, but can someone describe less tersely what
> that facility does and how one uses it?

Basically you can select a candidate from the minibuffer completion list
using a numeric argument, without having to type RET to exit from the
minibuffer. I attached a screenshot, using Vertico and Consult (although
the code I linked doesn't depend on any of those) to demonstrate what it
looks like. There, if you type '1' or '01' in your keyboard, you would
select 'VS Code' or 'Scad', respectively, without having to press the
return key.


[-- Attachment #2: 20231216_185914_import.png --]
[-- Type: image/png, Size: 36200 bytes --]

[-- Attachment #3: Type: text/plain, Size: 100 bytes --]


-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I attached a screenshot, using Vertico and Consult (although
  > the code I linked doesn't depend on any of those) to demonstrate what it
  > looks like. There, if you type '1' or '01' in your keyboard, you would
  > select 'VS Code' or 'Scad', respectively, without having to press the
  > return key.

Thanks.  Now I think I see what the issue is.

I don't have anything to say about it.  I'll leave it to you people.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Protesilaos Stavrou]

Hello folks!

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Thu,  7 Dec 2023 11:02:24 +0100
>
> Dear Emacs maintainers,
>
> I am writing to express my concern about a recent change in the
> behavior of the jump-to-register and point-to-register commands in the
> master branch (Bug#66394).

Please consider reinstating 'register-preview-delay'. Set the value to
no delay by default, if needed. The optional delay was a nice feature
because you could insert the same or a familiar register without having
to see the preview each time. All while retaining the preview buffer if
needed.

The 'register-use-preview' option does not seem to cover this use-case
anymore. We have the choice between an eager preview (in two varieties)
or none at all.

If this has already been covered, please ignore my message. I will find
the thread.

All the best,
Protesilaos (or simply "Prot")

-- 
Protesilaos Stavrou
https://protesilaos.com

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

[Alfred M. Szmidt]

As a data point, I think the existing behaviour of the preview popping
up after a delay was a very good addition, so setting it to 0 (no
delay) would be a regression.  But in a similar vein, removing the
delay completely is a bigger regression...

   Hello folks!

   > From: Tino Calancha <tino.calancha@gmail.com>
   > Date: Thu,  7 Dec 2023 11:02:24 +0100
   >
   > Dear Emacs maintainers,
   >
   > I am writing to express my concern about a recent change in the
   > behavior of the jump-to-register and point-to-register commands in the
   > master branch (Bug#66394).

   Please consider reinstating 'register-preview-delay'. Set the value to
   no delay by default, if needed. The optional delay was a nice feature
   because you could insert the same or a familiar register without having
   to see the preview each time. All while retaining the preview buffer if
   needed.

   The 'register-use-preview' option does not seem to cover this use-case
   anymore. We have the choice between an eager preview (in two varieties)
   or none at all.

   If this has already been covered, please ignore my message. I will find
   the thread.

   All the best,
   Protesilaos (or simply "Prot")

   -- 
   Protesilaos Stavrou
   https://protesilaos.com

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

[Stefan Kangas]

Protesilaos Stavrou <info@protesilaos.com> writes:

> Please consider reinstating 'register-preview-delay'. Set the value to
> no delay by default, if needed. The optional delay was a nice feature
> because you could insert the same or a familiar register without having
> to see the preview each time. All while retaining the preview buffer if
> needed.
>
> The 'register-use-preview' option does not seem to cover this use-case
> anymore. We have the choice between an eager preview (in two varieties)
> or none at all.

I'm a bit late to testing this stuff out, but I concur that a delay
before showing the preview seems useful.

As I said in Bug#66394, I also think that the preview should be ENABLED
by default.  With a delay, it will do even less to impact existing
workflows.

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

[Rudolf Adamkovič]

Tino Calancha <tino.calancha@gmail.com> writes:

> Unfortunately, the recent modification has introduced a requirement to
> press RET with every use, which has proven to be quite cumbersome for
> me.

+1 for no RET, not even on overwrite, by *default*.

In computer science and information technology, /register/ is a *quickly
accessible* location.  Remove its quickness, and the register ceases to
be a register, becoming just a "location".  In Emacs, registers are true
to their name and they should always stay so.

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."
--- Albert Einstein, 1879-1955

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Steve Perry]

Rudolf Adamkovič <salutis@me.com> writes:
>
> +1 for no RET, not even on overwrite, by *default*.

As a long time user of registers, I also find the current state
requiring extra RET keys to be very inconvenient, and I'm thankful for the
patches being offered that correct this.

I have no personal need for the preview behaviour but equally can see
how others may find it useful.  As long as there is an option to disable
the extra return key (and I don't mind what the default is - I'm all in
favour of better defaults for helping new users) then I will remain a
happy Emacs user.