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: Thu, 13 Feb 2014 11:42:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> Indeed, I don't think using an indirect buffer is a good solution.
>> I'm not even sure it's faster than mmm's "manual" variable switch.
> Why not? `switch-buffer' has to be faster than "iterate these lists, save
> values of symbols, set them to values from those alists".

Of course, if the code uses switch-to-buffer, then it gets much slower
because of the redisplays.

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

But then you have to add things like the need to handle variables that
are buffer-local but should be shared among the indirect buffers, and
I doubt the end result will be faster.  Plus handle all the bugs that
indirect buffers introduce (e.g. a modification in one of the indirect
buffers only runs its own after-change-functions, not the one of the
base buffer or any of the other indirect buffers; overlays added by
a major/minor mode in its indirect buffer won't affect the display of
the base buffer; ...).

> Or do you mean that indirect buffers add their own overhead, just by having
> (and somehow coordinating, I guess) the same contents?

I wasn't thinking of that, no, although it is true that the presence of
an indirect buffer can slow down some operations.

>> But making it do really less work is difficult: there's the
>> "local-variables" alist in the "struct buffer" which we could switch in
>> one step, but:
>> - it doesn't account for all local variables (doesn't account for those
>> local-vars held directly in the "struct buffer" such as tab-width).
>> - it would switch some vars which should not be switched.
> This, together with a blacklist and a small "additional variables" list
> would still probably be a lot neater than mmm-vars.el:

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)?

IOW I'd expect to start with a loop through the output of
(buffer-local-variables), skipping the permanent-local vars.  Then add
special cases (e.g. current-local-map, syntax-table which aren't
variables or syntax-ppss-cache which should probably be treated like
a permanent-local).

Of course, maybe it wouldn't be faster: (buffer-local-variables) returns
a fairly long list (like 100 more than elements), and at every
mode-switch we'd have to go through 2 such lists (the "from" and the
"to").  If we can make this clean enough, we could implement it in C,
which might speed it up significantly.


        Stefan



reply via email to

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