GNU bug report logs - #27647
26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

Previous Next

Package: emacs;

Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>

Date: Mon, 10 Jul 2017 20:55:02 UTC

Severity: normal

Tags: patch

Found in version 26.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #168 received at 27647 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27647 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com, agrambot <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#27647: 26.0.50; Line numbers implemented natively disappear
 momentarily when frame out of focus
Date: Mon, 13 Nov 2017 19:45:40 +0100
> Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
> then tip_frame will get its simple semantics back.

x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip.

> 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?

IIUC GTK doesn't need the original frame.  But it sets tooltip_frame to
it so Fx_show_tip and friends can base their decisions on it.  Look at
occurrences of FRAMEP (tip_frame) and FRAME_LIVE_P (XFRAME (tip_frame)).
They pass because for GTK tip_frame is a live frame associated with the
tooltip.  Jan tried hard to leave the native tooltip code untouched.

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

I don't dislike the timer.  I dislike the idea to put it on a frame
parameter.

>> but maybe there really is no better solution.
>
> Sorry, I refuse to believe that.

Where would you put it?

>> 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?

Simply because I don't know whether the rest is more complex than what's
needed to fix the mess.

martin




This bug report was last modified 7 years and 244 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.