[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38457: 27.0.50; dabbrev-expand regression due to message change
From: |
Juri Linkov |
Subject: |
bug#38457: 27.0.50; dabbrev-expand regression due to message change |
Date: |
Sun, 15 Dec 2019 01:10:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>> > 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.
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, (continued)
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/11
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/11
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/12
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Dmitry Gutov, 2019/12/12
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/12
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/13
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/11
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/12
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/12
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/13
- bug#38457: 27.0.50; dabbrev-expand regression due to message change,
Juri Linkov <=
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/15
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/15
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Dmitry Gutov, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, HaiJun Zhang, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, HaiJun Zhang, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/17