From: Alan Mackenzie <acm@muc.de>
Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
Subject: Re: Last steps for pretesting (font-lock-extend-region-function)
Date: Tue, 25 Apr 2006 21:49:46 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.3.96.1060425211734.353C-100000@acm.acm> (raw)
In-Reply-To: <jwviroxek19.fsf-monnier+emacs@gnu.org>
Evening, Stefan!
On Tue, 25 Apr 2006, Stefan Monnier wrote:
>> OK. So FACENAME comes back as nil (which presumably means "don't apply a
>> facename property") and the side effect is applying f-l-multiline if the
>> buffer line matches the regexp.
>Right.
>>>> What about the run-time overhead of having an extra text property over
>>>> the entire buffer?
>>> It's not over the entire buffer.
>> Load a buffer and wait for it to be jit-locked. The entire buffer will
>> have been scanned and this text property, in effect, set to t or nil on
>> every single byte.
>Actually the `nil' value is not added, so the property is only added where
>it's non-nil. Hence it's not added to the entire buffer.
Maybe the 'nil' isn't explicitly added, but the entire font-lock region
(or buffer) has to be scanned. Every time a region gets fontified, the
f-l-m properties are erased and every multiline sequence in that region
is recalculated. In the approach I favour, only the bits at the region
boundaries need checking, and then only at the time they are needed.
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.
>>> And I haven't seen any evidence that it's noticeable (especially
>>> compared the number of `face' properties or of the `fontified'
>>> property added to the whole buffer).
>> I'm sure it's not.
>Good.
>> Is it really that important to responsiveness whether the delay
>> happens at the redisplay or immediately after the change? With the
>> after-change f-l-e-r-f, only the two boundaries of the region get
>> checked, plus any chunk boundaries when this is bigger than 500 bytes.
>> With the extra pattern in f-l-keywords, then entire region gets
>> checked.
>But a single command may do thousands of buffer-modifications.
What is a typical number for an "advanced" command?
>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.
>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.
>> 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.
>>> 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.
[ .... ]
> Stefan
--
Alan.
next prev parent reply other threads:[~2006-04-25 21:49 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 [this message]
2006-04-26 4:50 ` Stefan Monnier
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=Pine.LNX.3.96.1060425211734.353C-100000@acm.acm \
--to=acm@muc.de \
--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.