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 18:39:57 +0200 Message-ID: <83lgj4hnaa.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> <837eupiclf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510936831 14200 195.159.176.226 (17 Nov 2017 16:40:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Nov 2017 16:40:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 17 17:40:28 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 1eFjgm-00034H-4F for ged-emacs-devel@m.gmane.org; Fri, 17 Nov 2017 17:40:24 +0100 Original-Received: from localhost ([::1]:46771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFjgq-0001s5-BI for ged-emacs-devel@m.gmane.org; Fri, 17 Nov 2017 11:40:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFjgh-0001rz-4n for emacs-devel@gnu.org; Fri, 17 Nov 2017 11:40:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFjgc-0003gj-4R for emacs-devel@gnu.org; Fri, 17 Nov 2017 11:40:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFjgb-0003gc-OQ; Fri, 17 Nov 2017 11:40:13 -0500 Original-Received: from [176.228.60.248] (port=3042 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFjgb-0002D1-4P; Fri, 17 Nov 2017 11:40:13 -0500 In-reply-to: (message from Stefan Monnier on Fri, 17 Nov 2017 10:58:57 -0500) 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:220253 Archived-At: > From: Stefan Monnier > Date: Fri, 17 Nov 2017 10:58:57 -0500 > > > 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. > > If we really wanted, we could implement some kind of tooltips in > a similar way, tho: > > - overwrite parts of the glyph matrix > - register some "pre-redisplay hook" > - return to the normal command loop > > the "pre-redisplay hook" would then remove the tooltip-overwrite from the > glyph matrix before the redisplay bumps into it. Then if we want the > tooltip to last longer than "until the next redisplay" (which sounds > rather likely), we'd need some way to re-add the tooltip after the > redisplay is done. > > Sounds pretty ugly/messy, obviously. Not only that, it probably won't work without much more ugliness to support it. > A more general solution could be to add two more glyph matrices (one for > overlay thingies like menus and tooltips, and another that combines the > "normal" glyph matrix with the one for overlay thingies (and it's this > one which is then sent to be displayed)). I don't see how this solves the problem, because the display engine will still know nothing about that "second" matrix. The only way to make TTY menus a first-class display citizen is to come up with some object which the display engine would routinely consult in deciding what to display in a window. Right now, it consults the text of the buffer pointed to by the window, and any Lisp strings related to the buffer. We need something else to add to this soup, and the problem with that something is that it spans several lines, but only part of each line. Maybe it should be modeled on the mouse-highlight, with the assumption of a rectangular region added...