Eli Zaretskii <
eliz@gnu.org> writes:
>> From: Mauro Aranda <
maurooaranda@gmail.com>
>> Date: Mon, 2 Sep 2019 08:16:21 -0300
>> Cc: Stefan Kangas <
stefan@marxist.se>,
3192@debbugs.gnu.org>>
>> >> + ;; Only stop displaying the message when the current message is our own.
>> >> + ;; This has the advantage of not clearing the echo area when
>> >> + ;; running after an error message was displayed. (Bug#3192)
>> >> + ((equal-including-properties tooltip-help-message (current-message))
>> >> (message nil)))))
>> >
>> > I think this will effectively disable tooltip messages in the echo
>> > area in too many situations.
>>
>> Sorry, I don't think I follow. The clause I propose would replace a
>> clause whose condition is `t'. So the new code would run, at most, in the
>> same cases that the current code, right? And the two clauses (the
>> current, and my proposed replace) call `message' with a nil argument, so
>> if there is some disabling, it is already happening, right?
>
> My point is that this fix is not as good as possible. I'm asking
> whether we can do better than this. If not, can you explain why not?
Apologies for not getting your point, then. See the last part of my
response, where a try to explain the situation the best I can.
>> But I can't figure out why this code (or the current code) would be
>> disabling tooltip messages. AFAIU, the case when there is some message
>> to show is already handled in the first of the clauses, with the
>> condition: (stringp help).
>
> If this is already handled, then why do we need this change at all?
> What use case does it handle that the current code doesn't?
Because it's handling a different case, the case where we got nil as the
argument, indicating us that we should stop showing a tooltip message.
And we need a change, because there is a bug: The user cannot see an
error message because it is cleared by the `tooltip-show-help-non-mode'
function, and that shouldn't happen. It handles the situation were
there was an error message shown after a tooltip message, but before the
code gets a chance to clear the tooltip message from the echo area.
IOW, when an error message is shown in-between the showing/hiding
mechanism of the tooltip code.
>> > How about if we show the tooltip in these cases for only some short
>> > enough period of time, like 2 sec, and then restore the original
>> > contents of the echo area?
>>
>> There should be no tooltip message to show, because this condition would
>> be reached if HELP is nil. (HELP might be either a string or nil, just
>> like in `tooltip-show-help' function). So I think when the two
>> previous conditions were not meet, it indicates that it is time to clear
>> the echo area. But we shouldn't do that unconditionally, only when the
>> current message is that of a tooltip.
>
> Then I guess I didn't understand your analysis of the original use
> case and what happens there. Could you perhaps describe that use case
> in more detail?
>
> Thanks.
`tooltip-show-help-non-mode' should handle two situations: 1) when there
is a message to show, show it; 2) when there is no message to show,
hide it.
Both situations are distinguished by the type of the argument. For the
1st case, the argument is a string; for the 2nd case the argument is
nil.
Additionally, it needs to save the previous message shown (if it is not
a tooltip one), to restore it when transitioning from the 1st case to
the 2nd case. This previous message shown can be, again, either a
string or nil, with nil meaning there was no previous message shown.
So far so good, let's go to the implementation. In order:
1) If the argument is a string, then show the message. If the previous
message shown was not a tooltip one (e.g., it is an error message), save
it, to restore it later.
This is the only chance that `tooltip-show-help-non-mode' gets to store
the perhaps present error message. This is very important.
2) If the argument is not a string, then we should stop showing the
tooltip message. But what should we show?
The previous message, that we stored in the 1st case. And if we didn't
store a string as a previous message, we have nothing to restore, so we
clear the echo area with a (message nil) call.
With that in mind, we can see when this bugs shows up:
The bug shows up when something happens between transitioning from the
1st case to the 2nd case. In the recipe provided, there is an error
echoed, that `tooltip-show-help-non-mode' can't grab because it ran
the 1st case before the error. And because it didn't store anything,
when running the 2nd case it clears clears the echo area. This has the
consequence of not letting the user see the error message.
So what I suggest is making `tooltip-show-help-non-mode' a little more
careful when clearing the echo area. That is, clear the echo area only
if we are certain that the last message shown was ours.
To finally answer your first question, I couldn't find a better fix for
this. I didn't see any drawbacks, and I'm certain it improves the
situation, so I proposed it.
Does my explanation make sense to you? If it is not enough,
would you explain to me what do you expect the fix to accomplish?