unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, "Marshall,
	Simon" <simon.marshall@misys.com>, Richard Stallman <rms@gnu.org>,
	emacs-devel@gnu.org
Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]
Date: Mon, 24 Jul 2006 14:33:43 +0100	[thread overview]
Message-ID: <20060724133343.GA1111@muc.de> (raw)
In-Reply-To: <jwvhd17wvhk.fsf-monnier+emacs@gnu.org>

Afternoon, Stefan!

On Sun, Jul 23, 2006 at 11:11:45PM -0400, Stefan Monnier wrote:
> >> 3.  Append a space to the fourth commented line.  Bug:
> >> fontification of Foo, bar, Snafu and snafu is removed from that
> >> line.

> > The problem is that after a textual change, the changed line gets
> > fontified as an atomic entity, i.e. yanked out of its context.  The

> If you placed a font-lock-multiline property on the whole thing,
> font-lock would know not to yank that one line out of its context.

We've already been through this at some length.

I think we're agreed that it's not possible to put this property exactly
where it's needed (at the boundaries of the region to fontify, and
nowhere else) when it's needed (at the time of the change, before Font
Lock starts fontifying).

> > solution is to determine the bounds of the region to fontify by
> > analysing the surrounding text syntactically.

> Presumably, at the moment when Emacs fontified it correctly, it knew
> the corresponding bounds, so it could have added the
> font-lock-multiline property at that time, thus avoiding the need to
> re-determine those bounds later when refontifying.

The buffer was originally fontified as a whole, thus the corresponding
bounds were BOB and EOB.

When the buffer is changed, in the most general case, the bounds of the
region to be refontified are going to have to be recalculated before
fontifying.

As you are aware, I intensely dislike the notion that an entire buffer
should have to be left constantly marked with all places where it
fontification might have to straddle line boundaries, rather than
determining these things as they are needed.  I also dislike being
unable to specify an exact fontification region to Font Lock (such as
the bounds of one of Simon's comments).

>         Stefan

-- 
Alan.

  reply	other threads:[~2006-07-24 13:33 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1G3OAq-0004WV-P1@fencepost.gnu.org>
2006-07-23 14:26 ` [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++] Alan Mackenzie
2006-07-24  3:11   ` Stefan Monnier
2006-07-24 13:33     ` Alan Mackenzie [this message]
2006-07-24 14:36       ` Stefan Monnier
2006-07-24 19:29         ` Alan Mackenzie
2006-07-24 20:43           ` Stefan Monnier
2006-07-24 22:29             ` Alan Mackenzie
2006-07-24 22:30               ` Stefan Monnier
2006-07-24 14:35   ` Stefan Monnier
2006-07-31 22:04     ` Alan Mackenzie
2006-07-31 22:03       ` Stefan Monnier
2006-08-01  9:21         ` Alan Mackenzie
2006-08-01 14:55           ` Stefan Monnier
2006-08-01 19:48             ` Alan Mackenzie
2006-08-01 19:23               ` Stefan Monnier
2006-08-03  8:45                 ` Alan Mackenzie
2006-08-03 15:12                   ` Stefan Monnier
2006-07-31 23:59       ` Richard Stallman
2006-08-01  7:59         ` Alan Mackenzie
2006-08-01  8:32           ` David Kastrup
2006-08-01 20:09           ` Richard Stallman
2006-08-01  8:06         ` Romain Francoise
2006-08-01 20:09           ` Richard Stallman
2006-08-02  9:38         ` Aidan Kehoe
2006-08-02  9:57           ` David Kastrup
2006-08-02 10:28             ` Aidan Kehoe
2006-08-02 11:57               ` David Kastrup
2006-08-02 12:52                 ` Aidan Kehoe
2006-08-02 13:21                   ` David Kastrup
2006-08-02 13:31                     ` Aidan Kehoe
2006-08-02 14:02                       ` David Kastrup
2006-08-02 13:59                 ` Stefan Monnier
2006-08-02 14:12                   ` Aidan Kehoe
2006-08-02 14:14                   ` David Kastrup
2006-08-02 21:20             ` Richard Stallman
2006-08-03  9:17               ` Alan Mackenzie
2006-08-03  8:42                 ` David Kastrup
2006-08-03  8:54                   ` Aidan Kehoe
2006-08-03 19:15                 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060724133343.GA1111@muc.de \
    --to=acm@muc.de \
    --cc=bug-cc-mode@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=rms@gnu.org \
    --cc=simon.marshall@misys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).