all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: thievol@posteo.net, kun.liu@gmail.com, 67702@debbugs.gnu.org
Subject: bug#67702: 30.0.50; insert-register can no longer be used in minibuffer
Date: Fri, 08 Dec 2023 09:27:22 +0100	[thread overview]
Message-ID: <m1v899f6ad.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <837clp167l.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Dec 2023 09:52:46 +0200")

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	other threads:[~2023-12-08  8:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 22:33 bug#67702: 30.0.50; insert-register can no longer be used in minibuffer Kun Liu
2023-12-08  6:32 ` Eli Zaretskii
2023-12-08  7:04   ` Thierry Volpiatto
2023-12-08  7:14     ` Thierry Volpiatto
2023-12-08  7:15     ` Eli Zaretskii
2023-12-08  7:31       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-08  7:52         ` Eli Zaretskii
2023-12-08  8:27           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-12-08  8:51             ` Eli Zaretskii
2023-12-08  9:07               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-08 10:23               ` Thierry Volpiatto
2023-12-08 10:16             ` Thierry Volpiatto
2023-12-08 10:40               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-08 12:00               ` Eli Zaretskii
2023-12-08 12:11                 ` Thierry Volpiatto
2023-12-08 12:39                 ` Thierry Volpiatto
2023-12-08 12:40                 ` Thierry Volpiatto
2023-12-08 16:37                   ` Thierry Volpiatto
2023-12-08  8:46           ` Thierry Volpiatto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1v899f6ad.fsf@dazzs-mbp.home \
    --to=bug-gnu-emacs@gnu.org \
    --cc=67702@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=kun.liu@gmail.com \
    --cc=me@eshelyaron.com \
    --cc=thievol@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.