From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 04:58:55 +0400 Message-ID: <53F695CF.1040606@yandex.ru> 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> 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 1408669234 19029 80.91.229.3 (22 Aug 2014 01:00:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 01:00:34 +0000 (UTC) Cc: 18285@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 22 03:00:27 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 1XKdDK-0003AI-B3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 03:00:22 +0200 Original-Received: from localhost ([::1]:34636 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKdDJ-000371-Rp for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 21:00:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKdDA-000364-CI for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 21:00:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKdD2-00045i-TE for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 21:00:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKdD2-00042W-Qk for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 21:00:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKdD2-0006IN-6m for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 21:00:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Aug 2014 01:00:04 +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.140866914924082 (code B ref 18285); Fri, 22 Aug 2014 01:00:04 +0000 Original-Received: (at 18285) by debbugs.gnu.org; 22 Aug 2014 00:59:09 +0000 Original-Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKdC8-0006GK-Dr for submit@debbugs.gnu.org; Thu, 21 Aug 2014 20:59:08 -0400 Original-Received: from mail-la0-f41.google.com ([209.85.215.41]:43987) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKdC5-0006Fp-Vv for 18285@debbugs.gnu.org; Thu, 21 Aug 2014 20:59:06 -0400 Original-Received: by mail-la0-f41.google.com with SMTP id s18so9496480lam.28 for <18285@debbugs.gnu.org>; Thu, 21 Aug 2014 17:58:59 -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=5yZNlYZU3r2i+WgXcLZF/D95f6XNMOWgnDpZwiQLBEM=; b=Af6UzvcJ6kaSaJysp8wg4yX9HaJT5sKAsk5mGimis9QBooraHpT06lsKda8Fxb3Eq6 522OIN0ZG0MzmnvL3W55a3nDbrluvqahlDzCGTvt9iFoLEt1t/EJmJE6tfifzjB+K1KP Dd/7pIMgbJ/7E9E2YgBI9SUq1gRmoqVcBoV3ANogWqyxb3q1HNt5tF73g+8Lq7r32Sis BO20n/2MbrhAaTPhtdBBwvMDKWkftiwKdACXJoqtJFRQejkQ+Wjb1EhVoi1MSFPvC458 5OMYpspyW+QwuMQmzYPmxoAEUvfPiwTb0rpElgUlCHVRMncPyB3W34sduZ7lKo/NrE/m NomQ== X-Received: by 10.112.183.162 with SMTP id en2mr1481135lbc.51.1408669139600; Thu, 21 Aug 2014 17:58:59 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id u15sm425160laz.38.2014.08.21.17.58.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 17:58:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <83mwaxbze5.fsf@gnu.org> 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:92586 Archived-At: 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. Anyway, how about the other way around? I'll like this less, but why not make `invisible' inactive when `display' is set? This works is a more consistent fashion, and the text that would be invisible ("a") is replaced by `display' anyway: (let ((pt (point))) (insert (propertize "a" 'display "bbb")) (let ((o (make-overlay pt (point)))) (overlay-put o 'after-string "foo\nbar"))) looks like bbbfoo bar >> 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. """ Like in this example: (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.