From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Layered display API Date: Wed, 13 Aug 2014 06:42:57 +0400 Message-ID: <53EAD0B1.1010405@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1407897812 8279 80.91.229.3 (13 Aug 2014 02:43:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2014 02:43:32 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 13 04:43:25 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 1XHOX6-0005dK-1K for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2014 04:43:24 +0200 Original-Received: from localhost ([::1]:44692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHOX5-0004kk-IV for ged-emacs-devel@m.gmane.org; Tue, 12 Aug 2014 22:43:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHOWt-0004ja-PQ for emacs-devel@gnu.org; Tue, 12 Aug 2014 22:43:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHOWk-0004iu-Mm for emacs-devel@gnu.org; Tue, 12 Aug 2014 22:43:11 -0400 Original-Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:33146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHOWk-0004in-AX; Tue, 12 Aug 2014 22:43:02 -0400 Original-Received: by mail-lb0-f169.google.com with SMTP id s7so7841447lbd.28 for ; Tue, 12 Aug 2014 19:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Y/h+W0vv+7PX8hUYoQ7VgK8yonwcJgVoolmRM0hAcok=; b=S7BT47b7HWi0A9Rh9v8Bkr5NMkTL0LTynAgDUqTw0h8YawzlT6Tz6Ex3ff3racbAwU nTNsrOIjJYrAtHqv4Ue0dzmfMctzW7GxoGAMba+VdGOS9lMsCUhGh2L3sq05lbFXOB6c 7Y4aIqxRghlvsF6Ok9GZMeE43769Ykw+Irc83hu2gswsQFpbwgmsq7m9x53mcJ3e6XL0 zOGjUdGJ7xKz/pqvvzgxlfFJ197SQEdXK599ti5vQNhYdJwkHBJ0FGhdpOnK1fWuXb3/ keLSqnxquDUhU4xd40c2CSn+4EKiJKVL28j/SpmleXl3UmLNvZVZFH8kB89i9xjc5HOz GP6Q== X-Received: by 10.152.9.100 with SMTP id y4mr1560064laa.26.1407897780974; Tue, 12 Aug 2014 19:43:00 -0700 (PDT) Original-Received: from [10.8.0.26] (v-2-eu19-d3962-07.webazilla.com. [78.140.151.7]) by mx.google.com with ESMTPSA id e7sm331586lae.9.2014.08.12.19.42.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Aug 2014 19:42:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <8361hzjciv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::229 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:173608 Archived-At: 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. > 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. >> Yes, I might try this, as soon as there's some suggestion how to handle >> the problem of `line-prefix' in this multi-overlay approach. > > Find the longest prefix and align everything so that the left edge > keeps clear of that? Yes, sounds like a reasonable simplification. This would be a step back in terms of functionality, though, but possibly a justified one. >>> 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". Or that's my understanding. >>> Text-mode menus support navigation with cursor movement keys, like >>> C-p, C-n, up-arrow, and down-arrow. More accurately, any key bound to >>> next/previous-line will navigate through the menu items as you'd >>> expect. >> >> We have different commands that move up and down, with specific logic >> behind them. > > Examples? A simple example: (define-key keymap (kbd "M-n") 'company-select-next) (define-key keymap (kbd "M-p") 'company-select-previous) (define-key keymap (kbd "") 'company-select-next-or-abort) (define-key keymap (kbd "") 'company-select-previous-or-abort) The last two abort completion, do some magic and push the event back into `unread-command-events'. This happens if is pressed when the first candidate is selected, or is pressed when the last one is. Among other things, `company-select-next' and its counterpart save the number of the currently selected completion candidate, and the other commands and front-ends use that to display information related to it, and for correct visualization. >> Allowing the menu to handle those keys doesn't sound like a good >> idea. > > We could generalize the current menu code to allow something like > that. Sounds promising. > You can always exit the menu, pop up the documentation buffer, then > redraw the menu, all this programmatically. Will the menu allow me to customize the keymap it's using? To be able to invoke the `company-show-doc-buffer' command in the first place? > 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? > That is a problem you won't be able to escape. Emacs modes aren't > supposed to fight each other; if they do, the user is in trouble. Some packages's fringe indicators might be incompatible by their essence, there's not much we could do there. Others could co-exist. If the fringe allowed "layered" display of bitmaps, for example, flymake could assign its overlays a higher priority and happily coexist with diff-hl indicators. >> Could I display some vertical graphic in the margins that smoothly spans >> several lines? > > Emacs can display image slices (see the documentation of the 'display' > property), so this should be possible. I didn't try it, though. Thanks, I'll look it up sometime. >> 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?