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 12:08:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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

Right.  In my experience, this doesn't work nearly as well as adding
symbol properties.

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

That's right, it doesn't try to handle major modes generically, but it
does have to solve similar problems, just with the benefit of being able
to custom-make its major modes.

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

The way I see it rather is to start over from scratch, based on the
experience gained with mmm-mode, but with a different view: instead of
trying to make it work without changing existing modes, assume that
the major modes will be changed to fit the framework.

The result should be much simpler/cleaner/shorter.

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

Could be.  (unless (get var 'mmm-foo) may be faster (mostly because the
plist is usually less than 20 elements), if needed.

I tend to assume that mode switches shouldn't be that super frequent to
be a real performance problem, and that if they need to be sped up,
there are ways to do that, e.g. by providing a few "subr", so I'm not
too worried about it.


        Stefan



reply via email to

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