From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice Date: Fri, 22 Aug 2014 09:41:25 +0300 Message-ID: <83bnrdauwa.fsf@gnu.org> References: <86d2bypwx1.fsf@yandex.ru> <83k365defw.fsf@gnu.org> <53F5FD0B.1070800@yandex.ru> <83ppftc2kv.fsf@gnu.org> <53F6130A.5090102@yandex.ru> <83mwaxbze5.fsf@gnu.org> <53F695CF.1040606@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1408689805 4304 80.91.229.3 (22 Aug 2014 06:43:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 06:43:25 +0000 (UTC) Cc: 18285@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 22 08:43:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1XKiZB-0000cD-6J for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 08:43:17 +0200 Original-Received: from localhost ([::1]:35344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiZA-0006a0-RB for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 02:43:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiZ2-0006Za-Me for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:43:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKiYx-0002wY-AR for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:43:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiYx-0002wT-6L for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:43:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKiYw-0006Td-Gu for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Aug 2014 06:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18285-submit@debbugs.gnu.org id=B18285.140868972424825 (code B ref 18285); Fri, 22 Aug 2014 06:43:02 +0000 Original-Received: (at 18285) by debbugs.gnu.org; 22 Aug 2014 06:42:04 +0000 Original-Received: from localhost ([127.0.0.1]:49267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKiXz-0006SK-R8 for submit@debbugs.gnu.org; Fri, 22 Aug 2014 02:42:04 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:52071) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKiXu-0006RD-LT for 18285@debbugs.gnu.org; Fri, 22 Aug 2014 02:42:00 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NAP006003FJIX00@mtaout25.012.net.il> for 18285@debbugs.gnu.org; Fri, 22 Aug 2014 09:36:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAP0009B3OEON60@mtaout25.012.net.il>; Fri, 22 Aug 2014 09:36:14 +0300 (IDT) In-reply-to: <53F695CF.1040606@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92590 Archived-At: > Date: Fri, 22 Aug 2014 04:58:55 +0400 > From: Dmitry Gutov > CC: 18285@debbugs.gnu.org > > On 08/21/2014 08:06 PM, Eli Zaretskii wrote: > > >> If the `invisible' starts even one character earlier, it *is* the other > >> way around. > > > > Yes, because then there's no doubt about the order of evaluating the > > various properties and acting upon them. By contrast, when they all > > begin at the same buffer position, the order is > > implementation-defined. The code is written to examine display > > properties before the invisible properties. > > Okay, but I'll take this to mean that hitting the changed behavior in > existing code would be pretty rare. I have no idea how rare it will be. FWIW, for the past year, all the display-related bugs are for pretty rare cases. What does that tell you about user expectations? > Anyway, how about the other way around? I'll like this less, but why not > make `invisible' inactive when `display' is set? That's what Emacs does already. The only place where invisible still matters in this situation is when deciding how and where to display overlay strings. I thought I explained that earlier in this thread. > >> Maybe. But at least it's consistent with the overlay priority rules. > > > > The priority is _per_buffer_position_. We tend to forget that text > > properties and overlays in Emacs are _character_ properties, but the > > display engine is designed and implemented to support that, and in > > some obscure cases, like this one, it is impossible to understand its > > logic, unless one remembers this simple fact. > > I'm just quoting Stefan from that discussion: > > """ > Same problem: for two overlays of equal `priority', the shorter one has > higher priority, so your original example is already one of those > cases, AFAIC. > """ This again omits the basic fact that properties and overlays are per character. > (let ((pt (point))) > (insert "aaa") > (let ((o (make-overlay pt (point))) (v (make-overlay (1+ pt) (1- > (point))))) > (overlay-put o 'face 'bold) > (overlay-put v 'face 'default))) > > the middle character has normal weight, even though it's also covered by > an outer overlay that sets `face' to `bold'. > > So, if I had to pick which single string to show (STRING1 or STRING2), > the latter seems to be the more consistent choice. My opinion is that users and Lisp programmers should not enter these dark corners.