From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: mouse-drag-and-drop-region Date: Fri, 17 Nov 2017 09:33:16 +0200 Message-ID: <837eupiclf.fsf@gnu.org> References: <5A0ABD41.5040402@gmx.at> <874lpwobsa.fsf@gmail.com> <5A0C0765.2040908@gmx.at> <87375fl3z1.fsf@gmail.com> <831skzjo2o.fsf@gnu.org> <87y3n7jj2y.fsf@gmail.com> <83r2syi5h6.fsf@gnu.org> <87r2sx4do3.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510904027 2508 195.159.176.226 (17 Nov 2017 07:33:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Nov 2017 07:33:47 +0000 (UTC) Cc: rudalics@gmx.at, tak.kunihiro@gmail.com, emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 17 08:33:40 2017 Return-path: Envelope-to: ged-emacs-devel@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 1eFb9d-0008R6-DD for ged-emacs-devel@m.gmane.org; Fri, 17 Nov 2017 08:33:37 +0100 Original-Received: from localhost ([::1]:44309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFb9i-0006Al-AB for ged-emacs-devel@m.gmane.org; Fri, 17 Nov 2017 02:33:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFb9b-0006AY-3f for emacs-devel@gnu.org; Fri, 17 Nov 2017 02:33:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFb9X-0006KA-Vk for emacs-devel@gnu.org; Fri, 17 Nov 2017 02:33:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFb9X-0006Js-Rn; Fri, 17 Nov 2017 02:33:31 -0500 Original-Received: from [176.228.60.248] (port=2701 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFb9X-0007GV-3g; Fri, 17 Nov 2017 02:33:31 -0500 In-reply-to: <87r2sx4do3.fsf@gmail.com> (message from Alex on Fri, 17 Nov 2017 00:33:48 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220244 Archived-At: > From: Alex > Cc: rudalics@gmx.at, tak.kunihiro@gmail.com, emacs-devel@gnu.org > Date: Fri, 17 Nov 2017 00:33:48 -0600 > > >> That sounds better. Though I wonder if tooltips could be shown in TTY > >> frames using a method similar to how `x-popup-menu' displays a menu in > >> them? > > > > No, it can't. TTY menus pre-empt the command loop, so they cannot be > > shown during mouse-tracking, AFAIR. > > I didn't mean to use menus directly, but to use a similar method of > displaying something "on top of" a TTY frame. Is displaying the > rectangle that makes up a menu necessarily incompatible with a regular > command loop? Yes, it is incompatible. > If so, do you know why? Because TTY menus are implemented by overwriting parts of the glyph matrix with text that comes "out of nowhere", as far as the normal redisplay is concerned. IOW, there's no buffer or display string or overlay string that the display engine knows about that produce this text. So if we let the command loop do its thing, it will eventually enter redisplay, and the menu will be erased, partially or fully. > > Does the flickering disappear if you set x-gtk-use-system-tooltips to > > nil? > > Yes, it appears that only GTK tooltips are affected here. Should I file > a bug report? Yes, of course. Though I doubt we have the expertise to fix it (or maybe it's even unfixable as long as we implement the GTK support the way we do). > >> There's also a side issue that subsequent mouse-movement events appear > >> to only be generated after moving a character rather than by a > >> configurable amount of pixels, which leads to the tooltip movement being > >> a bit jerky. > > > > If that, too, disappears when GTK tooltips are not used, then maybe > > it's due to the way we show GTK tooltips. > > I don't believe this one has to do with GTK. If you set `track-mouse' to > t, then, after the first pixel movement, you will only see > mouse-movement events when you move the mouse to a whole character > position. This might be intentional, but I think it's poor behaviour. Can you show a Lisp recipe to reproduce this?