[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
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.
- Re: /srv/bzr/emacs/trunk r101338:*lisp/emacs-lisp/syntax.el(syntax-ppss): More sanity check to catchtch, (continued)
- RE: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Drew Adams, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Eli Zaretskii, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Eli Zaretskii, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch,
Dmitry Gutov <=
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/14
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Dmitry Gutov, 2014/02/15
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Stefan Monnier, 2014/02/16
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Davis Herring, 2014/02/20
- Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch, Andreas Röhler, 2014/02/20