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#22320: Overlays with an 'invisible property break stacking of overlay faces Date: Thu, 07 Jan 2016 20:46:07 +0200 Message-ID: <83ziwh1b4g.fsf@gnu.org> References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1452192448 24979 80.91.229.3 (7 Jan 2016 18:47:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 18:47:28 +0000 (UTC) Cc: 22320@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 07 19:47:17 2016 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 1aHFaa-0008S2-39 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 19:47:12 +0100 Original-Received: from localhost ([::1]:60145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFaZ-0007QF-AZ for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 13:47:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFaU-0007Pv-AC for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 13:47:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHFaQ-0007yV-4A for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 13:47:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFaQ-0007yQ-0p for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 13:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aHFaP-00080M-SV for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 13:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jan 2016 18:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22320 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22320-submit@debbugs.gnu.org id=B22320.145219236830707 (code B ref 22320); Thu, 07 Jan 2016 18:47:01 +0000 Original-Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 18:46:08 +0000 Original-Received: from localhost ([127.0.0.1]:41970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFZY-0007zD-0S for submit@debbugs.gnu.org; Thu, 07 Jan 2016 13:46:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43802) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFZW-0007yV-7L for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 13:46:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHFZM-0007fg-JC for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 13:46:01 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFZM-0007fc-FK; Thu, 07 Jan 2016 13:45:56 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1906 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHFZL-0002BE-PC; Thu, 07 Jan 2016 13:45:56 -0500 In-reply-to: <568E9A6A.2050201@live.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Thu, 7 Jan 2016 12:03:38 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:111329 Archived-At: > Cc: 22320@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 7 Jan 2016 12:03:38 -0500 > > > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg00338.html > > Interesting, thanks for the pointer. I read the discussion, but I see no rationale there for this choice. Was one ever given? I do see a rationale provided here: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg00339.html The change causes the code to keep using the same face in cases where that is not controversial, and fall back on 'default' otherwise. > Why is this better than, for example, keeping the face of the first invisible character and extending it to the whole ellipsis? That would go back to the original problem, whereby each ellipsis could have a different face depending on the faces in the invisible text. I think it's confusing to have the faces of the invisible text show through, don't you agree? Ellipsis just indicates there's some hidden text, why should it "inherit" the face of that hidden text? > Am I mistaken to think that this choice is also inconsistent with the way faces on composed characters are handled? It seems that composing a sequence of characters into "..." will keep the face of the first compose character. That default is useful in many places (such as Arthur's nameless mode, or in flyspell or flycheck when an error covers a sequence of characters composed into a single one). Is there a good reason to treat ellipses standing for invisible spans differently? I'm not sure I understand what you describe here. Can you show me some simple Lisp which demonstrates the situation? > The interactions of the current behaviour with transient mark mode are especially confusing I agree, but I learned long ago that one should use invisible text as little as possible, and in particular expect that text properties and overlays put on invisible text will have some specific effect. The display engine skips the invisible text entirely, looking only at its first character (and sometimes the last); if you think about this, you will immediately understand that having properties and overlays on invisible text is playing with fire -- basically, you bump into undefined behavior. > Using transient-mark-mode and selecting characters one by one from the end of the buffer, "i", "h", and "g" are progressively selected, then nothing happens despite "def" being in fact selected (so pressing C-w at that point kills more than highlighted), then "def" and "c" get highlighted at the same time. This means that the highlighted region doesn't actually correspond to the marked region. Is that also expected? The ellipsis gets highlighted as soon as the last visible character before the invisible text has the same face as the invisible text. That is what you see. So yes, this is expected. Like I said: it's a hard problem, and the solution only caters to the simple, no-brainer, use cases. I'm not surprised that you can come up with weird situations, but I cannot see a better, more general solution here. > >> (with-current-buffer (get-buffer-create "org-bug") > >> (erase-buffer) > >> (org-mode) > >> (insert "* line1\n** line2\n* line3") > >> (org-shifttab) > >> (pop-to-buffer (current-buffer))) > > > > You say that this use case is only broken in Emacs 25, but I see this > > in all the previous versions as well (as expected, given when this was > > coded). So if you really see this working correctly in Emacs 24.4, > > then some other factors on your system were at work here. Maybe you > > didn't test this exact test case there? > > You're right; this example works fine in 24.3, but it is indeed broken in 24.5. I tested both with -Q: No, it behaves the same in 24.3 and in 24.5 (and in all versions before that). I don't understand how you see something different. > Works: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2015-06-17 on clem-w50-mint > Broken: GNU Emacs 24.5.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2015-06-20 on clem-w50-mint > > Is this something that changed in org then? No, nothing changed. Which version of Org did you use in each Emacs release? (I used the one bundled with that release.) > >> (with-current-buffer (get-buffer-create "flyspell-bug") > >> (erase-buffer) > >> (text-mode) > >> (add-to-invisibility-spec '(outline . t)) > >> (insert "line1\nline2\nline3") > >> (flyspell-check-region-doublons (point-min) (point-max)) > >> (let ((ov (make-overlay 7 12))) > >> (overlay-put ov 'invisible 'outline)) > >> (pop-to-buffer (current-buffer))) > > > > What exactly is the problem here? I don't see anything that looks > > problematic. In particular, there are no duplicate misspelling in > > this buffer, so flyspell-check-region-doublons should do nothing. > > What am I missing? > > Indeed, I use aspell instead of ispell. It seems to ignore numbers, and thus flags the first two instances of "line" as duplicates. And what problems do you see then?