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 12:03:38 -0500 Message-ID: <568E9A6A.2050201@live.com> References: <568D5721.7060709@live.com> <83io352xmm.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="uis9wSHPL2cshgcLUFf2NaknIKOMtQbur" X-Trace: ger.gmane.org 1452186284 17083 80.91.229.3 (7 Jan 2016 17:04:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 17:04:44 +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 18:04:33 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 1aHDzD-0005RW-U7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 18:04:32 +0100 Original-Received: from localhost ([::1]:59716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHDzD-0004Os-Bn for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 12:04:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHDyo-0003oz-4l for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 12:04:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHDyj-0004XD-SL for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 12:04:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHDyj-0004X9-QB for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 12:04:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aHDyj-0003un-JR for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2016 12:04:01 -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 17:04: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.145218622915032 (code B ref 22320); Thu, 07 Jan 2016 17:04:01 +0000 Original-Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 17:03:49 +0000 Original-Received: from localhost ([127.0.0.1]:41896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHDyW-0003uN-N3 for submit@debbugs.gnu.org; Thu, 07 Jan 2016 12:03:49 -0500 Original-Received: from mout.kundenserver.de ([212.227.126.187]:64406) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHDyU-0003u9-EI for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 12:03:47 -0500 Original-Received: from [18.189.87.242] ([18.189.87.242]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M5lI9-1a20VW3q4f-00xtpS; Thu, 07 Jan 2016 18:03:40 +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: <83io352xmm.fsf@gnu.org> X-Provags-ID: V03:K0:OerKCOzrbaVnLp69nzLXlypV+6G2EdM3jMOiXt03VtcdwM3nj/L M4Fiv3NkCKqSlgCq1taMD6dKqhIb15U0b47fRuFe8KD3k5LIHggH03OGJOePKbzQhKWr+P9 0KA0GfgIDyg256thtDuuJD5He76nhAlzL5uILd6hK2AsCaymImE5ZtbB8NPvs0UM6uZULv7 WCPGt5UZ4a8XBpScohXSA== X-UI-Out-Filterresults: notjunk:1;V01:K0:THzm4RoqdBk=:RC5G9RU+YZrI8iF8ZeeGdm 0rqZF2h0sRjL9t59B1fw5fEa5kiV+udZy/2tT9nAQArYi4icWA1n4Z4M3CrktgVA5JDk79UyA TiW4C/MvknSvUAvbTLtfheEU9hlZWyHHimw21rDCBvUI6ewSjpTV/wqAIhOYxj0Umpe+igRpf MPrc+N+AvWgK1oZoNMbxGVqEbqx1ji+/9AEhWXcPaQ+pbxXHInYzIX4vlWrQ/bv9AXOpzFjbP tkhclm5YvSlSmLg223F4BhI6Iw+KXguFKRBhEjZcICH0AJ9O3Phh8qE6dyFJ/CMLaKhppY1/D br1isjctIA9qByEBzkNXJIqRJNx3cf67CrV4qx/YlDlBGpyWlwZmAOTGLhXqvV+kpYw7sswb3 +CpSnwdKBXVY1gyuy9s3KpahZyiJgffD4jWb9aEWNj4OPE2kn1MHzHIhYIpGVgNJZJdMw1833 N1YO9QWoo+IKwFlNjGkGClwoVaNJA5N2Sgv1q8LBlMTFXJfbmlxmHmLsXFxqyfaeeq8PAPts6 cqckyK/+jaItMKboApAcfxbVC+oqvqD8Dqd2JYNfMiyKEQwVskHZC2smcA/E36RkJR984E79L C3yyemjiULKa253D8bccSynnaIeGSjOyVG4X/Lcj4i7zKj+FPerd9HPcPNYksENY9iW4tUUpr OmEGvEmwTnKLPhaJBAX4A9DAc/Yl1STEWCz5mEs/HpOFhagtnqU2ZQDgZllABM+EpjrI= 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:111326 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uis9wSHPL2cshgcLUFf2NaknIKOMtQbur Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eli, Thanks a lot for your response. On 01/07/2016 10:54 AM, Eli Zaretskii wrote: > It's a feature. More accurately, it's the best solution found (more > than 10 years ago!) for a difficult problem. In a nutshell, in a > general use case the invisible text can (and many times does) have > non-trivial face attributes, and using those faces for displaying the > ellipsis would result in each instance of the ellipsis to have some > random face. This "feature" makes that face predictable: when the > invisible text has a face that is different from the last visible > character before it, the ellipsis is displayed with the 'default' > face. > > You can read the discussion which led to the current implementation > here: >=20 > 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? Why is this better t= han, for example, keeping the face of the first invisible character and e= xtending it to the whole ellipsis? 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 sequ= ence of characters into "..." will keep the face of the first compose cha= racter. 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 chara= cters composed into a single one). Is there a good reason to treat ellips= es standing for invisible spans differently? The interactions of the current behaviour with transient mark mode are es= pecially confusing: consider the two examples below: (with-current-buffer (get-buffer-create "region covers "def", but ellipsi= s isn't highlighted") (erase-buffer) (fundamental-mode) (add-to-invisibility-spec '(outline . t)) (insert "abcdefghi") (let ((ov (make-overlay 4 7))) (overlay-put ov 'invisible 'outline)) (let ((ov (make-overlay 6 (point-max)))) (overlay-put ov 'face 'region)) (pop-to-buffer (current-buffer))) (with-current-buffer (get-buffer-create "region now covers one more char,= and ellispis is highlighed") (erase-buffer) (fundamental-mode) (add-to-invisibility-spec '(outline . t)) (insert "abcdefghi") (let ((ov (make-overlay 4 7))) (overlay-put ov 'invisible 'outline)) (let ((ov (make-overlay 5 (point-max)))) (overlay-put ov 'face 'region)) (pop-to-buffer (current-buffer))) Using transient-mark-mode and selecting characters one by one from the en= d of the buffer, "i", "h", and "g" are progressively selected, then nothi= ng 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 c= orrespond to the marked region. Is that also expected? (I realize that th= is can also happen if the point is in the middle of an invisible region, = but that's a lot more of a corner case than using Shift+arrow keys to sel= ect a buffer section) > Note that the display engine only looks at the face of the first > invisible character; the rest are skipped without looking at their > faces (or any other text properties or overlays). So if you change > your test case in a very minor way: >=20 > (let ((ov (make-overlay 8 9))) > (overlay-put ov 'face '(:underline t))) >=20 > The "problem" doesn't happen. That's true, but I have no control over this; the only thing that I see i= s that invisible sections of org Buffers do not have the right background= (same for folded theorems in Coq buffers, due to the bug with font fallb= ack and overlays). >> Here is another (more "real-world") way to reproduce this issue (run t= he >> snippet, then use C-x h in the newly created buffer to mark all text: = the >> invisible section isn't highlighted) >> >> (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))) >=20 > 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: 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? >> Yet another way it to reproduce it is given below >> >> (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))) >=20 > 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 t= hus flags the first two instances of "line" as duplicates. >> Interestingly, the first example is broken in both 24.4 and emacs-25; = but the=20 >> second one is broken only in emacs-25 (the third one does not run in E= macs=20 >> 24.4). >=20 > This behavior should be present in any Emacs released after Apr 2005. I wonder what makes 24.3 behave differently in Org mode. >> I wonder if this is connected to another issue that I've seen, where h= aving a >> composition (using prettify-symbols-mode) just before an invisible reg= ion would=20 >> cause the background of the invisible region to be incorrect, but sett= ing=20 >> prettify-symbols-unprettify-at-point and moving the point to the edge = of the=20 >> symbol would cause the background to be fine. Unfortunately I don't ha= ve a good=20 >> repro for that issue. >=20 > Hard to tell without a reproducible test case. This is in fact due to font fallback. I opened a separate bug report, as = it does not seem obviously related to the current issue. Thanks, Cl=C3=A9ment. --uis9wSHPL2cshgcLUFf2NaknIKOMtQbur 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) iQIcBAEBAgAGBQJWjppqAAoJEPqg+cTm90wjNwAP/0VmMCCUikrbJFPHkYz+DxbX 7e1R9rZwIdoN8FXhjtXpspB0iJHL/0fwvgoedNrAktNSJOL8RAEpiKGuNf2Kp7Ko IGVlD4aTuWUSO60j0yB8rPNcltHRed1b2TaME3sJa8eSxzJLs58L7/sU2a4vm8mW aQ96bptC01gQrE54eQQkrgOAO8mmOzAz9Exs15gxsvasoP+szLwZVqcWCOAMYSZ9 6Ywkz4YcRnIha7Xo9da9diZQZmiv3P3RRv5+XcZvgdcZogi1R7i58zyWZCLSTfS0 cxBGGX/VjtJXqqxKVlvN2lRcHHGYABEFKYcN422yGBB/QZicyAOda1eXUfJkYUbM QicJv8AB8LZsKbDtQUXConhLKtO4fouBJ1LFkzv75VmZ+HXOsHkioI9RbUk0FCGF R/T9xdnn26dP8P1iU6iU36rIVuIDX9K3HfhLlkvMZXc4NMb9VEmgO4rEmdwSK8du lG6NVg7SXCyj2bQaExp4+TIWv0Ny7RYgvJS+8t8UcRjNJ0NtgcPSucqf/GKxwwVe 2JJ8eOKg+HagFM5ZYjEZeyPH9BNZW3GiiE5iCZDuHfLKd/ObfwNnXZGcnEhLs/34 Pt3uJ8bEYyXHuHIzzBfphSKqd/GfWM8HFDfyL6/GEr7BlxN9Th8/871PQ5A/dTWG fYymwafTYlOPNkrbxFP3 =BtjJ -----END PGP SIGNATURE----- --uis9wSHPL2cshgcLUFf2NaknIKOMtQbur--