From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <83o9o7n2y8.fsf@gnu.org> References: <83eftnitpj.fsf@gnu.org> <87inekjzy8.fsf@gmail.com> <87efp8jznq.fsf@gmail.com> <87shdo4150.fsf@users.sourceforge.net> <5A0403B7.3080309@gmx.at> <83shdnqwbw.fsf@gnu.org> <5A049A30.5000802@gmx.at> <83a7zvqilp.fsf@gnu.org> <5A081D9C.1000602@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510486628 16587 195.159.176.226 (12 Nov 2017 11:37:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Nov 2017 11:37:08 +0000 (UTC) Cc: 27647@debbugs.gnu.org, npostavs@users.sourceforge.net, agrambot@gmail.com, kaushal.modi@gmail.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 12 12:37:04 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDqZS-00040w-PF for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 Nov 2017 12:37:02 +0100 Original-Received: from localhost ([::1]:48781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDqZa-0005cK-1O for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 Nov 2017 06:37:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDqZT-0005c4-MV for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2017 06:37:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDqZS-0005Qm-LS for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2017 06:37:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55639) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDqZS-0005Qg-H4 for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2017 06:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eDqZS-00043P-Be for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2017 06:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Nov 2017 11:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27647 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27647-submit@debbugs.gnu.org id=B27647.151048661815572 (code B ref 27647); Sun, 12 Nov 2017 11:37:02 +0000 Original-Received: (at 27647) by debbugs.gnu.org; 12 Nov 2017 11:36:58 +0000 Original-Received: from localhost ([127.0.0.1]:36087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDqZN-000436-Q7 for submit@debbugs.gnu.org; Sun, 12 Nov 2017 06:36:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDqZM-00042t-Fr for 27647@debbugs.gnu.org; Sun, 12 Nov 2017 06:36:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDqZG-0005GR-DN for 27647@debbugs.gnu.org; Sun, 12 Nov 2017 06:36:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDqZB-000592-8z; Sun, 12 Nov 2017 06:36:45 -0500 Original-Received: from [176.228.60.248] (port=3867 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eDqZA-00060o-Fi; Sun, 12 Nov 2017 06:36:44 -0500 In-reply-to: <5A081D9C.1000602@gmx.at> (message from martin rudalics on Sun, 12 Nov 2017 11:08:28 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:139798 Archived-At: > Date: Sun, 12 Nov 2017 11:08:28 +0100 > From: martin rudalics > 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?