all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stephen Berman 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: jpw@gnu.org, juri@linkov.net, me@eshelyaron.com,
	basil@contovou.net, 71927@debbugs.gnu.org,
	kickingvegas@gmail.com
Subject: bug#71927: 29.4; ibuffer-do-isearch and ibuffer-do-isearch-regexp not prompting for input
Date: Thu, 04 Jul 2024 15:32:05 +0200	[thread overview]
Message-ID: <874j95706i.fsf@gmx.net> (raw)
In-Reply-To: <86v81l8gnj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Jul 2024 15:50:56 +0300")

On Thu, 04 Jul 2024 15:50:56 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eshel Yaron <me@eshelyaron.com>,  kickingvegas@gmail.com,
>>   71927@debbugs.gnu.org,  basil@contovou.net,  jpw@gnu.org,
>>   juri@linkov.net
>> Date: Thu, 04 Jul 2024 12:06:40 +0200
>>
>> >> FWIW, AFAICT everything is working correctly, it's just that the
>> >> "Operation finished" message hides the prompt.  ibuffer-do-isearch
>> >> should tell define-ibuffer-op not to display that message, somehow.
>> >
>> > I don't see how this could be considered "correct": the "Operation
>> > finished" message is supposed to be shown only after the Isearch is
>> > finished in all the marked buffer, not before.  It looks like we need
>> > a function that will not return until all the buffers where searched,
>> > because that's what define-ibuffer-op expects.  Don't you agree?
>>
>> The attached patch appears to DTRT, but I only tested it briefly.
>
> Thanks, but does it really make sense to change define-ibuffer-op to
> fix the functions which (evidently) use it incorrectly?  I think the
> fix needs to be in the same place where the bug is.

That's what I thought, too, but I don't see a way to do that, because
define-ibuffer-op hard-codes displaying a message at the end of the
body.  But in this case that message seems superfluous, in addition to
hiding the isearch prompt, because when isearch goes through the marked
buffers, it then displays its own message that the operation is
complete.  So this looks like a case when define-ibuffer-op is currently
too rigid.  However, I acknowledge that I don't really grok the
interaction with isearch, i.e., why the "Operation finished" message is
shown although isearch hasn't even begun.  But AFAICS suppressing the
message as in the patch does allow isearch to proceed and complete as
usual.

Steve Berman





  reply	other threads:[~2024-07-04 13:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03 21:25 bug#71927: 29.4; ibuffer-do-isearch and ibuffer-do-isearch-regexp not prompting for input Charles Choi
2024-07-04  6:58 ` Juri Linkov
2024-07-04  7:55   ` Eli Zaretskii
2024-07-04  7:12     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-04  9:59       ` Eli Zaretskii
2024-07-04 10:06         ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-04 12:50           ` Eli Zaretskii
2024-07-04 13:32             ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-07-04 14:12               ` Eli Zaretskii
2024-07-04 15:09                 ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-04 16:04           ` Juri Linkov
2024-07-04 17:36             ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-04 18:07               ` Eli Zaretskii
2024-07-04 18:29                 ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-04 18:46                   ` Eli Zaretskii
2024-07-06 21:13                     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-07 16:59                       ` Juri Linkov
2024-07-12  7:03                       ` Eli Zaretskii
2024-07-12 10:20                         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-12 17:05                           ` Charles Choi

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=874j95706i.fsf@gmx.net \
    --to=bug-gnu-emacs@gnu.org \
    --cc=71927@debbugs.gnu.org \
    --cc=basil@contovou.net \
    --cc=eliz@gnu.org \
    --cc=jpw@gnu.org \
    --cc=juri@linkov.net \
    --cc=kickingvegas@gmail.com \
    --cc=me@eshelyaron.com \
    --cc=stephen.berman@gmx.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.