emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-pp


From: Stefan Monnier
Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch
Date: Fri, 14 Feb 2014 09:23:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> Just `set-buffer' might be faster, indeed, but mostly because it's
>> written in C (e.g. it also has to iterate through the local variables to
>> save the old value and reload the new value for some of them).
> Not the 100+ of them, though?

It does iterate over the whole list, yes.  It ignores most elements, tho.

>> Hmm... I wonder why mmm-save-local-variables is defined the way it is.
>> It doesn't seem to make use of `buffer-local-variables', even though it's
>> the most natural starting point.  E.g. there shouldn't be a need to list
>> explicitly all the c-* variables.  Maybe the author didn't know about
>> buffer-local-variables (or it didn't exist back then)?
> I'm not quite sure, but this way we only save the variables that are known
> to be safe in the multiple-mode context.

The way I see it, it's rather "this way we can only work for those major
modes we've been taught to handle".

I'm really interested in adding something like mmm-mode (or mumamo or
web-mode) into Emacs.  It'll have to start in GNU ELPA, I think, but in
any case before it can make it into Emacs it will have to be structured
such that new major modes can be handled without having to modify
mmm-mode.

> And also don't touch anything mmm-mode itself introduced.

This is the list that we can trivially know, so it's OK if we have to
handle these specially.

BTW, I really don't know yet what will work best.  Maybe the
"save&restore only those vars we've been told" as is currently done is
indeed the best option.  But in that case it shouldn't be done via
a variable listing those symbols, but e.g. by adding a special
property to those symbols.

> Now that I've checked, parsing the buffer into regions is definitely the
> slowest part (followed by fontification, which takes about 40% of the time
> in the current test example):

Does mmm-mode parse the buffer lazily?
Is fontification done "the jit-lock way"?


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]