From: Stefan Monnier <monnier@iro.umontreal.ca>
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 16:43:14 -0400 [thread overview]
Message-ID: <jwvejwapxds.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20060724192940.GC1111@muc.de> (Alan Mackenzie's message of "Mon, 24 Jul 2006 20:29:40 +0100")
> Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> Reply-To: Alan Mackenzie <acm@muc.de>
> To: emacs-devel@gnu.org
> Subject: font-lock-extend-region-function: Final refinements.
> It hasn't as yet been installed, although it would establish the
> infrastructure with which the problems being discussed here could be
> wholly and efficiently erradicated, without resort to obscure coding.
Richard put it on the backburner, claiming he hasn't seen the other thread
where you presented your point of view and then I presented mine. We need
to start it over, but I've had other horses to flog.
> I know what your paragraph refers to. We've discussed it at great
> length already, and I think I understood it at the time you posted it.
> That approach is more obscure and more inefficient (in terms of
> processor cycles) than anything I want to put into CC Mode.
You haven't shown any evidence of inefficiency.
> Is there any chance of you adapting the font-lock-multiline mechanism so
> that the properties can be applied _before_ fontification, exactly where
> they are needed, rather than _after_ fontification throughout the entire
> change region?
That's the thing on the backburner. But it's still unrelated to the OP's
problem which was specifically about *re*fontification, where the
current font-lock-multiline support is all you need (and if you don't like
it, there are already several existing alternatives, see the lispref
manual).
I.e. you need both to be able to extend the region just-before fontification
(to do the initial discovery of multi-line elements) and to re-extend the
region based on info kept from the last fontification (to properly
refontify such elements).
>> > I also dislike being unable to specify an exact fontification region
>> > to Font Lock (such as the bounds of one of Simon's comments).
>> I don't understand what you're referring to.
>> From Simon's example:
> public Bar // Bar fontified as a type, at first
> type a space after "first". The region I want to specify to Font Lock
> is exactly this:
> public Bar // Bar fontified as a type, at first
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oh, I see. It seems very minor. Why do you care? Is the performance
difference ever noticeable? If yes, how often?
> Most of CC Mode's languages are not line-based.
Same as 99% of the languages supported by Emacs.
> I think it's unhelpful to construe it's font-locking stuff in terms of
> buffer lines. This is what has led to many complaints about font locking
> in CC Mode (many of which have appeared directly in bug-cc-mode). If CC
> Mode can specify a font-locking region based on language constructs
> (e.g. a whole statement, a comment, a string, a declaration), these
> problems will go away.
Thanks to CPP and other preprocessors, there will always be cases you
can't handle.
> Even entries to the obfuscated C competition would
> get correctly and efficiently fontified.
I don't see why we should waste our time trying to handle that correctly.
Stefan
next prev parent reply other threads:[~2006-07-24 20:43 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
2006-07-24 14:36 ` Stefan Monnier
2006-07-24 19:29 ` Alan Mackenzie
2006-07-24 20:43 ` Stefan Monnier [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvejwapxds.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.