[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: |
Eli Zaretskii |
Subject: |
bug#38457: 27.0.50; dabbrev-expand regression due to message change |
Date: |
Sun, 15 Dec 2019 17:35:22 +0200 |
> From: Juri Linkov <juri@linkov.net>
> Cc: 38457@debbugs.gnu.org
> Date: Sun, 15 Dec 2019 01:10:58 +0200
>
> > 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?
What I had in mind was to go with your idea, viz.:
> 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.
IOW, introduce a new option, which will affect the new function we
were talking about, a near-clone of minibuffer-message (and will not
affect minibuffer-message itself). When that new option's value is
not a number, the near-clone of minibuffer-message should not call
sit-for at all; and when that value is a number, use a timer to remove
the message after that many seconds if no input arrives before that.
In any case, I thought we agreed not to call minibuffer-message from
'message', but define a new function, similar but not identical to
minibuffer-message (what I call a "near-clone"). And
minibuffer-message-timeout should not affect that new function, it
should be a separate option.
> 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':
Do we still need such a hook if the idea above is implemented instead?
> > 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.
Thanks. Let's revisit these after the implementation of the
minibuffer-message's clone is finalized, so that we could know which
ones of these are still needed and which aren't.
- 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, 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, 2019/12/14
- bug#38457: 27.0.50; dabbrev-expand regression due to message change,
Eli Zaretskii <=
- 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
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/17