bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27647: 26.0.50; Line numbers implemented natively disappear momentar


From: Eli Zaretskii
Subject: bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus
Date: Sun, 12 Nov 2017 13:36:47 +0200

> Date: Sun, 12 Nov 2017 11:08:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > Not if we always either put in that variable either the tooltip frame
>  > or nil, never any other frame.  IOW, if we make it an innocent
>  > variable with simple semantics again, and track the frame GTK needs
>  > "by other means".
> 
> If the semantics of tip_frame non-nil is
> 
> "The frame of a currently visible tooltip."
> 
> and for a GTK build the "currently visible tooltip" has no frame, then
> we have no simple semantics.  It means that for GTK we always need an
> additional test like that for a 'tooltip' frame parameter.  Don't you
> agree?

Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
then tip_frame will get its simple semantics back.  If GTK needs to
stash the original frame, to be used to hide the tooltip, it should
use a separate variable (or a struct frame member), also with simple
semantics.  Two variables with simple semantics are much better than
one with a subtly complex one.  Don't you agree?

>  > Maybe I'm missing something, but I don't understand why the changes
>  > for this have to be so complex and invasive.  But I'll review any
>  > specific proposal for fixing this mess.
> 
> He didn't want to change only "this".  His was a pretty comprehensive
> solution for many problems in this area.  The only thing I disliked was
> that 'tooltip-timer' parameter

That timer was at the base of the proposed solution, AFAIU.  So if you
dislike it, you dislike the idea itself.

> but maybe there really is no better solution.

Sorry, I refuse to believe that.

> Anyway, replacing the global variable and the frame parameter stuff
> by a one-bit per frame slot should be enough for fixing the mess at
> hand.

Exactly.  So why we need the rest of the complexity in that patch?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]