From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
Subject: Re: Last steps for pretesting (font-lock-extend-region-function)
Date: Wed, 26 Apr 2006 00:50:03 -0400 [thread overview]
Message-ID: <87ejzlar60.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1060425211734.353C-100000@acm.acm> (Alan Mackenzie's message of "Tue, 25 Apr 2006 21:49:46 +0000 (GMT)")
> This continual erasure and recalculation of f-l-m properties could have a
> serious impact on the speed of C Mode, when that finally acquires a
> suitable region calcualtion function - because this function will
> essentially have to be c-beginning-of-statement-1, with various
> strategies, such as cacheing, to speed it up. Calculating this function
> for _every_ statement within the region would be prohibitively expensive.
Look at my suggested patch for cc-awk and you'll see that you never need to
compute anything extra: you just have to place the font-lock-multiline
property at the moment where you highlight the multiline element (at which
point you already have all the necessary info).
My experience has been that this has always been the case. And it's not
a coincidence.
>> Look at it this way. Let's define things as follows:
>> - a single buffer-modification, without your hook, takes time T1
>> - font-locking, without my font-lock-multiline thingy, takes time T2
>> - your hook takes times N1*T1
>> - my font-lock-multiline takes time N2*T2
>> So your approach can slow down user-visible execution by a fator N1,
>> whereas mine can slow it down by a factor N2. So the important question
>> (to me anyway) is whether N1 is expected to be bigger or smaller than
>> N2.
> Equally important is T1 and T2.
Both T1 and T2 are outside the scope of this discussion, so I'm not sure why
you find them important.
>> Note that in all likelyhood T2 is much larger than T1, so it should be
>> expected that N1 is significantly larger than N2.
> You've given a good argument for keeping both approaches available.
Why? Because you think that in some potential hypothetical case, T2 might
be smaller than T1? In my experience not only is T2 always much larger than
T1, but N2 is also tiny (because it's really nothing more than adding a few
put-text-property calls). So the reverse case sounds hopelessly unlikely
to me. Get back to me when you've found one.
>>> expensive in aggregate - it marks _every_ sequence which must be
>>> atomically fontified, just in case that sequence might straddle a chunk
>>> boundary in the future.
>> No: it's only applied to those atomic elements which do straddle
>> a line boundary.
> My understanding of the form you were suggesting for AWK Mode's
> f-l-keywords, ("^.*\\\\\n" . (progn ......)), was that this regexp would
> be matched against ALL lines in the region, marking all multi-lines,
> in case they might in the future come to straddle chunk boundaries.
Oh yes, that's the case, sorry I misunderstood your use of "chunk" (even
though it was indeed quite clear, my fault). So the only correction I'd
make to your claim is that it's not "_every_ sequence which must be
atomically fontified", but "_every_ multiline sequence which must be
atomically fontified" (that was probably meant implicitly).
>>>> I'm as close as it gets to a font-lock maintainer. So from where I
>>>> stand, you're trying to impose your taste and judgment on me.
>>> I'm as close as it gets to a CC Mode maintainer at the moment. What's
>>> constraining my freedom in that department now? ;-)
>> We're talking about font-lock code here. You're free to do whatever you
>> like in cc-mode, including adding an advice to
>> font-lock-after-change-function.
> Richard has specifically required this advice to be eradicated, on the
> grounds that if such advice is necessary there's some deficiency in the
> underlying functionality, and that deficiency should be fixed.
Yes, and there is no such deficiency, as shown with my sample patch, using
font-lock-multiline.
Stefan
next prev parent reply other threads:[~2006-04-26 4:50 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 0:56 Last steps for pretesting Richard Stallman
2006-04-17 8:01 ` Ramprasad B
2006-04-17 8:37 ` Eli Zaretskii
2006-04-18 1:42 ` Richard Stallman
2006-04-19 3:54 ` Ramprasad B
2006-04-19 15:40 ` Richard Stallman
2006-04-20 5:23 ` Ramprasad B
2006-04-18 17:31 ` Bill Wohler
2006-04-19 17:02 ` Alan Mackenzie
2006-04-19 21:23 ` Stefan Monnier
2006-04-19 21:30 ` David Kastrup
2006-04-20 21:35 ` Stefan Monnier
2006-04-20 21:37 ` David Kastrup
2006-04-20 21:44 ` Stefan Monnier
2006-04-20 21:46 ` David Kastrup
2006-04-20 22:50 ` Alan Mackenzie
2006-04-19 22:43 ` Last steps for pretesting (font-lock-extend-region-function) Alan Mackenzie
2006-04-20 9:13 ` Alan Mackenzie
2006-04-20 17:46 ` Stefan Monnier
2006-04-20 18:12 ` Alan Mackenzie
2006-04-20 20:58 ` Stefan Monnier
2006-04-20 22:40 ` Alan Mackenzie
2006-04-20 23:34 ` Stefan Monnier
2006-04-21 7:58 ` Alan Mackenzie
2006-04-21 12:18 ` Stefan Monnier
2006-04-21 19:51 ` Alan Mackenzie
2006-04-21 22:28 ` Stefan Monnier
2006-04-24 19:28 ` Alan Mackenzie
2006-04-24 21:06 ` Stefan Monnier
2006-04-25 6:21 ` Ralf Angeli
2006-04-25 10:53 ` Alan Mackenzie
2006-04-25 18:37 ` Ralf Angeli
2006-04-25 22:00 ` Alan Mackenzie
2006-04-26 6:14 ` Ralf Angeli
2006-04-25 19:26 ` Stefan Monnier
2006-04-25 20:10 ` font-lock-multiline for cc-awk Stefan Monnier
2006-04-26 7:37 ` Alan Mackenzie
2006-04-26 13:55 ` Stefan Monnier
2006-04-25 19:23 ` Last steps for pretesting (font-lock-extend-region-function) Stefan Monnier
2006-04-25 20:18 ` Stefan Monnier
2006-04-25 11:33 ` Alan Mackenzie
2006-04-25 11:59 ` David Kastrup
2006-04-25 12:33 ` Stefan Monnier
2006-04-25 14:07 ` Alan Mackenzie
2006-04-25 16:05 ` Stefan Monnier
2006-04-25 16:09 ` Stefan Monnier
2006-04-25 21:52 ` Alan Mackenzie
2006-04-25 21:49 ` Alan Mackenzie
2006-04-26 4:50 ` Stefan Monnier [this message]
2006-04-24 21:20 ` Stefan Monnier
2006-04-25 7:45 ` Alan Mackenzie
2006-04-25 12:12 ` Stefan Monnier
2006-04-25 21:15 ` Alan Mackenzie
2006-04-26 4:33 ` Stefan Monnier
2006-04-26 8:30 ` Alan Mackenzie
2006-04-26 13:36 ` Stefan Monnier
2006-04-24 21:33 ` Stefan Monnier
2006-04-25 7:27 ` Alan Mackenzie
2006-04-25 12:03 ` Stefan Monnier
2006-04-25 13:14 ` Alan Mackenzie
2006-04-26 0:22 ` Miles Bader
2006-04-25 4:39 ` Tomas Zerolo
2006-04-25 19:02 ` Ralf Angeli
2006-04-25 19:30 ` Stefan Monnier
2006-04-25 20:12 ` Ralf Angeli
2006-04-25 20:26 ` Stefan Monnier
2006-04-25 20:58 ` Ralf Angeli
2006-04-25 21:11 ` Stefan Monnier
2006-04-25 22:30 ` Alan Mackenzie
2006-04-26 4:25 ` Stefan Monnier
2006-04-26 7:44 ` Alan Mackenzie
2006-04-25 22:16 ` Alan Mackenzie
2006-04-26 4:36 ` Stefan Monnier
2006-04-21 23:14 ` Drew Adams
2006-04-19 22:53 ` Last steps for pretesting (true file names in load-history?) Alan Mackenzie
2006-04-20 1:14 ` Last steps for pretesting Richard Stallman
2006-04-24 17:52 ` Richard Stallman
2006-04-20 10:54 ` Reiner Steib
2006-04-21 0:10 ` Richard Stallman
2006-04-21 5:46 ` David Kastrup
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=87ejzlar60.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/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.