From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 06 13:04:35 2016 Received: (at submit) by debbugs.gnu.org; 6 Jan 2016 18:04:35 +0000 Received: from localhost ([127.0.0.1]:40550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aGsRn-0007Yy-F4 for submit@debbugs.gnu.org; Wed, 06 Jan 2016 13:04:35 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41038) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aGsRl-0007Yj-4f for submit@debbugs.gnu.org; Wed, 06 Jan 2016 13:04:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGsRe-0002xW-Lt for submit@debbugs.gnu.org; Wed, 06 Jan 2016 13:04:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGsRe-0002xR-JD for submit@debbugs.gnu.org; Wed, 06 Jan 2016 13:04:26 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGsRd-0007JB-1d for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 13:04:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGsRZ-0002wI-Pa for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 13:04:24 -0500 Received: from mout.kundenserver.de ([217.72.192.73]:54574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGsRZ-0002vz-Gt for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 13:04:21 -0500 Received: from [18.26.2.123] ([18.26.2.123]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0Lo18K-1Zk0bb37u4-00fwvS for ; Wed, 06 Jan 2016 19:04:19 +0100 From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= X-Enigmail-Draft-Status: N1110 Subject: Overlays with an 'invisible property break stacking of overlay faces To: bug-gnu-emacs@gnu.org Message-ID: <568D5721.7060709@live.com> Date: Wed, 6 Jan 2016 13:04:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HI0oUaD4APtD3pgfaJhDO8J9tqqngxF9d" X-Provags-ID: V03:K0:clE21Nabq50/SjydBPZjeYjyKG/Lo2MEQPIj+DELQmdf1mnQPkE x6wfXd8Woxx13886ty6tsAYfj0K7XFXI90/mnIENQFhoTdBDy9hL0HHSX3Xn9GAr4+gpmmo qtNDX4OviiStvJzlB4TsY//H1G1wwlAcBYvx2JiMj4RDmc+2IkoJgpktgVdPkqvUaxVNW4w LpGJhmhVVW8+twlJw7VXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:sWwXQZemze8=:kJBiwlXZ5/LUtwp/ELjRt+ gA89zkXEV3puoZSBqtwIKIQxM8zb6fkbeixBlAVEIdNZdBDQzViMSELyP8HAXmuVdTHH8lyA4 6OWKlkpjWvI/K4Vvx3qHYfmgQpo4mATjaILv05nL2KZGiBPs7TGzCm1xlVobdw2QErgWc8p8R rIAcNjx5zGfiVByxe3wO3U0gQnLnDHF1eixMzzPhJWPwtW0/7riYzakswdApOnNim4WBaOvcW rOKk/+Bl1AAzt4ljwqCbEUmL808UUyJh7sZgoqnmbOUO/4H5qVkDt1q61c7xA+RcW+mMKrDhA jsE2QWdIHDQfHKo3XNxDbjcI2wcytL3A9IcgBf7khecnw85jQ1nQHsNPzMf066D33T+5Jiz6U ZzzSz3qa4b4yXr2jh5f15ryuFs9OurIFCGzQc7lV+5xVERq0tsrQCEhlQZ3qtyxzUbckm8a6j RGcIPNhuUbdLG0eyZ/2mhPXBTPxgvHu2ai3DvdwRPkdtM062pxFBmmb6yUyOPpV+a/yxAhElA DHWmQpZ9XV6M3vozcNN0zW2Jtm1oENIPE4YYXkviwJeLjnlYOKn4drgoChLqK98sOff1I0VWX O4Jr7yDOhSqBRsBObxRtvpifuM49+NRHN2jpQ8psW8KRKdbq2YGqgrwumNc7FxiPw9g01tt6S gvv82R8E+FCC6LKdSIMVITMerP9siiDALeGyLjVbAl3f8TLnwxS5cbolL9EniuIIx2tw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HI0oUaD4APtD3pgfaJhDO8J9tqqngxF9d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Adding an 'invisible property to an overlay seems to break stacking of fa= ces. To reproduce, run the following snippet. The whole buffer should have a r= ed background, but the invisible section does not inherit that background. (with-current-buffer (get-buffer-create "bug") (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))) I initially thought this was an issue of priorities, but removing the ove= rlay with the invisible property makes the issue disappear. Similarly, removing the= underline overlay makes the issue disappear. Here is another (more "real-world") way to reproduce this issue (run the 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))) 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))) Interestingly, the first example is broken in both 24.4 and emacs-25; but= the second one is broken only in emacs-25 (the third one does not run in= Emacs 24.4). I wonder if this is connected to another issue that I've seen, where havi= ng a composition (using prettify-symbols-mode) just before an invisible r= egion would cause the background of the invisible region to be incorrect,= but setting prettify-symbols-unprettify-at-point and moving the point to= the edge of the symbol would cause the background to be fine. Unfortunat= ely I don't have a good repro for that issue. Cheers, Cl=C3=A9ment. In GNU Emacs 25.0.50.8 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2015-12-29 built on clem-w50-mint Repository revision: a21bb238ce7bcc9c13a9cf66db77918304daa2fc Windowing system distributor 'The X.Org Foundation', version 11.0.1150100= 0 System Description: Linux Mint 17.2 Rafaela Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=3Dibus locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: recentf-mode: t ido-ubiquitous-mode: t keybindings-global-mode: t keybindings-minor-mode: t ido-everywhere: t flycheck-pos-tip-mode: t global-company-mode: t company-mode: t global-page-break-lines-mode: t which-key-mode: t delete-selection-mode: t show-paren-mode: t save-place-mode: t savehist-mode: t xterm-mouse-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Features: (shadow sort ws-butler flyspell ispell ruler-mode gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils smex recentf tree-widget company-math math-symbol-lists company-files company-oddmuse company-keywords company-etags etags xref project company-gtags company-dabbrev-code company-dabbrev company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-css company-nxml company-bbdb ido-ubiquitous s ucs-normalize ido-completing-read+ cus-edit cus-start cus-load wid-edit autoloads ido haskell-prettify flycheck-pos-tip pos-tip flycheck find-func rx subr-x jka-compr let-alist proof-site proof-autoloads pg-vars company agda2 smart-mode-line-dark-theme smart-mode-line rich-minority page-break-lines diminish which-key which-func imenu elapsed time eml-mode derived demo-mode dash always-make-directory easy-escape easy-mmode delsel paren saveplace savehist xt-mouse finder-inf edmacro kmacro advice tex-site cl-seq cl eieio eieio-core cl-macs info package epg-config compatibility seq byte-opt gv compile comint ansi-color ring bytecomp byte-compile cl-extra help-mode easymenu cl-loaddefs pcase cl-lib cconv tangomod-dark-theme time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 433672 15194) (symbols 48 33265 1) (miscs 40 54 211) (strings 32 81160 11716) (string-bytes 1 2094594) (vectors 16 42572) (vector-slots 8 774284 7488) (floats 8 294 55) (intervals 56 2934 164) (buffers 976 14) (heap 1024 43373 1840)) --HI0oUaD4APtD3pgfaJhDO8J9tqqngxF9d 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) iQIcBAEBAgAGBQJWjVciAAoJEPqg+cTm90wjhUcP/RJ/TIJ0Fp8zrMlrL0gvbg7i awQHJ5J5OoScrI8VTf8xbAucsJ8Yfr3+uVo5BsH1SGbSumzNKN35fkeX9l2wtFlq HlVIJk8xRUpZccBsq53HLJSaPGRwxDso66DN25AYYzz+HYVeavgfV9SuTi/j1Yn1 MIwKC4x4l1SQs0kUw1zaB2nNkxOZ7NjBaLBXRYXC38SDcBqHh7reQIRswlAj0ub1 MjWe3jnJ8WpuxP3ZP5hEywT79zU+3FaRdOe8I0E8uB8FdmKvsmmjWT5oYahh6TbJ c34iIUSqZlgFZX+SXnVxKX+yrY0gDoaVTqYagMgtg0LrBpNOlPURIpNV+EtGT/BL xHOQ9lWT+90bX+f+GeaasEBuAs0eOc5NNxKzffFwyfReQLjoM8ATvunUSzB0O7iz WonwCIK0pwjuTcinN9xtaLKCeAhRq03OLeIyfQpXcVKCfBVTGzb2IP6hZmpupiC4 JIOA6wQkaDg0733vX2iBaxllQ1y+quWATGFdmkU49lEPEphKthKDYe9x5ti1Ti4j Ly1GXzjNrTL+ynJVhOBBZfhXdC6xyQj5qWOCS+1Kzv9i+NtxpZbxeePrdcRgvBq7 ZHj3MhS8vDVtbUR+AOl0FgymTMrSQr02gmlTY8xmj7ocFiFvEUH0tZv5EEL0FKsm c7d8fu2CBQjAAW/nKi9n =JrVL -----END PGP SIGNATURE----- --HI0oUaD4APtD3pgfaJhDO8J9tqqngxF9d-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 10:54:43 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 15:54:44 +0000 Received: from localhost ([127.0.0.1]:41863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHCtf-0002Hh-MW for submit@debbugs.gnu.org; Thu, 07 Jan 2016 10:54:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47540) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHCte-0002HV-Ap for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 10:54:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHCtU-0007It-Fg for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 10:54:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHCtU-0007Io-3A; Thu, 07 Jan 2016 10:54:32 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1664 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHCtS-0000F6-1G; Thu, 07 Jan 2016 10:54:31 -0500 Date: Thu, 07 Jan 2016 17:54:41 +0200 Message-Id: <83io352xmm.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568D5721.7060709@live.com> (message from =?utf-8?Q?Cl=C3=A9m?= =?utf-8?Q?ent?= Pit--Claudel on Wed, 6 Jan 2016 13:04:17 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Clément Pit--Claudel > Date: Wed, 6 Jan 2016 13:04:17 -0500 > > Adding an 'invisible property to an overlay seems to break stacking of faces. > To reproduce, run the following snippet. The whole buffer should have a red > background, but the invisible section does not inherit that background. > > (with-current-buffer (get-buffer-create "bug") > (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))) > > I initially thought this was an issue of priorities, but removing the overlay > with > the invisible property makes the issue disappear. Similarly, removing the > underline overlay makes the issue disappear. 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: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg00338.html 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: (let ((ov (make-overlay 8 9))) (overlay-put ov 'face '(:underline t))) The "problem" doesn't happen. > Here is another (more "real-world") way to reproduce this issue (run the > 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))) 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? > 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))) 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? > Interestingly, the first example is broken in both 24.4 and emacs-25; but the > second one is broken only in emacs-25 (the third one does not run in Emacs > 24.4). This behavior should be present in any Emacs released after Apr 2005. > I wonder if this is connected to another issue that I've seen, where having a > composition (using prettify-symbols-mode) just before an invisible region would > cause the background of the invisible region to be incorrect, but setting > prettify-symbols-unprettify-at-point and moving the point to the edge of the > symbol would cause the background to be fine. Unfortunately I don't have a good > repro for that issue. Hard to tell without a reproducible test case. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 12:03:49 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 17:03:49 +0000 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 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 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 Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces To: Eli Zaretskii References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= X-Enigmail-Draft-Status: N1110 Message-ID: <568E9A6A.2050201@live.com> Date: Thu, 7 Jan 2016 12:03:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <83io352xmm.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uis9wSHPL2cshgcLUFf2NaknIKOMtQbur" 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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) 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-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 12:36:46 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 17:36:46 +0000 Received: from localhost ([127.0.0.1]:41902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHEUQ-0004gA-Gi for submit@debbugs.gnu.org; Thu, 07 Jan 2016 12:36:46 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:53794) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHEUO-0004fx-Fn for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 12:36:45 -0500 Received: from [18.189.87.242] ([18.189.87.242]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MTxmj-1ahwRD2A9R-00Qhf9; Thu, 07 Jan 2016 18:36:38 +0100 Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces To: Eli Zaretskii References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Message-ID: <568EA223.4060805@live.com> Date: Thu, 7 Jan 2016 12:36:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <568E9A6A.2050201@live.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jC8pboo1IAEVBPPEiL02jHIkBM2akWhVE" X-Provags-ID: V03:K0:lRX0enE5gLMpySeRaI1EKU3Bh7yPEQ9Fkp8C9bICL0MEJk+4x4M WQ2CYtMTcGpHk6lKH4HInHJZj0GLgUMFNf0iJk6pD4l57GhCD5HDJbv8CNezjq2Sonv7F9J BHV4SoFPyBdxkUTnk2wgblKTLFOQJ+fHrYX6k/FUtUpRAmvWk78/A+Zoga10dY5FwStc3za 2XoBXjJNywnudDbUDtueQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3hd1K/V/994=:AUyYHHQ0pYxTOfs6g1bCsN O5R2hnCtITmejplhQQ91LbbvS2/g1vpVElYlNLJQHYZur7hb+WIzh3TzV2oz2u1ub9o4h5aJL FHKY3wmPIkQf8bUgW8mrPRYIZnkTYwNGcNzWlT2eHwu/N7BArw//DHvE7i6tyEIFeMCmSZDI+ 4Mfg5auwouOynWa6B299VufM/O+18CurtHU0U+tV8BtzW3p7KG7nJMWsgBY3bMr4+qpQrfgm2 dx8glKAEPvHsm4cWxLC+Dj27PVoCuOFfeHF0QxDFY5F6hP+0KeaqhPLT8kAUaLVZGknece5vM QVlMPWcXyKg7rA5ytDXXk/rgbxpbOBYPzkiYvlo4xNRRmarDYYDSjCqdIwEx4tMZ8OZViwcwm 6x7a3MyMsOE9bglymOqFYDQJpUyDtpn9jrNa554bLx2kuSylNlToq5q9aw+gyigO3wdaQ2iNe XCaV6/Qz7V0kQyfKROznw3kC4MJtWvPY6H/115CY8gjrPBchwBJARJi9dE0AFjj/JJfhNvjyh Kb7M9qWIlK6420nm/UkYCowk0ibPIP/DhXiVKPlmZJXMkMDKhA5zL3yGXbO4sfbYfnLj8QQ52 9OWTvDRbSyN019KE4V1s8wlnvmz2hwXAboQHc0HVh9vMFA5Jpg09K7Ng6U3bSsf2Ds3EXhLLN h2DrX/CzbSQvXqiORBl/1IFT5Q5ed2tTE9/M1H2lEPsULv1QBdo7GdMTJe/q9W4DWnYQ= X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jC8pboo1IAEVBPPEiL02jHIkBM2akWhVE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2016 12:03 PM, Cl=C3=A9ment Pit--Claudel wrote: >> You can read the discussion which led to the current implementation >> here: >> >> http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-04/msg00338= =2Ehtml Interestingly, even after disabling the fix for the issue that led to it,= I can't reproduce the issue posted there. Instead, I get the behaviour t= hat I described in my previous mail. Am I doing it wrong? =46rom 7648ca61042cd6c54bce94ce9f8938e176a8d083 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Cl=3DC3=3DA9ment=3D20Pit--Claudel?=3D Date: Thu, 7 Jan 2016 12:30:30 -0500 Subject: [PATCH] Don't set overlay face to default --- src/xdisp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index b18bfd0..4ddae50 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -4586,8 +4586,9 @@ setup_for_ellipsis (struct it *it, int len) /* Remember the current face id in case glyphs specify faces. IT's face is restored in set_iterator_to_next. saved_face_id was set to preceding char's face in handle_stop. */ - if (it->saved_face_id < 0 || it->saved_face_id !=3D it->face_id) - it->saved_face_id =3D it->face_id =3D DEFAULT_FACE_ID; + /* if (it->saved_face_id < 0 || it->saved_face_id !=3D it->face_id) */= + /* it->saved_face_id =3D it->face_id =3D DEFAULT_FACE_ID; */ =20 /* If the ellipsis represents buffer text, it means we advanced in the buffer, so we should no longer ignore overlay strings. */ --=20 2.7.0 --jC8pboo1IAEVBPPEiL02jHIkBM2akWhVE 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) iQIcBAEBAgAGBQJWjqIkAAoJEPqg+cTm90wjIiEP/35wT1g+tpBd22vKEo8kz47o TWpNsLwKmEHDL+qD5h09eTNKmIfVI9D//9lRd23NXJEjLdq2f6oDTViusFArG+3p hC/qBil0VjGCgtr0OgNejNxwLEF6hpbAdmijrlF7oYZ4gStiWcyjMlbaelTHY44z UPNU3TsMMaOFHIjvT3wThWKgPRMYLeN4wHONyXJwpdZbVzSd8bnxIzma0lgHfSUh qd9Y70iGBwQcUNye4VNiyVRClbpG35Nakh2ItJuV61kzoxMErvcu4umAjQMF3KDG 2gWeYk+FSOvrzv/Ri/01TY3m3RQQhgM+kFTVJLsewjwHwHTfV7GZZ0J/3QlfbONj sN9OySTr8hjaB1TAX4RYv0m8LjwIzfh0oIctnPEUmCjprgw2pxNRpIOVz4z4SgdH BbP5SXiC/xHHSutKGvLGuLfiXVApHGQC5k/PMRg+3nbkp6TCWNa9BinFRzjvE0K1 4vdILNe+Y3gNsCTrDhhj6XJomhhx7AUsXthB0EpforV0DSvgVPfxK+F4PZM13812 znIQBB+xIvmsWVcDd6K9kxlW1DM+0WiFOCx2zzqyR5frP38TBlvkhdF3XJLGBe0E m+bifU5I42u4OQ6CVP92su/NXgQp849GYQzLkz/ejaiam4Qb7YJ1VlAFeBNIrfWL ZGu9aHImtrIOq1+q/aRE =gTW9 -----END PGP SIGNATURE----- --jC8pboo1IAEVBPPEiL02jHIkBM2akWhVE-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 13:20:00 2016 Received: (at control) by debbugs.gnu.org; 7 Jan 2016 18:20:00 +0000 Received: from localhost ([127.0.0.1]:41954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFAG-0005h9-Cp for submit@debbugs.gnu.org; Thu, 07 Jan 2016 13:20:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36139) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFAF-0005gx-EO for control@debbugs.gnu.org; Thu, 07 Jan 2016 13:19:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHFA7-0007XC-3o for control@debbugs.gnu.org; Thu, 07 Jan 2016 13:19:54 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFA6-0007X8-W3 for control@debbugs.gnu.org; Thu, 07 Jan 2016 13:19:51 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1878 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHFA6-0002Ef-9c for control@debbugs.gnu.org; Thu, 07 Jan 2016 13:19:50 -0500 Date: Thu, 07 Jan 2016 20:20:02 +0200 Message-Id: <8337u92qwd.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-reply-to: <568E97E7.2030604@live.com> (message from =?iso-8859-1?Q?Cl?= =?iso-8859-1?Q?=E9ment?= Pit--Claudel on Thu, 7 Jan 2016 11:52:55 -0500) Subject: Re: bug#22323: Font fallback causes inconsistent stacking of faces in overlays with invisible property References: <568E97E7.2030604@live.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) merge 22323 22320 thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 13:46:08 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 18:46:08 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Thu, 07 Jan 2016 20:46:07 +0200 Message-Id: <83ziwh1b4g.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568E9A6A.2050201@live.com> (message from =?utf-8?Q?Cl=C3=A9m?= =?utf-8?Q?ent?= Pit--Claudel on Thu, 7 Jan 2016 12:03:38 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 13:52:06 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 18:52:06 +0000 Received: from localhost ([127.0.0.1]:41974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFfJ-00087n-Pn for submit@debbugs.gnu.org; Thu, 07 Jan 2016 13:52:05 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45300) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFfI-00087K-4r for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 13:52:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHFf8-0001NZ-Qk for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 13:51:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHFf8-0001NV-NZ; Thu, 07 Jan 2016 13:51:54 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1929 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHFf8-0002jq-15; Thu, 07 Jan 2016 13:51:54 -0500 Date: Thu, 07 Jan 2016 20:52:06 +0200 Message-Id: <83y4c11auh.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568EA223.4060805@live.com> (message from =?utf-8?Q?Cl=C3=A9m?= =?utf-8?Q?ent?= Pit--Claudel on Thu, 7 Jan 2016 12:36:35 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <568EA223.4060805@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 22320@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 7 Jan 2016 12:36:35 -0500 > > Interestingly, even after disabling the fix for the issue that led to it, I can't reproduce the issue posted there. Instead, I get the behaviour that I described in my previous mail. I'm not surprised: a lot has changed in the display engine since 2005. The original issue was just the tip of an iceberg: the general problem was that the ellipsis would have an unpredictable face which depended on the face of the first invisible character. I think this is more confusing than what we have now, because that situation is by far much more common. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 14:07:26 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 19:07:27 +0000 Received: from localhost ([127.0.0.1]:41988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFuA-0008VP-MA for submit@debbugs.gnu.org; Thu, 07 Jan 2016 14:07:26 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:64373) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHFu8-0008V4-Vr for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 14:07:25 -0500 Received: from [18.189.87.242] ([18.189.87.242]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0M57sc-1a07hL12Bq-00zDWf; Thu, 07 Jan 2016 20:07:17 +0100 Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces To: Eli Zaretskii References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <568EA223.4060805@live.com> <83y4c11auh.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Message-ID: <568EB762.20605@live.com> Date: Thu, 7 Jan 2016 14:07:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <83y4c11auh.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ufI8idvujwWqgttrpqo1JpExVt3E1uO56" X-Provags-ID: V03:K0:frzG84h2/Mh4y7swTjfxkE0kUs0mKEB111L4Bspr67iSRl5rxZx SodWpyAvpuUYY9v3q4yGKXTvYU3j9Dib8Y1S/154a+cgNMU8PwxCrD5k9YJzLXjMAkqDtHz Rv3/FNd5gdijER2/WUyoe5dcT/J1ZyauU0lQ310fMIociYGnOLisfMEhfiTuI2LG7TcA7HM UKbon8fCkAt0+ZNDy2Ekw== X-UI-Out-Filterresults: notjunk:1;V01:K0:RH2YVa9q77I=:9F0Pq90EpZLLNlPvEwI8rg 6XWdCCR1alw1/2XZkYTIxtO4nIiNekS2zSfVL58mcb9hTRj/eWOIp/UaWeNqba9xmz/UJVpQW or7nsyiGfFdorpw7AznlAYemxBqszF4o01zBUIXQp9VXw3c3rYB2FjF8OCl0Yjb1i7A7d87CT EX0rMqVz+h3c+mYmTuHg0VmjOdEC73ipIX1g2LfWMuJ20BMhS7Noyt1+jAF0hGKK+RJBPFIF6 1znBZLRMeVhENxxR5IBVBlCxf+90JO35bOzhfociQvlN1K7dNVkxgmN+7O1qkuEiKfNVsQpj9 PFoKUfcxPmJVgwtZY/j4E6GEvst/8I4BWsVjxVFxJv88TN7fIBe1IY+Mm1M7I5z4P9Kbg2D95 vkPfjd2Y2milCutgai8lB8LDMSSpep/F5FMb+nYhEhyGGH5xTl8chl3b+ym37Jhe/N8oC/QKd OHTfHuvQOKM+tZY/wbCwevOMGVTLr7qcbruF2mSnp7q92OqMwsiCUM6+emas/1JeuIXo/iuZU uQn6WFYyUdXpsC5YkNKhYxgrKVq+KtiVNSEcK5pPuBsJhOiRKTkr4E6+mdA8yiWS2Tf7Fw0UI yTkucmDSefR2pEaVHwU8xdCvOZVxobezBfk1R7y5/nrCQcIO5RgNpMP9ypZh9HhytI+LVC+Gl BPTDdJIxBlVuQ4XmAO6dqudUaQrbb7VAT0RgXNTE6tSwtQRY7czeJgCH7WtL/odVPOic= X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ufI8idvujwWqgttrpqo1JpExVt3E1uO56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2016 01:52 PM, Eli Zaretskii wrote: >> Cc: 22320@debbugs.gnu.org >> From: Cl=C3=A9ment Pit--Claudel >> Date: Thu, 7 Jan 2016 12:36:35 -0500 >> >> Interestingly, even after disabling the fix for the issue that led to = it, I can't reproduce the issue posted there. Instead, I get the behaviou= r that I described in my previous mail. >=20 > I'm not surprised: a lot has changed in the display engine since > 2005. The original issue was just the tip of an iceberg: the general > problem was that the ellipsis would have an unpredictable face which > depended on the face of the first invisible character. I think this > is more confusing than what we have now, because that situation is by > far much more common. I find the current situation more confusing, as it introduces many incons= istencies. Inheriting the face of the first hidden character, and applyin= g it to each dot in the ellipsis, seems a lot more consistent to me (and = it does feel predictable). Of course there will be gotchas, but no more t= han with using the default face; on the other hand, the current heuristic= is rather unpredictable (at least the region selection example and the f= ace fallback example in my other message both felt confusing to me). The same problems exist for composition, but keeping the properties of th= e first character seems to work well there; maybe we could consider harmo= nizing both behaviors? (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 '(Br = =2E 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))) Thanks for your help with this issue! Cl=C3=A9ment. --ufI8idvujwWqgttrpqo1JpExVt3E1uO56 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) iQIcBAEBAgAGBQJWjrdiAAoJEPqg+cTm90wj8Y4P/3NC9DKJtRCxSTK0mmrjKrBq a2Tro1qSdp0SO57zRuFL/0nJzWDV/K5R073mlUfLMKwjF2qOA5hrb1Iu6hT+nMtg YC5iWQobky1x/XnnmVh1bhVOpUiP9veUajlcxv7RfMZdSOUnqfl1PsWwTrTVETPV OJbrbvARTKROmICFmDOhN2Fseh6XSKF97Gef27ypoAmz6LGCRl1G/K/cDpjg21go XKO7OH3duqUoSCl1veyLdujTl0pJMWzk34v3xhhvgkWBvGgNHl6et6bmWvBxE7ag 6J2nHaJoEK8Vn6iCrnaaSuRbfggbZzvEE+1zXZJzLW2J0Yv9hBju++kQw4DTpHlf zFukzzLqvebQzm8nxaE3vjExxNGHEmmnFJo5GCcJJiObgIyV0eNpM4vDmec7PEkT LwihMLpB4Cl2wJ6x+GHckjLtClz9sCDhdMOZ3sQbsboLHHEgSRMZY1G9S03ERPCe rFl8kOpKwScncE2dc7oGBjaWdQmb7nKwIwmAjxRVJ6GrW4etIacmCmN/laqCtmIj +poYaJZKPpQ57iRgi6uexeGhPlHANHZ8VsOph/W/fdIQfbUScBZ5rjOucTy1cgPx K7gzx30BuIbAomeBYzC0ZSc/tqPi/LiVXD++elvkGigU/ydJWgSu6akB7F+jNI0o nlyAz0vQu43Rw2ck+vye =DMYv -----END PGP SIGNATURE----- --ufI8idvujwWqgttrpqo1JpExVt3E1uO56-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 14:28:22 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 19:28:22 +0000 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 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 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 Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces To: Eli Zaretskii References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= X-Enigmail-Draft-Status: N1110 Message-ID: <568EBC49.6010405@live.com> Date: Thu, 7 Jan 2016 14:28:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <83ziwh1b4g.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uo74C1psDKstwUrNbDua3blXWQBOA0T5p" 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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) 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-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 15:12:42 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 20:12:42 +0000 Received: from localhost ([127.0.0.1]:42025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHGvK-0001dj-2D for submit@debbugs.gnu.org; Thu, 07 Jan 2016 15:12:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53081) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHGvI-0001dW-EZ for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 15:12:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHGv8-0003DH-JV for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 15:12:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHGv8-0003DD-GN; Thu, 07 Jan 2016 15:12:30 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2010 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHGv7-0003As-QD; Thu, 07 Jan 2016 15:12:30 -0500 Date: Thu, 07 Jan 2016 22:12:42 +0200 Message-Id: <83si291745.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568EB762.20605@live.com> (message from =?utf-8?Q?Cl=C3=A9men?= =?utf-8?Q?t?= Pit--Claudel on Thu, 7 Jan 2016 14:07:14 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <568EA223.4060805@live.com> <83y4c11auh.fsf@gnu.org> <568EB762.20605@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 22320@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 7 Jan 2016 14:07:14 -0500 > > I find the current situation more confusing, as it introduces many inconsistencies. Inheriting the face of the first hidden character, and applying it to each dot in the ellipsis, seems a lot more consistent to me (and it does feel predictable). I don't see how it would be less confusing: the invisible characters are invisible, so figuring out why some ellipses are in black, others in blue, still others have some non-default background colors, and some use a different font, sounds like mission impossible to me: you don't see the text that gives the ellipsis its looks. > The same problems exist for composition, but keeping the properties of the first character seems to work well there; maybe we could consider harmonizing both behaviors? I'm not sure I understand what exactly are you proposing to do. We cannot treat invisible text like we treat character compositions, each one invokes a very different machinery with distinct and very different features. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 15:35:05 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 20:35:05 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Thu, 07 Jan 2016 22:35:05 +0200 Message-Id: <83r3ht162u.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568EBC49.6010405@live.com> (message from =?utf-8?Q?Cl=C3=A9m?= =?utf-8?Q?ent?= Pit--Claudel on Thu, 7 Jan 2016 14:28:09 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> <568EBC49.6010405@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 16:02:55 2016 Received: (at 22320) by debbugs.gnu.org; 7 Jan 2016 21:02:55 +0000 Received: from localhost ([127.0.0.1]:42050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHHhv-0002q4-7N for submit@debbugs.gnu.org; Thu, 07 Jan 2016 16:02:55 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49492) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHHht-0002ps-QQ for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 16:02:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHHhk-0006EL-LV for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 16:02:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHHhk-0006E8-Ij; Thu, 07 Jan 2016 16:02:44 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2047 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHHhk-0008HA-3Z; Thu, 07 Jan 2016 16:02:44 -0500 Date: Thu, 07 Jan 2016 23:02:55 +0200 Message-Id: <83d1tdyuf4.fsf@gnu.org> From: Eli Zaretskii To: clement.pitclaudel@live.com In-reply-to: <83si291745.fsf@gnu.org> (message from Eli Zaretskii on Thu, 07 Jan 2016 22:12:42 +0200) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <568EA223.4060805@live.com> <83y4c11auh.fsf@gnu.org> <568EB762.20605@live.com> <83si291745.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Thu, 07 Jan 2016 22:12:42 +0200 > From: Eli Zaretskii > Cc: 22320@debbugs.gnu.org > > > The same problems exist for composition, but keeping the properties of the first character seems to work well there; maybe we could consider harmonizing both behaviors? > > I'm not sure I understand what exactly are you proposing to do. We > cannot treat invisible text like we treat character compositions, each > one invokes a very different machinery with distinct and very > different features. Here's a suggestion: ignore the face of the invisible text altogether, and instead always use the face of the last visible character. The patch to do that is below; it fixes all of your test cases. But since you would like to see the face of the invisible text show through, I'm not sure you will like it... WDYT? diff --git a/src/xdisp.c b/src/xdisp.c index 87a92fc..7e5f7df 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -4583,14 +4583,15 @@ setup_for_ellipsis (struct it *it, int len) it->current.dpvec_index = 0; it->dpvec_face_id = -1; - /* Reset the current face ID to default if the last visible - character and the first invisible character have different faces. - IT->saved_face_id was set in handle_stop to the face of the - preceding character, and will be different from IT->face_id only - if the invisible text skipped in handle_invisible_prop has some - non-default face. IT's face is restored in set_iterator_to_next. */ - if (it->saved_face_id < 0 || it->saved_face_id != it->face_id) - it->saved_face_id = it->face_id = DEFAULT_FACE_ID; + /* Use IT->saved_face_id for the ellipsis, so that it has the same + face as the preceding text. IT->saved_face_id was set in + handle_stop to the face of the preceding character, and will be + different from IT->face_id only if the invisible text skipped in + handle_invisible_prop has some non-default face. We thus ignore + the face of the invisible text when we display the ellipsis. + IT's face is restored in set_iterator_to_next. */ + if (it->saved_face_id >= 0) + it->face_id = it->saved_face_id; /* If the ellipsis represents buffer text, it means we advanced in the buffer, so we should no longer ignore overlay strings. */ From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 07 19:27:43 2016 Received: (at 22320) by debbugs.gnu.org; 8 Jan 2016 00:27:43 +0000 Received: from localhost ([127.0.0.1]:42079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHKu7-0007UX-3i for submit@debbugs.gnu.org; Thu, 07 Jan 2016 19:27:43 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:51267) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHKu5-0007UJ-0o for 22320@debbugs.gnu.org; Thu, 07 Jan 2016 19:27:41 -0500 Received: from [18.189.101.34] ([18.189.101.34]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M1eYM-1ZxCUJ1u3u-00tl1D; Fri, 08 Jan 2016 01:27:33 +0100 Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces To: Eli Zaretskii References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> <568EBC49.6010405@live.com> <83r3ht162u.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= X-Enigmail-Draft-Status: N1110 Message-ID: <568F0272.9040105@live.com> Date: Thu, 7 Jan 2016 19:27:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <83r3ht162u.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cgMqfILuWwGW3wD9WQnMtXeRD5dl9TQr7" X-Provags-ID: V03:K0:jhbiLnA4DtA9fqItXBEbDF7paNp1Va08x9t6ElZlNkmtnWr9B1r kq/VUaF67YJpFWH4zCNN7Q5bq3rqTcKLZyqTeKVvHCpMM+J/t/bSDREkb3kV44KSuLBEjmY Z0/O/+4/O5n5GLy8oKZ7qLIoPgRkhXC2wWE7f35RIqG6uxZTz7OtiRB85b3BIUehxKQYEhS viB4AGBZBM+ScIFNi+THA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lv97YBc9udY=:8YMsAhtvRrvxD2U+1ROsfw R2oTEWzPTZzU1F9g89wqJa8kS33AU8si8sNgLu7+VcVwUXg6L3gNjY6B/UgajKfNMKLDtDMrD 5TgCg26eLV3g0kbmV4sqAnaNBPitctEQY9xjZn+6UHS9kDuPrK1LPxBrOcMoJMNuW8oOideM3 +vAzHw/5FJj4OuHYklKlWMkU2Zo12A+MzdOSUy07+EbQTkCRMvgSYES6GJDsQ6XmU+p2kJ1V0 +p8giuIZ8FHXqne40pRJhyqsi2MFdXh49E13VHT81TL6vDA86yxQ4i1ewOQrHH5CEAOQDFK6Z kYL2Ha+Prv0mwztzkIDw4CcVVGh0vMQVetxkBplp0NIZfCUxBbsL6U3hsrqJ3uDuf8e4PrqU3 nVlPQjHEyPJ9UTQTXYd95liT/rD++TjsSGbr0JlLI+tFfcV7AgoaRTDFR4QaReubYscuqbV06 9ob2tJn4Mg4tCMTXmmAcmYfRDhTQOwlK4Ved0IuY/TbTE1kZEn3E3rEDmo+awCCNu0BibaPRV SVUsVXRvR5TcvOoV5FDvLTbRM1WBs4uwn/eDHz4rq2EbPbCPNyTiPlai1yYM+yNHxzQXI63U1 leSqQ6q3p7zqUvNca1lrk4kNwoABvAYdRnfp4NwiDDXwqsWefkMH++g+aIsd7qJRtQ1LQuiwP j1RqNamM9NvdOlHvNkqGNf6sPQfVKl7vTaxJ1SxuLHCRQCRZhAEHFxbXdQF9sAnXMSAk= X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cgMqfILuWwGW3wD9WQnMtXeRD5dl9TQr7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2016 03:35 PM, Eli Zaretskii wrote: >>> 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=20 > let's merge it with the default is asking for a no-op. It will > change nothing. Yes, sorry for being unclear. Hopefully the following is more clear. For = any overlay/invisible section pair there are five cases, right? 1. The overlay does not intersect with the invisible area. No problems he= re. 2. The overlay covers a few characters before the invisible area and the = first few characters of the invisible area, but not the last ones. 3. The overlay covers a few characters after the invisible area and the l= ast few characters of the invisible area, but not the first ones. 4. The overlay is a subset of the invisible area. 5. The overlay is a superset of the invisible area. The current solution doesn't think in these terms; instead, it ignores al= l overlays for the ellipses, unless the first hidden character has the sa= me face as the preceding one. Always applying the face of the first character to the ellipsis means app= lying to the ellipsis the faces of overlays in categories 2, 5, and 4 if = they cover the first character. You pointed out that the special case of = 4 is confusing. Another option (the one I was trying to explain above) is to apply to the= ellipsis only the faces of overlays in category 5. I feel that this shou= ld be rather uncontroversial (don't you think?). The problem with this way of thinking about overlays and invisible text i= s that it doesn't necessarily map directly to the implementation. IIUC, t= he current implementation computes faces without taking invisibility into= account for the first character before and after the left boundary of th= e invisible section, and then compares them. At this point it's too late = to merge certain faces but not others. Thanks again for your explanations and your time. --cgMqfILuWwGW3wD9WQnMtXeRD5dl9TQr7 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) iQIbBAEBAgAGBQJWjwJyAAoJEPqg+cTm90wjIdkP906vSdnU0lrMrll0lPFm1TUo evN7G5vGFCIra8lEBZvZFOQdlhcrnOHXF8h+yCkdIDIaENp2EH34EDu71PgXOvvJ C3c3BKSkTibNdbRhwXC60GhUnXEQw24a9dhm8x23uYuQTxSJP8gwOebiAHzR0ywT PRqonavIN/d4dWqIaYWJxOZPNyhziYiq6pcbhdvQq+WRMDRojfoveTKvM2xlA0Hs 43591v8HGk34/QFg9K4XSGaIJSQJaxbBODk6rCnC/XSDwrQyGLHdx6S64b/CGPoE +92838ukhQKK0yL4K3cf6mU6VdWisogAW0qqCa842rZnM4++XFAEmEQUuoi+a6p7 LM1cS7VRkdhQAokT0qkC96/0pAXwJtxrZ7pA4gGS50aMhzt4AK0SgsIg2cQBlspR 82DxNeCwlmyq08cmMgA1Xfdh4PafXO4hHOM0acGX4efcaV98TxkqVJ+BfTMAeMYb gUz6Z8Fs6sl7vqSAL7pSjqwaig6bSF06zfam7BK0I5MMfjRfQLkMKvLgTyjjwEM3 kyjn/nO/JWEx1ZQmuf9praWfxORQA9EBxb/sgKNBbc9BHdCCWy7TC/bf5IxOJJeP DvJexAyq+OSTN1GV+GlWluDquQu/pNYI0k9DdvQGgelKMhu0uSZdCPDZPj2rrb0u sjFhk1m+qZCkf+PZg7o= =14Xf -----END PGP SIGNATURE----- --cgMqfILuWwGW3wD9WQnMtXeRD5dl9TQr7-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 08 05:28:21 2016 Received: (at 22320) by debbugs.gnu.org; 8 Jan 2016 10:28:21 +0000 Received: from localhost ([127.0.0.1]:42302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHUHN-0008Jf-3k for submit@debbugs.gnu.org; Fri, 08 Jan 2016 05:28:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55601) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aHUHK-0008JK-Mj for 22320@debbugs.gnu.org; Fri, 08 Jan 2016 05:28:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHUHC-0005uG-8b for 22320@debbugs.gnu.org; Fri, 08 Jan 2016 05:28:13 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHUHC-0005uC-5H; Fri, 08 Jan 2016 05:28:10 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1225 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aHUH9-0000Gm-22; Fri, 08 Jan 2016 05:28:07 -0500 Date: Fri, 08 Jan 2016 12:28:05 +0200 Message-Id: <83r3hspdqi.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel In-reply-to: <568F0272.9040105@live.com> (message from =?utf-8?Q?Cl=C3=A9m?= =?utf-8?Q?ent?= Pit--Claudel on Thu, 7 Jan 2016 19:27:30 -0500) Subject: Re: bug#22320: Overlays with an 'invisible property break stacking of overlay faces References: <568D5721.7060709@live.com> <83io352xmm.fsf@gnu.org> <568E9A6A.2050201@live.com> <83ziwh1b4g.fsf@gnu.org> <568EBC49.6010405@live.com> <83r3ht162u.fsf@gnu.org> <568F0272.9040105@live.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22320 Cc: 22320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 22320@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 7 Jan 2016 19:27:30 -0500 > > 1. The overlay does not intersect with the invisible area. No problems here. > 2. The overlay covers a few characters before the invisible area and the first few characters of the invisible area, but not the last ones. In this case, Emacs doesn't care where the overlay ends, that buffer position is skipped without checking overlays. > 3. The overlay covers a few characters after the invisible area and the last few characters of the invisible area, but not the first ones. Likewise. > 4. The overlay is a subset of the invisible area. If it starts on the first invisible character, Emacs will take note; otherwise it won't. > 5. The overlay is a superset of the invisible area. This is the case with all your use cases. > The current solution doesn't think in these terms; instead, it ignores all overlays for the ellipses, unless the first hidden character has the same face as the preceding one. > > Always applying the face of the first character to the ellipsis means applying to the ellipsis the faces of overlays in categories 2, 5, and 4 if they cover the first character. You pointed out that the special case of 4 is confusing. > > Another option (the one I was trying to explain above) is to apply to the ellipsis only the faces of overlays in category 5. I feel that this should be rather uncontroversial (don't you think?). Well, now that I've committed what I believe is a better solution, I think we can put these issues to rest. > IIUC, the current implementation computes faces without taking invisibility into account for the first character before and after the left boundary of the invisible section, and then compares them. At this point it's too late to merge certain faces but not others. Yes. More accurately, the display engine always considers faces before it considers invisibility, so it always sees the face of the first invisible character. From unknown Mon Aug 11 18:15:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 05 Feb 2016 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator