From: Juri Linkov <juri@linkov.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 38457@debbugs.gnu.org
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Sun, 15 Dec 2019 01:10:58 +0200 [thread overview]
Message-ID: <87a77uh5a5.fsf@mail.linkov.net> (raw)
In-Reply-To: <83d0cs8uw8.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 13 Dec 2019 10:57:59 +0200")
>> > That would mean bring back all the problems for which these changes
>> > were made. So it would be the worst of all worlds, and thus makes
>> > very little sense to me.
>>
>> Then your proposed implementation should be activated when
>> minibuffer-message-timeout is set to a non-nil value.
>> Otherwise, when it's a number, it should use the timer.
>
> That leaves open the issue of the default value of
> minibuffer-message-timeout. I don't think we can change it, because
> it affects minibuffer-message as well. But we could have a new
> option, which would affect only the duplicate function you mention
> below. If the new option by default makes the message stay until the
> next one or until user input, I think this would be an okay solution
> that satisfies everyone, at least for Emacs 27.
The main problem with 'minibuffer-message' is that it uses 'sit-for'.
If a new function will use the same 'sit-for' to detect when input is
available, then it will bring the same problems. Here's is an example
of the problems it causes: I call 'select-window' from 'post-command-hook'
to select an output window, but 'sit-for' delays selecting the window
for 2 seconds until 'execute-extended-command' finishes displaying
the message "You can run the command `%s' with %s" using 'sit-for'.
The output window becomes selected only after 2 seconds because
a customized function in 'post-command-hook' doesn't run earlier
than returning from 'sit-for' in 'execute-extended-command'.
'sit-for' is used in many places, but it's inappropriate for these tasks.
What is a possible replacement for 'sit-for'? For a delay of specified
seconds, one solution is to run a timer. But how to replace another
aspect of 'sit-for', namely an ability to stop when input is available?
There is a need for a hook that would be called when input is available.
Maybe such hook already exists, I don't know, I searched but found only
'echo-area-clear-hook' that is used in this code in 'command_loop_1':
if (minibuf_level
&& !NILP (echo_area_buffer[0])
&& EQ (minibuf_window, echo_area_window)
&& NUMBERP (Vminibuffer_message_timeout))
{
/* Bind inhibit-quit to t so that C-g gets read in
rather than quitting back to the minibuffer. */
ptrdiff_t count = SPECPDL_INDEX ();
specbind (Qinhibit_quit, Qt);
sit_for (Vminibuffer_message_timeout, 0, 2);
/* Clear the echo area. */
message1 (0);
safe_run_hooks (Qecho_area_clear_hook);
unbind_to (count, Qnil);
/* If a C-g came in before, treat it as input now. */
if (!NILP (Vquit_flag))
{
Vquit_flag = Qnil;
Vunread_command_events = list1i (quit_char);
}
}
This code looks very like 'minibuffer-message', and still uses 'sit_for'.
>> > And in any case, minibuffer-message already behaves differently: it
>> > logs the message in *Messages*, something it never did and is not
>> > documented, and you suggested another change, to make it start the
>> > debugger per debug-on-message. These change behavior of any direct
>> > callers of minibuffer-message in incompatible ways, something I don't
>> > think we have a good reason to do.
>>
>> I see no reason not to change minibuffer-message. But if you think
>> it should never change, let's create a duplicate function
>> message-in-minibuffer.
>
> Fine with me, as long as the duplicate is an internal function. Maybe
> that new internal function should be invoked from message3_nolog
> instead, btw? That would remove the need to duplicate the
> functionality of message_dolog.
>
> Assuming you agree, once this change is made, some of the recent
> changes related to these issues should be reverted. Can I ask you to
> review those related changesets and publish a list of those which need
> to be reverted or augmented?
Here's is a list of related changesets:
8693611136
aa89c84e00
54c792ece6
Please revert them if you want.
next prev parent reply other threads:[~2019-12-14 23:10 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 11:06 bug#38457: 27.0.50; dabbrev-expand regression due to message change Stephen Berman
2019-12-02 16:02 ` Eli Zaretskii
2019-12-02 23:00 ` Juri Linkov
2019-12-03 0:15 ` Stephen Berman
2019-12-03 3:36 ` Eli Zaretskii
2019-12-03 23:44 ` Juri Linkov
2019-12-04 3:38 ` Eli Zaretskii
2019-12-04 23:16 ` Juri Linkov
2019-12-05 3:43 ` Eli Zaretskii
2019-12-06 0:10 ` Juri Linkov
2019-12-06 7:44 ` Eli Zaretskii
2019-12-07 23:05 ` Juri Linkov
2019-12-08 3:28 ` Eli Zaretskii
2019-12-08 5:18 ` Eli Zaretskii
2019-12-08 21:50 ` Juri Linkov
2019-12-09 3:36 ` Eli Zaretskii
2019-12-09 7:43 ` Lars Ingebrigtsen
2019-12-09 14:00 ` Eli Zaretskii
2019-12-09 15:55 ` Eli Zaretskii
2019-12-11 7:32 ` Lars Ingebrigtsen
2019-12-11 7:35 ` Lars Ingebrigtsen
2019-12-11 16:30 ` Eli Zaretskii
2019-12-11 16:28 ` Eli Zaretskii
2019-12-24 16:30 ` Lars Ingebrigtsen
2019-12-24 17:50 ` Eli Zaretskii
2019-12-09 23:45 ` Juri Linkov
2019-12-10 3:36 ` Eli Zaretskii
2019-12-10 7:19 ` HaiJun Zhang
2019-12-10 16:11 ` Eli Zaretskii
2019-12-10 17:52 ` Drew Adams
2019-12-10 17:51 ` Drew Adams
2019-12-10 16:34 ` Eli Zaretskii
2019-12-10 17:08 ` Stefan Monnier
2019-12-10 17:49 ` Eli Zaretskii
2019-12-10 17:57 ` Eli Zaretskii
2019-12-10 23:45 ` Juri Linkov
2019-12-11 16:19 ` Eli Zaretskii
2019-12-11 17:34 ` Stefan Monnier
2019-12-11 17:50 ` Eli Zaretskii
2019-12-11 18:53 ` Stefan Monnier
2019-12-11 23:12 ` Juri Linkov
2019-12-12 4:39 ` Eli Zaretskii
2019-12-12 22:45 ` Juri Linkov
2019-12-13 8:25 ` Eli Zaretskii
2019-12-10 19:45 ` Stefan Monnier
2019-12-10 20:11 ` Eli Zaretskii
2019-12-10 21:45 ` Stefan Monnier
2019-12-11 3:24 ` HaiJun Zhang
2019-12-11 3:40 ` Eli Zaretskii
2019-12-11 3:59 ` HaiJun Zhang
2019-12-11 16:26 ` Eli Zaretskii
2019-12-12 4:33 ` HaiJun Zhang
2019-12-12 5:29 ` Eli Zaretskii
2019-12-12 22:58 ` Juri Linkov
2019-12-13 7:02 ` Eli Zaretskii
2019-12-13 9:07 ` Eli Zaretskii
2019-12-12 13:21 ` Stefan Monnier
2019-12-11 3:35 ` HaiJun Zhang
2019-12-11 16:11 ` Eli Zaretskii
2019-12-11 16:42 ` Eli Zaretskii
2019-12-11 23:24 ` Juri Linkov
2019-12-12 5:36 ` Eli Zaretskii
2019-12-12 11:08 ` Dmitry Gutov
2019-12-12 23:07 ` Juri Linkov
2019-12-13 8:46 ` Eli Zaretskii
2019-12-11 23:28 ` Juri Linkov
2019-12-12 5:41 ` Eli Zaretskii
2019-12-12 23:12 ` Juri Linkov
2019-12-13 8:57 ` Eli Zaretskii
2019-12-14 23:10 ` Juri Linkov [this message]
2019-12-15 15:35 ` Eli Zaretskii
2019-12-15 23:59 ` Juri Linkov
2019-12-16 16:09 ` Eli Zaretskii
2019-12-16 22:29 ` Juri Linkov
2019-12-16 23:26 ` Dmitry Gutov
2019-12-17 6:27 ` HaiJun Zhang
2019-12-17 16:19 ` Eli Zaretskii
2019-12-17 23:53 ` Juri Linkov
2019-12-18 3:38 ` HaiJun Zhang
2019-12-17 16:11 ` Eli Zaretskii
2019-12-17 23:51 ` Juri Linkov
2019-12-18 16:24 ` Eli Zaretskii
2019-12-19 0:12 ` Juri Linkov
2019-12-19 15:36 ` Eli Zaretskii
2019-12-19 22:16 ` Juri Linkov
2019-12-19 22:30 ` Dmitry Gutov
2019-12-19 23:17 ` Juri Linkov
2019-12-20 7:34 ` Eli Zaretskii
2019-12-19 22:52 ` Juri Linkov
2019-12-20 7:59 ` Eli Zaretskii
2019-12-21 22:09 ` Juri Linkov
2019-12-20 7:54 ` Eli Zaretskii
2019-12-21 22:02 ` Juri Linkov
2019-12-22 19:02 ` Eli Zaretskii
2019-12-20 14:29 ` Dmitry Gutov
2019-12-21 22:03 ` Juri Linkov
2019-12-23 10:10 ` Dmitry Gutov
2019-12-23 22:58 ` Juri Linkov
2019-12-24 0:42 ` Dmitry Gutov
2019-12-24 23:47 ` Juri Linkov
2019-12-25 16:30 ` Dmitry Gutov
2019-12-25 16:44 ` Eli Zaretskii
2019-12-25 16:49 ` Dmitry Gutov
2020-01-18 0:59 ` Dmitry Gutov
2020-01-18 8:19 ` Eli Zaretskii
2020-01-20 12:30 ` Dmitry Gutov
2020-01-21 16:15 ` Eli Zaretskii
2020-01-22 0:46 ` Dmitry Gutov
2020-01-18 1:00 ` Dmitry Gutov
2019-12-05 15:24 ` Kévin Le Gouguec
2019-12-05 16:36 ` Eli Zaretskii
2019-12-06 0:06 ` Juri Linkov
2019-12-06 7:41 ` Eli Zaretskii
2019-12-06 17:15 ` Kévin Le Gouguec
[not found] <<8736e3vve8.fsf@gmx.net>
[not found] ` <<8736e2coyv.fsf@mail.linkov.net>
[not found] ` <<83y2vujd0y.fsf@gnu.org>
[not found] ` <<87blspm0sm.fsf@mail.linkov.net>
[not found] ` <<837e3ckbem.fsf@gnu.org>
[not found] ` <<871rtjn0kt.fsf@mail.linkov.net>
[not found] ` <<83lfrrigj8.fsf@gnu.org>
[not found] ` <<87eexiqps5.fsf@mail.linkov.net>
[not found] ` <<83lfrphp94.fsf@gnu.org>
[not found] ` <<87wob7g2jk.fsf@mail.linkov.net>
[not found] ` <<83k177ebs0.fsf@gnu.org>
[not found] ` <<AE02ADC8-6567-4EB1-8A44-E60BC4B5807A@gnu.org>
[not found] ` <<87muc27prn.fsf@mail.linkov.net>
[not found] ` <<83tv6acgq5.fsf@gnu.org>
[not found] ` <<87eexdoygh.fsf@mail.linkov.net>
[not found] ` <<83tv68c0nb.fsf@gnu.org>
[not found] ` <<83h828b0lz.fsf@gnu.org>
2019-12-10 17:53 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a77uh5a5.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=38457@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).