From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 27647@debbugs.gnu.org, npostavs@users.sourceforge.net,
agrambot@gmail.com, kaushal.modi@gmail.com
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 [thread overview]
Message-ID: <83o9o7n2y8.fsf@gnu.org> (raw)
In-Reply-To: <5A081D9C.1000602@gmx.at> (message from martin rudalics on Sun, 12 Nov 2017 11:08:28 +0100)
> 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?
next prev parent reply other threads:[~2017-11-12 11:36 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 20:52 bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus Kaushal Modi
2017-07-11 2:38 ` Eli Zaretskii
2017-07-11 3:43 ` Kaushal Modi
2017-07-11 14:31 ` Eli Zaretskii
2017-07-11 14:38 ` Kaushal Modi
2017-07-11 20:08 ` Kaushal Modi
2017-07-12 14:44 ` Eli Zaretskii
2017-07-19 15:13 ` Kaushal Modi
2017-07-19 17:34 ` Eli Zaretskii
2017-07-19 17:52 ` Noam Postavsky
2017-07-19 18:09 ` Eli Zaretskii
2017-10-05 12:40 ` Kaushal Modi
2017-10-05 13:03 ` jonas
2017-10-05 13:10 ` Eli Zaretskii
2017-10-05 13:39 ` Eli Zaretskii
2017-10-05 22:17 ` Romanos Skiadas
2017-10-06 8:57 ` Eli Zaretskii
2017-10-11 20:32 ` Romanos Skiadas
2017-10-12 8:29 ` Eli Zaretskii
2017-10-12 19:30 ` Romanos Skiadas
2017-10-13 8:33 ` Eli Zaretskii
2017-10-13 18:14 ` Romanos Skiadas
2017-10-14 7:47 ` Eli Zaretskii
2017-10-15 15:05 ` Romanos Skiadas
2017-10-14 8:36 ` martin rudalics
2017-10-14 10:12 ` Eli Zaretskii
2017-10-15 9:39 ` martin rudalics
2017-10-15 13:25 ` Kaushal Modi
2017-10-16 21:46 ` Kaushal Modi
2017-10-17 8:59 ` martin rudalics
2017-10-17 14:47 ` Eli Zaretskii
2017-10-17 15:07 ` Kaushal Modi
2017-10-17 15:13 ` Kaushal Modi
2017-10-17 16:48 ` Eli Zaretskii
2017-10-15 14:29 ` Eli Zaretskii
2017-11-08 20:08 ` Alex
2017-11-08 20:14 ` Alex
2017-11-09 2:49 ` Noam Postavsky
2017-11-09 7:28 ` martin rudalics
2017-11-09 15:57 ` Eli Zaretskii
2017-11-09 18:10 ` martin rudalics
2017-11-09 20:53 ` Eli Zaretskii
2017-11-12 10:08 ` martin rudalics
2017-11-12 11:36 ` Eli Zaretskii [this message]
2017-11-13 18:45 ` martin rudalics
2017-11-13 19:12 ` Eli Zaretskii
2017-11-14 9:52 ` martin rudalics
2017-11-14 15:47 ` Eli Zaretskii
2017-11-14 18:29 ` martin rudalics
2017-11-14 19:02 ` Eli Zaretskii
2017-11-15 9:22 ` martin rudalics
2017-11-15 10:05 ` martin rudalics
2017-11-18 11:42 ` Eli Zaretskii
2017-11-18 18:25 ` martin rudalics
2017-11-09 13:34 ` Kaushal Modi
2017-11-10 0:38 ` Noam Postavsky
2017-11-09 16:12 ` Eli Zaretskii
2017-11-09 18:14 ` Romanos Skiadas
2017-11-09 20:27 ` Eli Zaretskii
2017-11-10 0:11 ` Noam Postavsky
2017-11-10 8:37 ` Eli Zaretskii
2017-07-21 17:49 ` bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, " jonas
2017-07-21 18:57 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83o9o7n2y8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=27647@debbugs.gnu.org \
--cc=agrambot@gmail.com \
--cc=kaushal.modi@gmail.com \
--cc=npostavs@users.sourceforge.net \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).