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

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

bug#67702: 30.0.50; insert-register can no longer be used in minibuffer


From: Eshel Yaron
Subject: bug#67702: 30.0.50; insert-register can no longer be used in minibuffer
Date: Fri, 08 Dec 2023 09:27:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>>
>> >> > I guess register-read-with-preview should temporarily bind
>> >> > enable-recursive-minibuffers to a non-nil value?
>> >>
>> >> Yes, do you want me to install this change?
>> >
>> > If you think that's the correct solution, sure.
>>
>> FWIW, I think it's not the right solution.  As I wrote in bug#66394, I
>> think it's wrong to involve the minibuffer in reading registers in any
>> way.  `enable-recursive-minibuffers` would make this less broken, but
>> only slightly.
>
> I'm not sure I understand: if we put aside the fundamental opposition
> to using read-from-minibuffer, what problems will be left if we
> temporarily enable recursive-minibuffers while prompting for the
> register?

Concretely this is still worse because starting a recursive minibuffer
hides the previous minibuffer.  So you no longer see what you're
operating on.  There are other problems that I mentioned in bug#66394,
and there's also the disadvantage that `read-from-minibuffer` switches
windows, which is redundant in this case.

>> It's up to you maintainers to decide, I think.  Following your request,
>> I've proposed a patch that reverts Thierry's changes, and implements the
>> parts I find useful in a clean and backward compatible way.
>
> Thierry said your patch was incomplete.

Well, I requested some elaboration on that comment.  Still waiting.

> And I wonder why we need to completely revert his changes.  My
> suggestion was to allow both, controlled by user option.

That's basically what my patch does, it even makes Thierry's preferred
behavior (confirmation before overwriting registers) the default, it
just doesn't use the minibuffer for that.  AFAIU the goal of Thierry's
patch wasn't to use the minibuffer, that's an implementation detail, one
with problematic consequences.

> Then we could see what users prefer, and make the decision: whether to
> keep both or just one, and which one.  I very much prefer this path
> forward than continuing to argue now which of the two ways is the only
> one that's correct.

>> > If it's unrelated, then please go ahead and install your changes in
>> > that discussion.  In any case, perhaps you could help Eshel improve
>> > and polish his additions, which AFAIU are supposed to provide an
>> > optional behavior more similar to the previous one.
>>
>> That'd be nice, thanks.
>
> Agreed.  But again: please consider reworking your patch such that it
> allows using the minibuffer as optional behavior.  After all, using
> the minibuffer has also advantages, not just disadvantages.

I don't see these advantages.  Again, I think this is just an
implementation detail, and my patch provides a better implementation.
If someone would spell out these advantages, I could look into it when I
have the time.


Eshel





reply via email to

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