From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#3192: 23.0.92; disabling tooltip-mode inhibits showing Customize error msgs Date: Sat, 7 Sep 2019 18:14:00 -0300 Message-ID: References: <001e01c9cb3a$a4f4ad10$0200a8c0@us.oracle.com> <83k1as8681.fsf@gnu.org> <83ef0s5t38.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000050fcd50591fd09e2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="208778"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Kangas , 3192@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 07 23:15:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i6i38-000sAN-PU for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Sep 2019 23:15:15 +0200 Original-Received: from localhost ([::1]:37188 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6i37-00010B-Cp for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Sep 2019 17:15:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44292) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i6i2y-0000zM-AO for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2019 17:15:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i6i2w-0000F7-BM for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2019 17:15:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57567) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i6i2w-0000F3-8N for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2019 17:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i6i2w-0001Ll-2S for bug-gnu-emacs@gnu.org; Sat, 07 Sep 2019 17:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Sep 2019 21:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 3192 X-GNU-PR-Package: emacs Original-Received: via spool by 3192-submit@debbugs.gnu.org id=B3192.15678908625089 (code B ref 3192); Sat, 07 Sep 2019 21:15:02 +0000 Original-Received: (at 3192) by debbugs.gnu.org; 7 Sep 2019 21:14:22 +0000 Original-Received: from localhost ([127.0.0.1]:38152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i6i2H-0001Jz-Dh for submit@debbugs.gnu.org; Sat, 07 Sep 2019 17:14:22 -0400 Original-Received: from mail-lj1-f180.google.com ([209.85.208.180]:34829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i6i2E-0001Jc-Ji for 3192@debbugs.gnu.org; Sat, 07 Sep 2019 17:14:19 -0400 Original-Received: by mail-lj1-f180.google.com with SMTP id q22so4564736ljj.2 for <3192@debbugs.gnu.org>; Sat, 07 Sep 2019 14:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0+alz3y+OrJqrSHpM9Jry5gkkHM0IFyK3j7a+jHNvQ=; b=N2pmj8n3eKZhvZeNKZnTY4EVlBefynAAJwJ1RVoVNEaeERqkGenqEVbMhwLk+4XOhm RIoIWk2Mr7s/z2nFoCEUp7OlfjFrcJiIj+gf8jJpyNknMOaoYBrpD0a8xPXMH9Tv8LG5 fW8D09yLjE9CqCOdQPnOndpeRZtTfQ3fMTM4yq3TWW8yb7gRFsgEAHK1KOl+QT3YJ14U MGjhIezP8EMre/I4wI4v2UrWWG4UxADbwGv5YsOYEfBT52gwA1R0RhRQAJRj/qnf7RcX o0n9gAyyu8FBdM+0O0+oUjqCKAp8LHUjtcO4aO4kUpzSJyd3fpz4Wam43rDM04Tm2HpZ fyjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O0+alz3y+OrJqrSHpM9Jry5gkkHM0IFyK3j7a+jHNvQ=; b=ZJ9//+KICyXO1jsbaj9TYft/GRdECUfPMzXrd4UUDPSO1kvrkbN8hjld3BkYzbF642 yujhz8cCqV4l6664GjqZKgWeKE6mkagV8ZYunojb/r0lTLLKch4bXgkKnrvalns8DM04 cPD2Wd84fyKf/1XhUjfMaherlu5f4oodpur30kiQxVTqnG04KK5yhLCZ8Q2KHHZURN/c A+G90tEAL3pkz5SLfOS5WhuQC4ihJFHfPmle4XBxo2anR1aADqnvPIt5BKmzof+I1of2 xnFeOEMK3LCOG+9V54kTWW+dXFqHSGqLKAuF+TOH7cKCwWKB7UDTIn/0YbIuskzBZrsN 7OUg== X-Gm-Message-State: APjAAAV7et14iXcK+sod/+FJ8PfU3po2gNELjyXsvSIU8i/faBrqTn21 6/fgw0c3Q9ZPoyyEIgurp7Sriow9nhQjPHrT9I8= X-Google-Smtp-Source: APXvYqy1QDb1ULqYkSbPyh7+Z/xY11+DPSCYELuFhKCts0fl1IMkYtf01igN9+WCQgFeV9crNLajhVSwas4x3ux7guI= X-Received: by 2002:a2e:9d0d:: with SMTP id t13mr3545555lji.169.1567890852607; Sat, 07 Sep 2019 14:14:12 -0700 (PDT) In-Reply-To: <83ef0s5t38.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166281 Archived-At: --00000000000050fcd50591fd09e2 Content-Type: text/plain; charset="UTF-8" Eli Zaretskii writes: >> From: Mauro Aranda >> Date: Mon, 2 Sep 2019 08:16:21 -0300 >> Cc: Stefan Kangas , 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? --00000000000050fcd50591fd09e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mauro Aranda= <maurooaran= da@gmail.com>
>> Date: Mon, 2 Sep 2019 08:16:21 -0300
&g= t;> Cc: Stefan Kangas <stefan@marxist.se>, 3192@debbugs.gnu.org
>>
>> >&g= t; + =C2=A0 =C2=A0 ;; Only stop displaying the message when the current mes= sage is our own.
>> >> + =C2=A0 =C2=A0 ;; This has the advan= tage of not clearing the echo area when
>> >> + =C2=A0 =C2= =A0 ;; running after an error message was displayed. =C2=A0(Bug#3192)
&g= t;> >> + =C2=A0 =C2=A0 ((equal-including-properties tooltip-help-m= essage (current-message))
>> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0(= message nil)))))
>> >
>> > I think this will effect= ively disable tooltip messages in the echo
>> > area in too man= y situations.
>>
>> Sorry, I don't think I follow.= =C2=A0 The clause I propose would replace a
>> clause whose condit= ion is `t'.=C2=A0 So the new code would run, at most, in the
>>= ; same cases that the current code, right?=C2=A0 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 happenin= g, right?
>
> My point is that this fix is not as good as possi= ble.=C2=A0 I'm asking
> whether we can do better than this.=C2=A0= If not, can you explain why not?

Apologies for not getting your poi= nt, then.=C2=A0 See the last part of my
response, where a try to explain= the situation the best I can.

>> But I can't figure out w= hy this code (or the current code) would be
>> disabling tooltip m= essages.=C2=A0 AFAIU, the case when there is some message
>> to sh= ow is already handled in the first of the clauses, with the
>> con= dition: (stringp help).
>
> If this is already handled, then wh= y 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 s= hould stop showing a tooltip message.
And we need a change, because ther= e is a bug: The user cannot see an
error message because it is cleared b= y the `tooltip-show-help-non-mode'
function, and that shouldn't = happen.=C2=A0 It handles the situation were
there was an error message s= hown 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 s= hown in-between the showing/hiding
mechanism of the tooltip code.
>> > How about if we show the tooltip in these cases for only som= e short
>> > enough period of time, like 2 sec, and then restor= e 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. =C2=A0(HELP might be either a= string or nil, just
>> like in `tooltip-show-help' function).= =C2=A0 So I think when the two
>> previous conditions were not mee= t, it indicates that it is time to clear
>> the echo area.=C2=A0 B= ut we shouldn't do that unconditionally, only when the
>> curr= ent message is that of a tooltip.
>
> Then I guess I didn't= understand your analysis of the original use
> case and what happens= there.=C2=A0 Could you perhaps describe that use case
> in more deta= il?
>
> Thanks.

`tooltip-show-help-non-mode' should = handle two situations: 1) when there
is a message to show, show it; 2) w= hen there is no message to show,
hide it.

Both situations are dis= tinguished by the type of the argument.=C2=A0 For the
1st case, the argu= ment is a string; for the 2nd case the argument is
nil.

Additiona= lly, 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 cas= e.=C2=A0 This previous message shown can be, again, either a
string or n= il, with nil meaning there was no previous message shown.

So far so = good, let's go to the implementation.=C2=A0 In order:
1) If the argu= ment is a string, then show the message.=C2=A0 If the previous
message s= hown was not a tooltip one (e.g., it is an error message), save
it, to r= estore it later.
This is the only chance that `tooltip-show-help-non-mod= e' gets to store
the perhaps present error message.=C2=A0 This is ve= ry important.

2) If the argument is not a string, then we should sto= p showing the
tooltip message.=C2=A0 But what should we show?
The pre= vious message, that we stored in the 1st case.=C2=A0 And if we didn'tstore a string as a previous message, we have nothing to restore, so weclear the echo area with a (message nil) call.


With that in mi= nd, 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.=C2=A0 I= n 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 err= or.=C2=A0 And because it didn't store anything,
when running the 2nd= case it clears clears the echo area.=C2=A0 This has the
consequence of = not letting the user see the error message.

So what I suggest is mak= ing `tooltip-show-help-non-mode' a little more
careful when clearing= the echo area.=C2=A0 That is, clear the echo area only
if we are certai= n that the last message shown was ours.


To finally answer your f= irst question, I couldn't find a better fix for
this.=C2=A0 I didn&#= 39;t see any drawbacks, and I'm certain it improves the
situation, s= o I proposed it.

Does my explanation make sense to you? If it i= s not enough,
would you explain to me what do you expect the fix = to accomplish?
--00000000000050fcd50591fd09e2--