Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch

[Dmitry Gutov]

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
> mmm-mode.

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.