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: Mon, 11 Aug 2014 05:14:24 +0400 Message-ID: <53E818F0.2080104@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> 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 1407719697 28886 80.91.229.3 (11 Aug 2014 01:14:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Aug 2014 01:14:57 +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 Mon Aug 11 03:14:50 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 1XGeCH-0001Nk-Gh for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2014 03:14:49 +0200 Original-Received: from localhost ([::1]:33219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGeCH-0003Vl-3A for ged-emacs-devel@m.gmane.org; Sun, 10 Aug 2014 21:14:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGeC5-0003Vd-OA for emacs-devel@gnu.org; Sun, 10 Aug 2014 21:14:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGeBw-0004VT-JJ for emacs-devel@gnu.org; Sun, 10 Aug 2014 21:14:37 -0400 Original-Received: from mail-la0-x22f.google.com ([2a00:1450:4010:c03::22f]:65468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGeBw-0004VF-71; Sun, 10 Aug 2014 21:14:28 -0400 Original-Received: by mail-la0-f47.google.com with SMTP id mc6so6085744lab.6 for ; Sun, 10 Aug 2014 18:14:27 -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=erQfp40ilfY5PqSDl7x+SFB2bkD82kY4a1+0CuzgB4A=; b=yITbICO8f4T9HGM5JTcDcNg1u8HSiXv8R1NnVl8fJcebNvPOrLb27cDzFecRJWHlGm lk/psCAj4ClJ9odqlkNvA+Q4wLsL0sph/MRyhHTNQgg7T29YR45AZWnmb2kuDf8LYuCw Ohj/YVYrRi6DyWR/pRJBMMJWq8CPab+s3vIkC50IZGBmssDtEZLXAVM9HKbaKz24vxG9 J+otPslolgvcGqjzvUN8kxom4f7ft6FIMD14VSjeYIvt0eRfWRL4a/OAKBmAWRb4t8J6 XnmOouCsR2bxZTulSUlWljmJ1wShzn/o2/jvLvVLThnk8mtVoceF6nq4rOAgOryz+Ceu ew0Q== X-Received: by 10.112.98.140 with SMTP id ei12mr33964009lbb.6.1407719667001; Sun, 10 Aug 2014 18:14:27 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id er11sm15875406lbc.49.2014.08.10.18.14.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Aug 2014 18:14:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <837g2knwb2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22f 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:173555 Archived-At: On 08/07/2014 07:39 PM, Eli Zaretskii wrote: > So what would be the requirements for "correct positioning"? Display some strings in the buffer starting with the given line and column, correctly lining all following lines up vertically, to form a rectangle Something like the following would work: (make-popup :x-coord 340 :y-coord 200 :width ... :height ... :contents "foo\nbar\nbaz" :default-face ...) The keyword arguments are just for show, and the above assumes that popups aren't tied to specific buffers (or window, I guess). Making it buffer-local would be fine, too, I guess, then :x-coord and :y-coord might be replaced with :x-offset and :y-offset, specified relative to the popup's reference position in the buffer's contents. > So text with display properties is one problem. Any others? - `line-prefix', as discussed. - Different values of `line-height', `line-spacing', images in the buffer. - Changes in some lines' appearance done some other way, like the separator line in `log-edit' buffers. - The `intangible' property would probably also cause some problems for our current implementation. - Proportional fonts, obviously. - Not being able to display the popup over the mode-line and window separators. This would be useful for completion when typing in the minibuffer. - The "one big overlay" approach conflicts with other packages that use overlays to put information on the margins or fringes, such as linum and diff-hl. The lines displaying our popup lose the linum and diff-hl indicators. > Sorry, I don't understand the question: what would be zero-length? An overlay where BEG = END. It wasn't a very meaningful question, I guess. > What I meant is this: if you need to display below the last line of > the buffer text, put the overlay at EOB, and include newlines in the > overlay string when you need to move to the next screen line. To > align text horizontally you could use spaces or align-to display > properties in the string. 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. >> This is indeed a missing feature. It should be easy enough to provide >> some special kind of display property that would overlay any other >> displayed content >> >> >> That would leave a question where will it have to be set on. Would that new kind of overlay be able to be displayed far from the position it's set on? > > 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. > 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. Allowing the menu to handle those keys doesn't sound like a good idea. >> press another combination of keys and see a doc buffer pop up > > Help-echo in menus is supported, and shown in the echo area > automatically, so you could have all that documentation in the > help-echo string. It _might_ help with displaying the one-line help we already show in the echo area (although the programmatic interface seems to be incompatible: we only ask the backend for that information when the candidate is selected), but it definitely won't help with popping up the documentation buffer. >> or just continue typing in the buffer and see the popup with completion candidates get updated unobtrusively. > > This can be achieved programmatically, by refreshing the menu when the > user types. Could you elaborate on that? Would that work via post-command-hook? >> And, at least in the tooltip's case, they can't be styled. > > What do you mean by "styled"? Displayed with different background color, for example. > In any case, if something is missing in tooltip frames to support this > kind of applications, we had better added that. IMO, showing > completion candidates in a tooltip will look much more professionally > than the current text emulation. AFAIK, other IDEs do use tooltips in > these cases. Of course. >> Still, this way you can only use 2 colors > > Why only 2? The fringe foreground color and the fringe background color. The fringe face may vary between lines, but a bitmap instance ends up using only two colors at a time. >> each line can only contain one bitmap > > Fringe real estate is limited, so yes, there are limits to this. Fringe size is not fixed, the user (or packages) can change it. Even with the current default size, I could use being able to display several bitmaps at a time: for example, the simple-looking indicator from diff-hl and, above it, `?' or `!` from flymake. > An alternative is to use line-prefix or display margins, and display > images there. line-prefix is again something only one package can use at a time. Could I display some vertical graphic in the margins that smoothly spans several lines? >> Suppose there are multiple modes using the fringe, and they all want to handle clicks. How would they handle that without conflicts? > > The click on the fringe is interpreted in the context of the selected > window's buffer, AFAIR. And? Suppose there are multiple minor modes in that buffer that might like to handle that click?