From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Layered display API Date: Wed, 13 Aug 2014 18:28:50 +0300 Message-ID: <83iolwif2l.fsf@gnu.org> References: <86tx5r7l1j.fsf@yandex.ru> <53E097F7.5050407@gmx.at> <53E0ABF9.7070506@yandex.ru> <8338dbqcai.fsf@gnu.org> <53E14AF4.6050804@yandex.ru> <83k36mpbxg.fsf@gnu.org> <53E22245.4070307@yandex.ru> <8361i5pmch.fsf@gnu.org> <53E294BD.1000500@yandex.ru> <837g2knwb2.fsf@gnu.org> <53E818F0.2080104@yandex.ru> <8361hzjciv.fsf@gnu.org> <53EAD0B1.1010405@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1407943759 26640 80.91.229.3 (13 Aug 2014 15:29:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2014 15:29:19 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 13 17:29:12 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XHaUB-0005cd-HI for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2014 17:29:11 +0200 Original-Received: from localhost ([::1]:48120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHaUA-0002QD-Pl for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2014 11:29:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHaU0-0002OU-0K for emacs-devel@gnu.org; Wed, 13 Aug 2014 11:29:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHaTt-0005jn-FV for emacs-devel@gnu.org; Wed, 13 Aug 2014 11:28:59 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:55195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHaTt-0005jf-1L for emacs-devel@gnu.org; Wed, 13 Aug 2014 11:28:53 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NA9002003NN2N00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 13 Aug 2014 18:23:51 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NA900KJX43R3G80@mtaout25.012.net.il>; Wed, 13 Aug 2014 18:23:51 +0300 (IDT) In-reply-to: <53EAD0B1.1010405@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173626 Archived-At: > Date: Wed, 13 Aug 2014 06:42:57 +0400 > From: Dmitry Gutov > CC: rudalics@gmx.at, emacs-devel@gnu.org > > On 08/11/2014 07:01 PM, Eli Zaretskii wrote: > > > Compare this with x-popup-menu: the similarity is striking. Which is > > why I suggested to use menus on TTYs. > > Yes, it would be nice if we can use them. However, the fact that menus > handle evens themselves (or try to) makes me think it's not the cleanest > approach. The menu code can be extended. More accurately, we could refactor the menu code to provide the capabilities of overlaying text on window display for other Lisp features. > > Given these requirements, I think the only 2 alternatives to implement > > them for GUI frames are: > > > > . tooltip frames, suitably beefed up <...> > > > > . some low-level graphics feature <...> > > > > Nothing else seems possible, because if we rely on the current display > > engine, we will be unable to fully control at least the vertical > > position of the lines in your popup, and in some cases (e.g., > > line-prefix) also the horizontal position. > > Not even menus? My understanding was they might be able to satisfy most > of the requirements, aside from working with proportional fonts. At least with some toolkits, GUI menus have decorations, which will look strange if we use them in this capacity. > >>> No, I meant conceal the text produced by other display properties, and > >>> display your overlay string instead. > >> > >> It doesn't seem to be solving much: if I want to display something in > >> the middle of, say, large `display' text, there's no specific span of > >> text to set that new property on. > > > > You'd put it on the overlay string. > > Let me rephrase the previous message: "...there's no specific span of > text to put the overlay on". The buffer text that is covered by the "large display property" is still there, right? It just isn't displayed. > Will the menu allow me to customize the keymap it's using? Of course! This is Emacs. See the end of menu-bar.el: the menu navigation keys are defined as a keymap. > > Same as above: exit the menu, do what you need, then redraw it. > > > >> Would that work via post-command-hook? > > > > No. The current menu code simply ignores any commands it wasn't > > programmed to understand and act upon. > > Ignores, or allows them to go through? Ignores. They are processed and produce no effect. > >> And? Suppose there are multiple minor modes in that buffer that might > >> like to handle that click? > > > > Again, fights like that should be resolved "by other means". > > In the buffer contents, they are resolved with buttons. Why not on the > fringe? I don't see how buttons can resolve conflicts. Maybe I'm missing something.