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: Sun, 24 Aug 2014 05:28:42 +0400 Message-ID: <53F93FCA.2040607@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> <53F695CF.1040606@yandex.ru> <83bnrdauwa.fsf@gnu.org> <53F72C7F.7050108@yandex.ru> <83sikomz1a.fsf@gnu.org> <53F7A1B7.2080607@yandex.ru> <83iolkmeg4.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 1408843769 26212 80.91.229.3 (24 Aug 2014 01:29:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Aug 2014 01:29:29 +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 Sun Aug 24 03:29:22 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 1XLMcT-0006pL-K3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Aug 2014 03:29:21 +0200 Original-Received: from localhost ([::1]:42691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLMcS-00009W-QN for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Aug 2014 21:29:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLMcI-00008L-M7 for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2014 21:29:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XLMcB-0003IV-6u for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2014 21:29:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLMcB-0003IR-36 for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2014 21:29:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XLMcA-0007D3-Kz for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2014 21:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Aug 2014 01:29: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.140884373627700 (code B ref 18285); Sun, 24 Aug 2014 01:29:02 +0000 Original-Received: (at 18285) by debbugs.gnu.org; 24 Aug 2014 01:28:56 +0000 Original-Received: from localhost ([127.0.0.1]:50517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XLMc3-0007Ci-Bb for submit@debbugs.gnu.org; Sat, 23 Aug 2014 21:28:55 -0400 Original-Received: from mail-la0-f41.google.com ([209.85.215.41]:49584) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XLMbz-0007CQ-Lc for 18285@debbugs.gnu.org; Sat, 23 Aug 2014 21:28:52 -0400 Original-Received: by mail-la0-f41.google.com with SMTP id s18so11482778lam.0 for <18285@debbugs.gnu.org>; Sat, 23 Aug 2014 18:28:45 -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=/WUMSUMxnp7zOc+mfpNb5oWEG2HgbiaR1wmMMYIq3ZY=; b=TrbaVgnDzVvJv7J/TXLdLyJAFiA0HVr62vyUZ7yZmNWEdCD1cEepkFZvN3xApisLNf 9VTSGbRGGicUh29doKSYYFJZalpykl9nfqXgac6gCl1tvzt458hlFx1Mh9uDaEJxF5+G 30yZtjhM5jN/U8k5xJdCR6p4IahOzseGkehlv7q2u269o+iDFsOxJGrA1futb3P8z5a1 3KXK77KKAAAhqol2e28BHOIM7FOPGWddyCTijnmOnS1XtiQn4p7MT3T+38ukISINhuvv 4eHECV1EpesvyYQQ3xxzH+nEOcVpRCiMSIo7MdzQc5JRV+Kt3mG/fq6Y//8wUZO6riHV fHRA== X-Received: by 10.152.229.133 with SMTP id sq5mr276992lac.67.1408843725695; Sat, 23 Aug 2014 18:28:45 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id u6sm21094451laj.7.2014.08.23.18.28.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 18:28:44 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <83iolkmeg4.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:92629 Archived-At: On 08/23/2014 12:55 AM, Eli Zaretskii wrote: > Look at the code inside load_overlay_strings that handles this, to > understand what I'm saying. Do you mean the situation when the `invisible' overlay starts before the `display' starts? And then we skip to the end because of `invisible', but that position is covered by `display', so if we ignore the `invisible' there, `before-string' would not be displayed? >>> The question is what would you expect from the second example, if it >>> used before-string there? Should the before-string be displayed or >>> shouldn't it? Since invisible makes the beginning of the overlay >>> disappear, under your suggestion it won't be displayed. This doesn't seem to apply to the second example, because the overlay with `invisible' and the `display' prop start at the same position, so the beginning of the overlay would not be "made disappear". I'm not sure what to do in the "mixed" cases like described above, though. Maybe only make `invisible' ignored when `display' covers the entirety of its span. Or maybe this complexity is an argument in favor of `invisible' taking priority over `display', after all. That sounds like it may be easier to implement, or at least specify: don't handle `display' only when it's entirely covered by `invisible'. > You asked to ignore the invisible, so it will change. Basically, my suggestion was to ignore it when `display' already performs all of its job. But the edge cases make it more complicated.