[Top][All Lists]

[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: Dmitry Gutov
Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch
Date: Fri, 14 Feb 2014 17:08:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 14.02.2014 16:23, Stefan Monnier wrote:
It does iterate over the whole list, yes.  It ignores most elements, tho.

Hmm. Not looking at the C code, I figured access to buffer-local variables happens through the buffer structure, each time they're looked up or modified. Maybe this way is faster.

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".

Yes and no. An mmm-mode aware package can modify `mmm-save-local-variables', too.

I'm really interested in adding something like mmm-mode (or mumamo or
web-mode) into Emacs.

Last time I checked, web-mode wasn't in this category: it's a major mode with explicit support for some templating languages.

mumamo is an unsupported mess (sorry, Lennart).

mmm-mode would require a hunt for CA signatures, but it's not outside the realm of possibility.

multi-mode would be the most likely option, I believe (it's already copyright-assigned), but it'll either require major changes, or indirect buffers would have to be "fixed", which is not likely, judging by this conversation.

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

I think you mean "can be handled without them being explicitly aware of mmm-mode", because modifying `mmm-save-local-variables' works from outside, too.

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.

I haven't measured it, but wouldn't adding an (unless (memq var (list with 20 elements))) around processing each variable be, like, slow?

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.

A special property would be neater, I guess. But then we'll really have to go though `buffer-local-variables'.

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?

Nope (unlike mumamo and, sorta, multi-mode). I guess it would be the next major feature to implement there.

Originally the parsing was triggered only manually. I added an idle timer, but it's still a kludge.

Is fontification done "the jit-lock way"?

Most of the time yes, but "reparsing" the buffer triggers the full refontification. There are no hard reasons why it can't be fixed, though.

reply via email to

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