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: Sat, 23 Apr 2011 21:42:14 +0200 Message-ID: <4DB32B96.50409@online.de> References: <83k4ekc3z1.fsf@gnu.org> 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 1303587193 2499 80.91.229.12 (23 Apr 2011 19:33:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Apr 2011 19:33:13 +0000 (UTC) Cc: Eli Zaretskii To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 23 21:33:10 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 1QDiZp-0001Oq-Fo for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2011 21:33:09 +0200 Original-Received: from localhost ([::1]:46667 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDiZo-0001fc-2D for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2011 15:33:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDiZl-0001fX-Jj for emacs-devel@gnu.org; Sat, 23 Apr 2011 15:33:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDiZk-0006dB-O3 for emacs-devel@gnu.org; Sat, 23 Apr 2011 15:33:05 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.187]:51821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDiZj-0006cu-BG; Sat, 23 Apr 2011 15:33:03 -0400 Original-Received: from [192.168.178.29] (brln-4db9f8ae.pool.mediaWays.net [77.185.248.174]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LjLyR-1Ph86u3kC7-00cmfD; Sat, 23 Apr 2011 21:33:00 +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: <83k4ekc3z1.fsf@gnu.org> X-Provags-ID: V02:K0:+d8gJ5ob00lNCpfROLxEGZJBAWUGblQUPXrBxwy2Wt6 HJluD1Ask01XjsmDvsVYm7G8zname1hzmFRXU2mT7+fsW1tDEr mJ6kU7q93xTR9CI89L8uKmXahbP6NBCjZW5DyOZCY8WHaGSCvP 7nueZZhHF4JLW1LjbK8v5mTBxqb7Xhs+CpCIWFpMvJ1eCXpezs k+uyxK6GDCriUqFdnpPHtZWu8kzKq9HD90FIttLPMc= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.227.126.187 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:138660 Archived-At: Am 23.04.2011 18:44, schrieb Eli Zaretskii: > 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. > > However, after so many years (this is how Emacs behaves since v21.1), > perhaps we should keep this behavior. Does anyone know any real-life > use cases where this "feature" is needed or would be beneficial? > > The reason I'm asking is that whether we keep or remove this feature > affects the detailed design of how bidirectional text should be > reordered in the presence of display properties and overlay strings. > > > Hi, would consider it definitly a bug with respect of following order of evaluation: (defvar myov2 (make-overlay 29 43)) (defvar myov1 (make-overlay 16 51)) (overlay-put myov2 'display "STRING2") (overlay-put myov1 'display "STRING1") ie if the wider overlay is applied last, it should take all. Cheers Andreas