From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joe Wells Newsgroups: gmane.emacs.devel Subject: Re: Fwd: overlay face property not used for after-string property Date: Wed, 24 Oct 2007 10:49:06 +0100 Message-ID: <86d4v46dwt.fsf@macs.hw.ac.uk> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1193219407 22663 80.91.229.12 (24 Oct 2007 09:50:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2007 09:50:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 11:50:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IkcsH-0006cd-DC for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 11:50:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikcs9-000079-DA for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 05:49:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ikcrm-0008FU-RB for emacs-devel@gnu.org; Wed, 24 Oct 2007 05:49:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ikcri-0008By-3z for emacs-devel@gnu.org; Wed, 24 Oct 2007 05:49:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikcrh-0008Bq-VU for emacs-devel@gnu.org; Wed, 24 Oct 2007 05:49:30 -0400 Original-Received: from izanami.macs.hw.ac.uk ([137.195.13.6]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ikcrg-0006wg-Ml for emacs-devel@gnu.org; Wed, 24 Oct 2007 05:49:29 -0400 Original-Received: from selene.macs.hw.ac.uk ([137.195.27.40]:33371 helo=127.0.0.1) by izanami.macs.hw.ac.uk with smtp (Exim 4.51) id 1IkcrL-0002Bb-OX for emacs-devel@gnu.org; Wed, 24 Oct 2007 10:49:10 +0100 Original-Received: (nullmailer pid 12604 invoked by uid 1001); Wed, 24 Oct 2007 09:49:06 -0000 In-Reply-To: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:81645 Archived-At: Stefan Monnier writes: >> Would someone please fix this, then ack? > > I don't think I can fix it, but I remember discussion of something > similar a few years ago where the conclusion was that it was better > to not apply a property of the overlay (e.g. `face' although I > believe the discussion was about `invisible') to the > (after|before)-string because it's easier to add this property > manually to the relevant string than to "undo" the effect of the > overlay's property from the string. For what it is worth, I agree that it might be better if the face property (and similar properties like invisible) did not affect the before-string and after-string properties. In fact, I think it might be better if the face property also did not affect the display property. However, there is clearly a bug here because before-string is affected by face while after-string is not. Either both should be affected or neither. Also, it is not straightforward to add the face property manually to the relevant string, because the string may already contain face properties. Doing (propertize STRING 'face FACE) will blast any face properties already on STRING. If recursive display properties were allowed, doing (propertize " " 'face FACE display STRING) would do the right thing even if STRING already had face and/or display properties. But recursive display properties are not allowed. And going through the string modifying each face property to add the correct attributes is a real pain. It would make my life much easier if recursive display properties were allowed. It would be enough in practice to allow recursion to some small fixed level, like 10 or so. Joe P.S. By the way, when forwarding messages from bug-gnu-emacs@gnu.org, it would be a big help if the original poster was CC-ed. I'm not on the emacs-devel@gnu.org mailing list, and it is a real pain to have to scan through the web mailing list archives to see if anything is happening with my bug report. Also, it is an additional pain to extract the Message-ID and References headers for the message I am replying to from the web mailing list archives in order to make a proper reply. It would have been much easier (and I would have replied days ago) if I had just been CC-ed. P.P.S. Actually, the issue in the above P.S. would be handled much better by simply using a proper bug tracker for Emacs. Aren't you folks tired of bugs being dropped (in some cases for many years) because of the lack of a bug tracker? >> ------- Start of forwarded message ------- >> From: Joe Wells >> Date: Sun, 21 Oct 2007 04:14:55 +0100 >> Subject: overlay face property not used for after-string property > >> BUG:=C2=A0=C2=A0An overlay's face property is applied to its before-stri= ng >> and display properties, but not to its after-string property. > >> Reproduce with this expression (see below for definition of >> test-in-fresh-buffer-and-window): > >> (test-in-fresh-buffer-and-window >> (insert "123") >> (let ((o (make-overlay 2 3))) >> (overlay-put o 'before-string "B") > >> (overlay-put o 'after-string "A") >> (overlay-put o 'display "D") >> (overlay-put o 'face 'highlight))) > >> This displays =E2=80=9C1BDA3=E2=80=9D. The =E2=80=9CBDA?=E2=80=9D porti= on should be displayed > >> with face =E2=80=9Chighlight=E2=80=9D, which means that the background s= hould be >> colored =E2=80=9Cdarkseagreen2=E2=80=9D. However, only the =E2=80=9CBD= =E2=80=9D portion is >> displayed with face =E2=80=9Chighlight=E2=80=9D and the =E2=80=9CA=E2=80= =9D portion is wrongly >> not displayed with any special face. > >> I'm assuming the following macro definition in my reproduction >> code above: > >> (defmacro test-in-fresh-buffer-and-window (&rest body) >> `(progn >> (delete-other-windows) >> (kill-buffer (get-buffer-create "xyzzy")) >> (let ((xyzzy-buf (get-buffer-create "xyzzy"))) > >> (set-buffer xyzzy-buf) >> (display-buffer xyzzy-buf) >> ,@body >> ))) > >> I hope this bug report is helpful. > >> Joe > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 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.700000= 00 >> configured using `configure '--prefix=3D/home/jbw/local2' '--enable-deb= ug'=20 > >> '--disable-nls' '--with-x-toolkit=3Dgtk' 'CFLAGS=3D-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: >> TeX-source-specials-mode: t >> 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 > >> ------- End of forwarded message -------