From rms@gnu.org Wed Oct 15 21:42:08 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.3 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,FOURLA,FVGT_m_MULTI_ODD,IMPRONONCABLE_1,MURPHY_DRUGS_REL8, MURPHY_WRONG_WORD2,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 16 Oct 2008 04:42:08 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9G4g2xb005327 for ; Wed, 15 Oct 2008 21:42:04 -0700 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KqKe1-0004PD-Jl; Thu, 16 Oct 2008 00:39:29 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: "Richard M. Stallman" To: emacs-pretest-bug@gnu.org Subject: redisplay bugs Reply-to: rms@gnu.org Message-Id: Date: Wed, 15 Oct 2008 12:10:01 -0400 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) I found this while reviewing old mail. I think I may have fixed one or two of these bugs, but most of them probably still exist. There are four messages included below. X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 To: bug-gnu-emacs@gnu.org From: Joe Wells Date: Wed, 19 Sep 2007 14:18:07 +0100 Message-ID: <86ps0ebxps.fsf@macs.hw.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: anomalies of overlays and before-string and display properties There are a number of strange anomalies (some clearly bugs) in the behavior of overlays and before-string and display properties. 1. Faces on a display property on a before-string behave differently depending on where the display property is in the before-string. For a display property at the beginning of the before-string, its face is used and the before-string's face is ignored (I think this is correct). For a display property not at the beginning of the before-string, its face is completely ignored, and the face of the before-string is used instead. This is fairly clearly a bug. 2. When a substring of a before-string beginning at offset O has a display property which is a string S, the first O characters of S are not displayed. If S is not at least O+1 characters long, then disastrous things start to happen. This is clearly a bug. 3. The before-string somehow œôòüinheritsœôòý face attributes from the face of the character that follows the start of the overlay. (If the overlay is of length zero, this character is not even in the overlay. See the recent discussion of how this problem is affecting linum.el.) This means that in practice a before-string needs to use completely specified faces, which is obviously a real pain. 4. The display property of an overlay somehow œôòüinheritsœôòý face attributes from the face of the character that follows the start of the overlay. This has similar disadvantages to anomaly #3 mentioned above. 5. The help-echo and mouse-face properties of an overlay with both a before-string and a display property only affect the material displayed by the overlay's display property. One can work around the issue by copying these properties to the various display properties inside the before-string; however, this workaround is a pain and in the case of mouse-face it doesn't get the entire overlay highlighted at once but instead only the pieces are highlighted one at a time. It would be nice to be able to set a single help-echo or a single mouse-face property that would affect the _entire_ overlay. You can reproduce all of these anomalies with this function: (defun illustrate-anomalies () (let ((s #1=#("\\abcd{VWXYZ}" 0 5 (face (:foreground "Purple" :background "yellow")) 5 12 (face (:foreground "DarkOliveGreen" :weight bold :slant oblique :height 0.8)))) (props '(help-echo #1# ;;face (:slant italic :foreground "red") display "]" before-string #(" " 0 1 (display #("|[" 0 2 (;; help-echo #1# face #2=(:strike-through t :background "white"))) ;; help-echo #1# face #3=(:underline t)) 1 2 (display #("||VWXYZ" 0 7 (;; help-echo #1# ;; mouse-face (:background "darkseagreen2") face #2#)) ;; help-echo #1# face #3#)) mouse-face (:background "darkseagreen2"))) (buf (get-buffer-create "xyzzy"))) (with-current-buffer buf (display-buffer buf) (erase-buffer) (dolist (o (overlays-in (point-min) (point-max))) (delete-overlay o)) (insert s) (let ((o (make-overlay (point-min) (point-max)))) (while props (overlay-put o (car props) (cadr props)) (setq props (nthcdr 2 props))))))) This example is derived from some work where I was trying to get AUCTeX's folding mode to show the fontified and latex-previewed contents of macro arguments. I hope this problem report is useful. Joe ====================================================================== In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-06-27 on artemis Windowing system distributor `The X.Org Foundation', version 11.0.70000000 configured using `configure '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: en_US.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: jbw value of $LANG: nil locale-coding-system: utf-8 default-enable-multibyte-characters: t Minor modes in effect: outline-minor-mode: t desktop-save-mode: t url-handler-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t size-indication-mode: t line-number-mode: t transient-mark-mode: t X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 To: bug-gnu-emacs@gnu.org From: Joe Wells Date: Wed, 19 Sep 2007 14:27:22 +0100 In-Reply-To: <86ps0ebxps.fsf@macs.hw.ac.uk> (Joe Wells's message of "Wed\, 19 Sep 2007 14\:18\:07 +0100") Message-ID: <86lkb2bxad.fsf@macs.hw.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: anomalies of overlays and before-string and display properties By the way, with one exception, these problems also occur with after-string properties. The exception is that the overlay's mouse-face property does correctly cover both the overlays display and after-string properties. This is more evidence that not covering the before-string property is a bug. Strangely, the after-string also œôòüinheritsœôòý face attributes from the character after the beginning of the overlay, not the character just before the _end_ of the overlay. This is more evidence that this is a bug and not a feature. Joe Joe Wells writes: > There are a number of strange anomalies (some clearly bugs) in the > behavior of overlays and before-string and display properties. > > 1. Faces on a display property on a before-string behave differently > depending on where the display property is in the before-string. > For a display property at the beginning of the before-string, its > face is used and the before-string's face is ignored (I think this > is correct). For a display property not at the beginning of the > before-string, its face is completely ignored, and the face of the > before-string is used instead. This is fairly clearly a bug. > > 2. When a substring of a before-string beginning at offset O has a > display property which is a string S, the first O characters of S > are not displayed. If S is not at least O+1 characters long, then > disastrous things start to happen. This is clearly a bug. > > 3. The before-string somehow œôòüinheritsœôòý face attributes from the face > of the character that follows the start of the overlay. (If the > overlay is of length zero, this character is not even in the > overlay. See the recent discussion of how this problem is > affecting linum.el.) This means that in practice a before-string > needs to use completely specified faces, which is obviously a real > pain. > > 4. The display property of an overlay somehow œôòüinheritsœôòý face > attributes from the face of the character that follows the start of > the overlay. This has similar disadvantages to anomaly #3 > mentioned above. > > 5. The help-echo and mouse-face properties of an overlay with both a > before-string and a display property only affect the material > displayed by the overlay's display property. One can work around > the issue by copying these properties to the various display > properties inside the before-string; however, this workaround is a > pain and in the case of mouse-face it doesn't get the entire > overlay highlighted at once but instead only the pieces are > highlighted one at a time. It would be nice to be able to set a > single help-echo or a single mouse-face property that would affect > the _entire_ overlay. > > You can reproduce all of these anomalies with this function: > > (defun illustrate-anomalies () > (let ((s #1=#("\\abcd{VWXYZ}" > 0 5 (face (:foreground "Purple" :background "yellow")) > 5 12 > (face > (:foreground > "DarkOliveGreen" > :weight bold :slant oblique :height 0.8)))) > (props > '(help-echo > #1# > ;;face (:slant italic :foreground "red") > display "]" > before-string > #(" " > 0 1 > (display > #("|[" > 0 2 (;; help-echo #1# > face #2=(:strike-through t :background "white"))) > ;; help-echo #1# > face #3=(:underline t)) > 1 2 > (display > #("||VWXYZ" > 0 7 (;; help-echo #1# > ;; mouse-face (:background "darkseagreen2") > face #2#)) > ;; help-echo #1# > face #3#)) > mouse-face (:background "darkseagreen2"))) > (buf (get-buffer-create "xyzzy"))) > (with-current-buffer buf > (display-buffer buf) > (erase-buffer) > (dolist (o (overlays-in (point-min) (point-max))) > (delete-overlay o)) > (insert s) > (let ((o (make-overlay (point-min) (point-max)))) > (while props > (overlay-put o (car props) (cadr props)) > (setq props (nthcdr 2 props))))))) > > This example is derived from some work where I was trying to get > AUCTeX's folding mode to show the fontified and latex-previewed > contents of macro arguments. > > I hope this problem report is useful. > > Joe > > ====================================================================== > In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) > of 2007-06-27 on artemis > Windowing system distributor `The X.Org Foundation', version 11.0.70000000 > configured using `configure '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb'' > > Important settings: > value of $LC_ALL: nil > value of $LC_COLLATE: nil > value of $LC_CTYPE: en_US.UTF-8 > value of $LC_MESSAGES: nil > value of $LC_MONETARY: nil > value of $LC_NUMERIC: nil > value of $LC_TIME: jbw > value of $LANG: nil > locale-coding-system: utf-8 > default-enable-multibyte-characters: t > > Minor modes in effect: > outline-minor-mode: t > desktop-save-mode: t > url-handler-mode: t > tooltip-mode: t > mouse-wheel-mode: t > file-name-shadow-mode: t > global-font-lock-mode: t > font-lock-mode: t > blink-cursor-mode: t > unify-8859-on-encoding-mode: t > utf-translate-cjk-mode: t > auto-compression-mode: t > temp-buffer-resize-mode: t > size-indication-mode: t > line-number-mode: t > transient-mark-mode: t X-Spam-Status: No, score=0.7 required=5.0 tests=SUBJ_HAS_SPACES autolearn=no version=3.1.0 To: rms@gnu.org Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Subject: Re: Fwd: overlay face property not used for after-string property From: Joe Wells Date: Mon, 29 Oct 2007 09:57:59 +0000 In-Reply-To: (Richard Stallman's message of "Mon\, 29 Oct 2007 05\:22\:23 -0400") Message-ID: <86bqaixmxk.fsf@macs.hw.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Richard Stallman writes: > > Can someone write a patch so that the overlay's face property (and > > other display-related properties) won't apply to its before-string? > > > > Joe, what do you think about that as a solution? > > I think that would be an improvement. I think the best solution would > be for the face property of an overlay (and similar properties) to not > apply to the before-string, the after-string, _and_ the display > property of the overlay. > > Can someone implement that? It should not be fundamentally hard; > making the properties apply is what is hard. > > Note that there are additional problems. One example (which I have > already reported) is that the face of the character in the buffer > after the overlay start location (which is not even in the overlay if > the overlay is of length zero) is applied to the before-string and > display properties of the overlay. > > The fix we are discussing will get rid of this problem, right? No, the problem with the before-string/display/after-string properties being affected by a face from the buffer appears to be a completely unrelated issue which will need to be debugged separately. > Another example (which I think I > have not previously reported) is that the face of the character in the > buffer _after_ the overlay end location (which is _never_ in the > overlay) is applied to the after-string property. > > Let's consider that after this fix is done; perhaps this will > solve that other problem as a byproduct. I can't see any way that the change proposed here will help with that problem. By the way, changing topic to something else I mentioned in my earlier message:  Johan Bockgård pointed out in another message that the convenience functions font-lock-prepend-text-property and font-lock-append-text-property already exist for the purpose of adding faces to text (strings or buffer contents) that already have face properties. However, I have pointed out in a new bug report that these functions don't work correctly for all possible face property values (and indeed they sometimes raise errors). -- Joe X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 To: bug-gnu-emacs@gnu.org From: Joe Wells Date: Tue, 18 Sep 2007 23:20:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: redisplay goes horribly wrong when a before-string contains multiple display properties Redisplay goes horribly wrong when a before-string contains multiple display properties. Reproduce by evaluating this expression: (let ((buf (get-buffer-create "foo"))) (with-current-buffer buf (display-buffer buf) (erase-buffer) (dolist (o (overlays-in (point-min) (point-max))) (delete-overlay o)) (insert "ABC") (let ((o (make-overlay 2 3)) (s (make-string 5 ?X))) (put-text-property 0 1 'display "1" s) (put-text-property 1 2 'display "2" s) (put-text-property 2 3 'display "3" s) (put-text-property 3 4 'display "4" s) (put-text-property 4 5 'display "5" s) (overlay-put o 'display "Y") (overlay-put o 'before-string s)))) The correct behavior would be to see the buffer ?foo? pop up displaying the characters ?A12345YC?. The horribly wrong behavior that actually happens is that redisplay of the buffer stops completely after ?A1? is shown. Strangely, the ?XXXXX? (which should not be displayed anywhere) will be displayed in the echo area. Scary errors start occurring if one tries to do work in the buffer after this. By the way, it would be really nice if this worked, because it would be an easy way to display a number of display specifications for a single overlay, which would make it much easier to get the features of AUCTeX's tex-fold.el to work together with the features of latex-preview. (What is needed is being able to display strings interleaved with images.) Joe ====================================================================== In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-06-27 on artemis Windowing system distributor `The X.Org Foundation', version 11.0.70000000 configured using `configure '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: en_US.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: jbw value of $LANG: nil locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: TeX-source-specials-mode: t auto-fill-function: do-auto-fill shell-dirtrack-mode: t outline-minor-mode: t desktop-save-mode: t url-handler-mode: t tooltip-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 unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t size-indication-mode: t line-number-mode: t transient-mark-mode: t From rgm@gnu.org Mon Oct 20 19:14:55 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-12.3 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1176) by emacsbugs.donarmstrong.com; 21 Oct 2008 02:14:55 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9L2Eq4q015456 for <1176@emacsbugs.donarmstrong.com>; Mon, 20 Oct 2008 19:14:54 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Ks6jF-00056t-69; Mon, 20 Oct 2008 22:12:13 -0400 From: Glenn Morris To: 1176@debbugs.gnu.org Subject: Re: bug#1176: redisplay bugs References: X-Spook: AMW spies nuclear import AFSPC Kosovo e-bomb Albania X-Ran: y\G{N;,x~cNH%Lp-'_?MYFj'^ (Richard M. Stallman's message of "Wed, 15 Oct 2008 12:10:01 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Redisplay goes horribly wrong when a before-string contains multiple > display properties. > > Reproduce by evaluating this expression: > > (let ((buf (get-buffer-create "foo"))) > (with-current-buffer buf > (display-buffer buf) > (erase-buffer) > (dolist (o (overlays-in (point-min) (point-max))) > (delete-overlay o)) > (insert "ABC") > (let ((o (make-overlay 2 3)) > (s (make-string 5 ?X))) > (put-text-property 0 1 'display "1" s) > (put-text-property 1 2 'display "2" s) > (put-text-property 2 3 'display "3" s) > (put-text-property 3 4 'display "4" s) > (put-text-property 4 5 'display "5" s) > (overlay-put o 'display "Y") > (overlay-put o 'before-string s)))) > > The correct behavior would be to see the buffer ?foo? pop up > displaying the characters ?A12345YC?. The horribly wrong behavior > that actually happens is that redisplay of the buffer stops completely > after ?A1? is shown. This piece appears to be fixed in 22.2 and up. From rgm@gnu.org Mon Oct 20 19:50:54 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-12.3 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1176) by emacsbugs.donarmstrong.com; 21 Oct 2008 02:50:54 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9L2opOv024963 for <1176@emacsbugs.donarmstrong.com>; Mon, 20 Oct 2008 19:50:52 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Ks7I3-00066P-La; Mon, 20 Oct 2008 22:48:11 -0400 From: Glenn Morris To: 1176@debbugs.gnu.org Subject: Re: bug#1176: redisplay bugs References: X-Spook: David John Oates KGB strategic bank nitrate Honduras X-Ran: pTO:~9>X6Y>GnH(P!H6DB{oe6nv X-Hue: white X-Debbugs-No-Ack: yes X-Attribution: GM Date: Mon, 20 Oct 2008 22:48:11 -0400 In-Reply-To: (Richard M. Stallman's message of "Wed, 15 Oct 2008 12:10:01 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I found all this rather hard to understand. "I expected to see", "I actually saw", never mind separate bugs, would have made it a lot easier. > 1. Faces on a display property on a before-string behave differently > depending on where the display property is in the before-string. > For a display property at the beginning of the before-string, its > face is used and the before-string's face is ignored (I think this > is correct). For a display property not at the beginning of the > before-string, its face is completely ignored, and the face of the > before-string is used instead. Appears to be fixed in 22.2 and up. I base this on the strike-through face appearing on the whole before-string in 22.2, but only on the first two chars in 22.1. And on the background of only the first two characters being white in 22.1 (the rest being yellow), but all being white in 22.2 > 2. When a substring of a before-string beginning at offset O has a > display property which is a string S, the first O characters of S > are not displayed. If S is not at least O+1 characters long, then > disastrous things start to happen. This is clearly a bug. Appears to be fixed in 22.2 and up. I base this on seeing only one "|" before VWXYZ in 22.1, but two in 22.2. > 3. The before-string somehow inherits face attributes from the face > of the character that follows the start of the overlay. Appears to be fixed in 22.2 and up. I base this on seeing underlining and a yellow background on "VWXYZ" in 22.1, but not 22.2. > 4. The display property of an overlay somehow inherits face > attributes from the face of the character that follows the start of > the overlay. I think this one still applies. The "]" in the example has a yellow background. > 5. The help-echo and mouse-face properties of an overlay with both a > before-string and a display property only affect the material > displayed by the overlay's display property. This appears to still be the case. Only the "]" in the example has mouse-face and help-echo. From rgm@gnu.org Tue Oct 21 18:46:17 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-10.8 required=4.0 tests=AWL,BAYES_00, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1176-done) by emacsbugs.donarmstrong.com; 22 Oct 2008 01:46:17 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9M1kDxt011565 for <1176-done@emacsbugs.donarmstrong.com>; Tue, 21 Oct 2008 18:46:14 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KsSl2-0001Dw-MM; Tue, 21 Oct 2008 21:43:32 -0400 From: Glenn Morris To: 1176-done@debbugs.gnu.org Subject: Re: redisplay bugs References: X-Spook: smuggle Saudi Arabia CDMA Telex Vickie Weaver CISU TWA X-Ran: c'g#(i0,f)uukG\ho%?[blsgm"_}fRtd->or@DYo|,h*Otx+CQBe%v7'Xq (Richard M. Stallman's message of "Wed, 15 Oct 2008 12:10:01 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I am closing this extremely confusing (to me) uber-bug. I have opened separate reports for the outstanding issues. > 1. Faces on a display property on a before-string behave differently > depending on where the display property is in the before-string. > For a display property at the beginning of the before-string, its > face is used and the before-string's face is ignored (I think this > is correct). For a display property not at the beginning of the > before-string, its face is completely ignored, and the face of the > before-string is used instead. As mentioned before, this seems fixed. Here is a simpler test-case (which still looks crazy to me...): (let ((buff (generate-new-buffer "overlay test")) o) (with-current-buffer buff (insert "text") (setq o (make-overlay (point-min) (point-max))) (overlay-put o 'display "display") (overlay-put o 'before-string (concat (propertize "before-" 'face '(:background "green") 'display (propertize "BEFORE-" 'face '(:background "red"))) (propertize "string" 'face '(:background "yellow") 'display (propertize "STRING" 'face '(:background "blue"))))) (pop-to-buffer buff))) One sees "BEFORE-" with a red background and "STRING" with a blue background. > 2. When a substring of a before-string beginning at offset O has a > display property which is a string S, the first O characters of S > are not displayed. If S is not at least O+1 characters long, then > disastrous things start to happen. I have difficulty understanding this ("the first 0 characters" are not displayed?), but as I said before it seems to be fixed. > 3. The before-string somehow inherits face attributes from the face > of the character that follows the start of the overlay. It seems I was mistaken before, this still occurs. Opened as bug#1222. > 4. The display property of an overlay somehow inherits face > attributes from the face of the character that follows the start of > the overlay. Opened as bug#1222. > 5. The help-echo and mouse-face properties of an overlay with both a > before-string and a display property only affect the material > displayed by the overlay's display property. Opened as bugs #1220 and #1221. > The exception is that the overlay's mouse-face property does > correctly cover both the overlays display and after-string > properties. Mentioned in bug #1220. > Strangely, the after-string also inherits face attributes from the > character after the beginning of the overlay, not the character just > before the _end_ of the overlay. Mentioned in bug#1222. >>> Can someone write a patch so that the overlay's face property (and >>> other display-related properties) won't apply to its before-string? In Emacs 22.2 and up, overlay faces no longer apply to the before- and after- strings. They still affect the display part, which seems reasonable to me. Example: (let ((buff (generate-new-buffer "overlay test")) o) (with-current-buffer buff (insert "text") (setq o (make-overlay (point-min) (point-max))) (overlay-put o 'display "display") (overlay-put o 'face '(:background "blue")) (overlay-put o 'before-string "before") (overlay-put o 'after-string "after") (pop-to-buffer buff))) Only "display" has a blue background in 22.2 and up. This was also discussed on emacs-devel: http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01360.html > Redisplay goes horribly wrong when a before-string contains multiple > display properties. As mentioned before, this is fixed. From rgm@gnu.org Tue Oct 21 18:57:51 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-10.7 required=4.0 tests=AWL,BAYES_00,FOURLA, RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1176-quiet) by emacsbugs.donarmstrong.com; 22 Oct 2008 01:57:51 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9M1vm6H013940 for <1176-quiet@emacsbugs.donarmstrong.com>; Tue, 21 Oct 2008 18:57:49 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KsSwF-0001bt-DH; Tue, 21 Oct 2008 21:55:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18686.34811.338086.486059@fencepost.gnu.org> Date: Tue, 21 Oct 2008 21:55:07 -0400 From: Glenn Morris To: 1176-quiet@debbugs.gnu.org Subject: Re: redisplay bugs In-Reply-To: References: X-Attribution: GM X-Mailer: VM (www.wonderworks.com/vm), GNU Emacs (www.gnu.org/software/emacs) X-Hue: magenta X-Ran: k8-D9c"nR1Vuz47$L'ln:roE`(D%{127O6gCW?wj:oo~/~E|S29>j9A=u;#RKQfeaVLkQz X-Debbugs-No-Ack: yes Glenn Morris wrote (on Tue, 21 Oct 2008 at 21:43 -0400): > > 2. When a substring of a before-string beginning at offset O has a > > display property which is a string S, the first O characters of S > > are not displayed. If S is not at least O+1 characters long, then > > disastrous things start to happen. > > I have difficulty understanding this ("the first 0 characters" are not > displayed?), but as I said before it seems to be fixed. Oh, that is "O" the letter, not "0" the number. This example proves it is fixed in 22.2 and up: (let ((buff (generate-new-buffer "overlay test")) o) (with-current-buffer buff (insert "text") (setq o (make-overlay (point-min) (point-max))) (overlay-put o 'before-string (concat "be" (propertize "fore" 'display "FORE"))) (pop-to-buffer buff))) In 22.1, one sees "beREtext", in 22.2 "beFOREtext". From unknown Thu Jun 19 16:16:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Wed, 19 Nov 2008 15:24:04 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator