From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Newsgroups: gmane.emacs.bugs Subject: bug#22320: Overlays with an 'invisible property break stacking of overlay faces Date: Thu, 7 Jan 2016 14:28:09 -0500 Message-ID: <568EBC49.6010405@live.com> References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uo74C1psDKstwUrNbDua3blXWQBOA0T5p" X-Trace: ger.gmane.org 1452194980 8362 80.91.229.3 (7 Jan 2016 19:29:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 19:29:40 +0000 (UTC) Cc: 22320@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 07 20:29:25 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 1aHGFP-0006Io-0P for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 20:29:23 +0100 Original-Received: from localhost ([::1]:60329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHGFG-0001oz-4x for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 14:29:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHGFA-0001of-Ji for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 14:29:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHGF5-00074S-Ca for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 14:29:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHGF5-00073r-9G for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 14:29:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aHGF4-0000Z2-Cj for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 14:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jan 2016 19:29: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.14521949022117 (code B ref 22320); Thu, 07 Jan 2016 19:29:02 +0000 Original-Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 19:28:22 +0000 Original-Received: from localhost ([127.0.0.1]:41992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHGEP-0000Y4-Gq for submit@debbugs.gnu.org; Thu, 07 Jan 2016 14:28:21 -0500 Original-Received: from mout.kundenserver.de ([212.227.126.133]:54563) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHGEN-0000Xr-Ac for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 14:28:20 -0500 Original-Received: from [18.189.87.242] ([18.189.87.242]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0M2U69-1ZylVR0Du1-00sPIK; Thu, 07 Jan 2016 20:28:12 +0100 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83ziwh1b4g.fsf@gnu.org> X-Provags-ID: V03:K0:PbR2K1gV72NVQdQsEWaHAOqw/zZ5lDO9ZJVrOe44RPrDoQM/+UH jB/BUFG0yKPT1fME6Z3bOQoJqUK1AbXpm5WnAqi4Iy7R0c8LWh8KA0DPKFEIT0/A8foqoKL MzJvxlpegZDm2H8KJmACaoHmcMIQoWZK0KsrdP7A6CdEQNZ8YlCUNFnabLxmgRkIMnVdV9D ZYizd4CnROR5k2t+kgcXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:GzkLNLFjwKU=:MF2MU1fLb0izxAVID09Z9Q GIst1IjdkJe2RA87HmJsXnAFi1xmY1hG1rnv/T5zkkl7ijyG+wnCCm2BeCGXUeczIQHhOdEE9 tR4Mndd7F9iwO3GaGGm+m4jmhJ9FOjTgXLD0xYSacXad/EtlIb8LkuDe7Qia2i4M9uSQ/BthZ XGp89wJuiTy2ExkRtzyIdg9uq6FiHV9jmo20RUxleQKSOs0nPHy21P3OlrYz0501vU8KuHIpz 4xqxh3u6tKEuT6M8MSCujrCk9tTbCml/wRL4IlUark9U9fX5Jo73LFNq/ugSh7s6TzjE4N7rY 7qgpcXOZbzEDnjtDrwygAWVBvw/Tu55X/oblyPMGJBXyZD4pDlmdi9Xf6LHVJCVSOqFaABUN8 +Jx8QYTtJ+tD4gQ9pLg1h/7zPhpLFw4vpE0lXe5cWM+CqsKMtqYOeNQKIfxKcct4b2XHUZTR2 O/hH6FZyX2w06+pvsCGE5U4UPaUOj25LPoMA87x8ezXl+PkKSstAms4PqS1LGuqTwtXguam/N hZKPfXub26MoxZpsV/C/IxXaAQaz2sNXVLlf+VYdETUb+iHNi59KVxktxNUXmm2j+0I25Vugw nwImdvBAN/77LM8pTXkVgZvOSTwhtnGn/bO+FUxiMkEQeiQ3IccTm8VlE/a1X9pOThCLFhvgh Ypyq5g/jSO7JB0s8L8byj98H4hesoU4Nws9bFS7O9nuKITw/ca42a9jJFJJrq4tP0go8= 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:111333 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uo74C1psDKstwUrNbDua3blXWQBOA0T5p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2016 01:46 PM, Eli Zaretskii wrote: >> Cc: 22320@debbugs.gnu.org >> From: Cl=C3=A9ment Pit--Claudel >> Date: Thu, 7 Jan 2016 12:03:38 -0500 >> >>> http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg0033= 8.html >> >> Interesting, thanks for the pointer. I read the discussion, but I see = no rationale there for this choice. Was one ever given? >=20 > I do see a rationale provided here: >=20 > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg00339.= html >=20 > The change causes the code to keep using the same face in cases where > that is not controversial, and fall back on 'default' otherwise. I understand what the change does, but I don't see that message as justif= ying it; instead, it asserts that the font-lock face is arbitrary; on the= other hand, what I'm seeing with that code currently is a large section = of the buffer highlighted in blue, and every time a folded section follow= s a character that's not in my current font (so about half of all folded = sections) the ellipsis has the wrong background, making it stand out. >> Why is this better than, for example, keeping the face of the first in= visible character and extending it to the whole ellipsis? >=20 > 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. > 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 face= s 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 mult= iple advantages: * If an incorrectly spelled word is invisible, the dots are underlined. * 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 t= he default face (the font fallback issue means that at the moment I can h= ave perfectly uniform-looking text, and folding still gives the default f= ace to the ellipsis). Invisible text is often used for folding sections of a buffer. Folding hi= des information, but we have an opportunity to show some of that informat= ion; namely, the information carried by the first invisible character. Th= e current solution does take the information contained in the first chara= cter into account, but then makes it stand out or not based on a complex = criterion. 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 t= o default ignores the surrounding overlays. My ideal solution would be to= use the first hidden character (or make it configurable), but even witho= ut 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 overlay= s. In other word one would consider that ellipses always have the default= face, plus overlays that cover the full ellipsis. > Ellipsis just indicates there's some hidden text, why should it "inheri= t" the > face of that hidden text? I think of ellipses as a compressed representation of that text; barring = a better way to summarize that text, inheriting the faces of its first ch= aracter seems like a decent approach. If I write red-green-red and color = each word with the corresponding color, then make "green" invisible, my s= pontaneous expectation is that three green dots will appear (mostly becau= se I don't think of invisible as invisible, but rather "compressed"/"fold= ed") >> 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 s= equence of characters into "..." will keep the face of the first compose = character. That default is useful in many places (such as Arthur's namele= ss mode, or in flyspell or flycheck when an error covers a sequence of ch= aracters composed into a single one). Is there a good reason to treat ell= ipses standing for invisible spans differently? >=20 > 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): (with-current-buffer (get-buffer-create "emulating invisibility with comp= osition works") (erase-buffer) (fundamental-mode) (add-to-invisibility-spec '(outline . t)) (insert "line1 line2 line3") ;; This composition snippet was taken from Arthur's nameless-mode: (compose-region 7 12 (cdr (apply #'append (mapcar (lambda (x) (list '(B= r . Bl) x)) "...")))) (let ((ov (make-overlay 7 8))) (overlay-put ov 'face '(:underline t))) (let ((ov (make-overlay (point-min) (point-max)))) (overlay-put ov 'face '(:background "red"))) (pop-to-buffer (current-buffer))) compared to (with-current-buffer (get-buffer-create "using invisibility directly does= n't work") (erase-buffer) (fundamental-mode) (add-to-invisibility-spec '(outline . t)) (insert "line1 line2 line3") (let ((ov (make-overlay 7 12))) (overlay-put ov 'invisible 'outline)) (let ((ov (make-overlay 7 8))) (overlay-put ov 'face '(:underline t))) (let ((ov (make-overlay (point-min) (point-max)))) (overlay-put ov 'face '(:background "red"))) (pop-to-buffer (current-buffer))) >> The interactions of the current behaviour with transient mark mode are= especially confusing >=20 > 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 no= thing happens despite "def" being in fact selected (so pressing C-w at th= at point kills more than highlighted), then "def" and "c" get highlighted= at the same time. This means that the highlighted region doesn't actuall= y correspond to the marked region. Is that also expected? >=20 > 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. >=20 > 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. Inheriting the face of the first character and applying it to the whole e= llipsis would work 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 wa= s >>> 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: >=20 > 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. >=20 >> 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? >=20 > 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. >>>> (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, an= d thus flags the first two instances of "line" as duplicates. >=20 > 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 b= uffer. --uo74C1psDKstwUrNbDua3blXWQBOA0T5p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWjrxJAAoJEPqg+cTm90wj4Z0P/24WZQeTjd1OixYQDhZhnrV4 N1jLMJSE6JgkABItsNCnd9eeKfe/fVbnB1uetFf4F4sZ//focuPFDmAtg8GR+9qr wO9hsT3FlttcGtX7vFPgvY10nYLU9KdUMTN/uf1kvNFxHdUYQTXsv+GG1lRcAQR5 066rjbUOUqLCU6SsuX4gRbRfrZNqQxy7M3S9KaTSxwM7DV3rLLYJ9WDyVgDCiR3f HzcfzLc1qDg2YYR6BXDcvNEtg6T7dUnn6V9nhdq4gKtro28mjm1ASKnpqzrS9hBp +CExGKxTB/jbgzrlsED+Lc9bk/6o8YKfsU7R1tWIEmsqKqs1vHoOmsvsG+k/JTwS 6QwMzYJRAmwZXnt8D5ILKznntZrXNO+PxwXpFMYrN1TsnCbJU+BiCEsi/XdKyovf saHC/VaQh6XYgusf3Ai7R3vuIyT4Pc59xypj1Fxf9Cs+aeB7ufwz344lkEoyAK91 OJx624+wxQq3O2OdALr/8xGXhst0OQVMY7lR0HN9rYUWmKKDmvoAu4//Vricr9l9 kJcaPgR1bnOuR+uN7osTU+YzUNtQV6jFL4m3sMkpx34DjcJdhW2Gdj9UvGXgOQS/ ZbfKjSclXC2No/yZ5T0e5UzKlowuLSsKQaZ+D1/2F/7F/XK7n2vzZVwaPt39Z/jQ lMAEu51ewYltNHTThzkY =BMQE -----END PGP SIGNATURE----- --uo74C1psDKstwUrNbDua3blXWQBOA0T5p--