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: Fri, 15 Aug 2014 09:39:55 +0300 Message-ID: <83sikygssk.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> <83iolwif2l.fsf@gnu.org> <53EC205F.7030801@yandex.ru> <8361hvixxz.fsf@gnu.org> <53ECB5C3.20309@yandex.ru> <834mxfhzd4.fsf@gnu.org> <53ED604C.8020705@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1408084825 21106 80.91.229.3 (15 Aug 2014 06:40:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 06:40:25 +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 Fri Aug 15 08:40:18 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 1XIBBR-0003Cy-ST for ged-emacs-devel@m.gmane.org; Fri, 15 Aug 2014 08:40:17 +0200 Original-Received: from localhost ([::1]:57754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIBBR-0007ir-Di for ged-emacs-devel@m.gmane.org; Fri, 15 Aug 2014 02:40:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIBB8-0007h8-NY for emacs-devel@gnu.org; Fri, 15 Aug 2014 02:40:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XIBB3-0005sQ-Qe for emacs-devel@gnu.org; Fri, 15 Aug 2014 02:39:58 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:54992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIBB3-0005sK-Hz for emacs-devel@gnu.org; Fri, 15 Aug 2014 02:39:53 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NAC00A004G9E300@mtaout24.012.net.il> for emacs-devel@gnu.org; Fri, 15 Aug 2014 09:35:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAC009RY4Z4HU20@mtaout24.012.net.il>; Fri, 15 Aug 2014 09:35:28 +0300 (IDT) In-reply-to: <53ED604C.8020705@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.180 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:173685 Archived-At: > Date: Fri, 15 Aug 2014 05:20:12 +0400 > From: Dmitry Gutov > CC: rudalics@gmx.at, emacs-devel@gnu.org > > > This property we are discussing (that doesn't yet exist) will be acted > > upon by the display engine. The display engine always knows what > > "things" are there at point, and the supporting logic for this > > property will cause the display engine to ignore all the other > > "things" and display only the overlay that has this property. At > > least that's the theory. > > Well, since we don't only need to replace the displayed characters, but > also modify them, this doesn't do a lot of work for us. Not sure why you would need to modify them. My understanding is that you include in the overlay some of the displayed text, and also include your own text. What I'm suggesting will allow you not to duplicate the displayed text, but just add an overlay with your own. > From what I understand, you're suggesting a property that would act > like a combination of overlay + display does currently. Why not just > document that current behavior and then stick to it, rather than > introduce the new property? See above: because what exists doesn't do the job for you well enough. Copying into your overlay existing text from buffer, other overlays, and display strings is fragile design with known deficiencies (which were revealed in this thread). Having a special property that would avoid all that is a win, IMO. For example, you will be able to stop worrying about line-prefix and images.