From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Nested display strings Date: Sun, 24 Apr 2011 08:31:24 +0200 Message-ID: <4DB3C3BC.8090905@online.de> References: <83k4ekc3z1.fsf@gnu.org> <8762q4mdjp.fsf@maru.md5i.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1303626139 20702 80.91.229.12 (24 Apr 2011 06:22:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2011 06:22:19 +0000 (UTC) Cc: Eli Zaretskii To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 24 08:22:16 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QDshz-0003Yz-Fi for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2011 08:22:15 +0200 Original-Received: from localhost ([::1]:59637 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDshy-0003hX-UX for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2011 02:22:14 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDshv-0003gz-Fg for emacs-devel@gnu.org; Sun, 24 Apr 2011 02:22:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDshu-0005UK-K2 for emacs-devel@gnu.org; Sun, 24 Apr 2011 02:22:11 -0400 Original-Received: from moutng.kundenserver.de ([212.227.17.8]:56111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDshu-0005Tk-8r; Sun, 24 Apr 2011 02:22:10 -0400 Original-Received: from [192.168.178.29] (brln-4dbc75c9.pool.mediaWays.net [77.188.117.201]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MhamE-1QQTuE1DsI-00MeAY; Sun, 24 Apr 2011 08:22:08 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <8762q4mdjp.fsf@maru.md5i.com> X-Provags-ID: V02:K0:+T/vBKZz4god8QvQCUswwNr6dT6Xn6L0++htMeKQF4K edB1FNidj5yXlIeF4WxykaswJdUqbKfmvdYJ3F1kO7MiLRvgOa b798G6i/Dyfpz6d2Z49TU/0dd0tGBZVA8enGuqi2AJJTQ2WJl7 o5N5CtQBTH2mdORKWKQxiVaP+01b4g5/dcr+82oq3CHMPVWvbI 1lWWM0iHHbYy22TUvdoC0V11HsAUoOEg+Ijt2WkfMU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.227.17.8 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:138674 Archived-At: Am 24.04.2011 07:19, schrieb Michael Welsh Duggan: > Eli Zaretskii writes: > >> The following 4 lines define two overlays with display strings, with >> the second overlay "nested" inside the first one: >> >> (defvar myov1 (make-overlay 16 51)) >> (overlay-put myov1 'display "STRING1") >> (defvar myov2 (make-overlay 29 43)) >> (overlay-put myov2 'display "STRING2") >> >> If you evaluate this in the *scratch* buffer, the result is this: >> >> ;; This buffer STRING1STRING2STRING1, and for Lisp evaluation. >> >> That is, STRING1 is displayed twice! Is this a bug or a feature? >> >> I asked Gerd Möllmann, and he told me that this is an accident: what >> he really meant was, once STRING1 is displayed, to skip to the end of >> its overlay, so that the nested overlay myov2 would not be displayed >> at all. > > I'm of the opinion that it should either display: STRING1 or > STRING1STRING2STRING1, and which doesn't really matter. In the first > case, the first overlay gets a higher priority than the second, in the > latter the second gets one that is higher than the first. The manual > says: "You should not make assumptions about which overlay will prevail > when there is a conflict and they have the same priority." This is what > makes me think that either is correct. If I had to choose, however, I > would prefer that if two overlays with the same priority appear over the > same character, whichever overlay that has the earlier start should take > precedence (giving us STRING1 in this case). Which would be the reverse logic from setting values in nested let's for example. Suggest giving the last setting precedence, in cases 'priorty can't decide. Cheers Andreas > > Please note, that if myov1 had a specifically higher priority than > myov2, I think STRING1STRING2STRING1 is a perfectly valid result. I see > overlays and text properties reducing down to a single set of property > ranges, with text properties at a sort-of -1 priority. In this case we > have a range with a property of STRING1, a range with a property of > STRING2, and a range with property of STRING1 again. The display makes > perfect sense to me. >