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 22:35:05 +0200 Message-ID: <83r3ht162u.fsf@gnu.org> References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> <568EBC49.6010405@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 1452198984 9849 80.91.229.3 (7 Jan 2016 20:36:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 20:36:24 +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 21:36:13 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 1aHHI2-0002Bx-MC for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 21:36:11 +0100 Original-Received: from localhost ([::1]:60956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHHI2-0001Ya-2q for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 15:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHHHy-0001YT-7N for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 15:36:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHHHu-0006NR-Ow for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 15:36:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHHHu-0006NL-Kx for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 15:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aHHHu-0002EX-GU for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 15:36:02 -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 20:36:02 +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.14521989058508 (code B ref 22320); Thu, 07 Jan 2016 20:36:02 +0000 Original-Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 20:35:05 +0000 Original-Received: from localhost ([127.0.0.1]:42045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHHGy-0002DA-PV for submit@debbugs.gnu.org; Thu, 07 Jan 2016 15:35:05 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33819) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHHGx-0002Ce-4p for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 15:35:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHHGo-0005c1-OO for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 15:34:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHHGo-0005bw-KL; Thu, 07 Jan 2016 15:34:54 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2020 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHHGn-0002rM-UB; Thu, 07 Jan 2016 15:34:54 -0500 In-reply-to: <568EBC49.6010405@live.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Thu, 7 Jan 2016 14:28:09 -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:111339 Archived-At: > Cc: 22320@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 7 Jan 2016 14:28:09 -0500 > > >> 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. > > No, my proposal would be to make all three dots use the face of the first hidden character. Yes, I understand. But then each invisible text will pass its potentially different face to its ellipsis, so each ellipsis will generally look different. > > I think it's confusing to have the faces of the invisible text > > show through, don't you agree? > > Not really; in a sense they already show through, since changing the faces of the hidden text can change the way it's displayed. Applying the face of the first hidden character to all three dots of the ellipsis has multiple advantages: > > * If an incorrectly spelled word is invisible, the dots are underlined. If seeing an ellipsis highlighted as a misspelled word is not confusing to you, then I guess we have very different ideas of what's confusing... > * If the first hidden character in fact does have the same face (from the user perspective) as the preceding one, the ellipsis is never reset to the default face (the font fallback issue means that at the moment I can have perfectly uniform-looking text, and folding still gives the default face to the ellipsis). If the invisible text uses a different font, you will have the ellipsis displayed with that different font, out of the blue. It could, for example, be a much larger or a much smaller font. Maybe it's not confusing to you, but it definitely is to me. > Invisible text is often used for folding sections of a buffer. Folding hides information, but we have an opportunity to show some of that information; namely, the information carried by the first invisible character. The current solution does take the information contained in the first character into account, but then makes it stand out or not based on a complex criterion. My POV is that when you make text invisible, you don't want to see it. None of it, not even its colors or its font. Having some of its attributes show through is just plain wrong, IMO. > In fact, I wonder if this isn't two problems we're looking at: the first one is falling back to default, and the second one is that falling back to default ignores the surrounding overlays. My ideal solution would be to use the first hidden character (or make it configurable), but even without this I feel that it would be a progress for the *face* of the ellipses to be reset to default, and then for that face to be merged with overlays. In other word one would consider that ellipses always have the default face, plus overlays that cover the full ellipsis. Any non-default face is always merged with the default, so saying let's merge it with the default is asking for a no-op. It will change nothing. What the code does is it deliberately ignores the faces specified by the overlays (or text properties) put on the invisible text, if that face is different from the preceding visible text. We can either ignore that face or not ignore it; there's no 3rd way. The way you suggest is go back to what we've been doing before that 2005 change. I don't like going back in principle (where does that end? can someone tomorrow go back from our going back, just because they think they are right and going back was wrong?). And I don't think it's justified to go back in this case. If someone comes up with a clever idea to fix more use cases that have faces on invisible text, that would be progress. But returning to what we did back then doesn't sound right to me, so I don't think we should do it. > >> 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? > > Sure (also posted in reply to your other message): Composed characters are processed, while invisible text is simply skipped. That's a world of difference. Each of these 2 features was introduced for a very different purpose, so it's small wonder they produce different effects on display. > Inheriting the face of the first character and applying it to the whole ellipsis would work here. But will fail elsewhere. > >> 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.) > > I'm using the bundled Org with emacs -Q in both cases. Then I don't know what to think. I see the "gap" in the region face in all old versions, exactly like I see in 24.5 and in the current emacs-25 branch. > >> 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? > > aspell marks line2 as a doublon, places an underline on it, and thus the invisible text doesn't inherit the selection face when I mark the whole buffer. Ah, you never said the 3rd use case needs "C-x h" as well. Yes, I see that here, too. It's the same situation as in the other cases.