[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple major modes
Eric M. Ludlam
Re: Multiple major modes
Wed, 4 Jul 2007 22:29:04 -0400
>>> Richard Stallman <address@hidden> seems to think that:
>Please forgive my delay in studying your message and responding.
> >Currently, the idea is that major modes can make any global variable
> >buffer-local. Are you suggesting we divide all variables into two
> >classes, those that can be and those that can't be? If so, what is
> >the benefit of that?
> There would be two classes.
>I don't entirely follow. Two classes of what? Two classes of variables?
>If so, could you describe each of the two classes?
Sorry for being vague. There would be "buffer-local variables", and
"mode-local variables". I was distinguishing those two from "global
variables". In reading the "Elisp" manual to check my phrases, I see
there are also "frame-local variables", and many other ways to bind
variables, so I am just wrong in saying there are only two classes of
> There would be values that are specific
> to the major mode, and variables that are local to just some buffer.
> The buffer local value would trump the mode-specific value, and any
> mode-specific value would trump the global value.
>That part makes sense to me; but can't we make all kinds of bindings
>possible for every variable?
Correct. When trying to resolve the value of some symbol, mode-local
values would fit into the current scheme of determining the value in
some way, and I am suggesting that buffer local values would be used
before mode-local values.
> The mode-local feature I wrote (with a lot of help from David Ponce)
> works in all versions of Emacs commonly used today. It does this work
> by modifying the buffer-local values for different major-modes. It
> provides the concept of what a mode-local variable might be. Ideally
> it would not operate this way, and instead have built-in support for
> real mode-local values and method tables.
>That makes sense. We could implement mode-local bindings at the low
>level if that is what we want.
>What should their semantics be?
If you have a variable defined:
(defvar my-var nil)
and then set a mode-local value for a mojor mode:
(setq-mode-local 'c-mode my-var t)
;; or declarative
(defvar-mode-local c-mode my-var t "Description about C value")
;; or a constant for that mode, if `defconst' was used instead of `defvar'.
(defconst-mode-local c-mode my-var t "Description here...")
then all buffers in c-mode would get the new value of my-var.
If any of those buffers have a buffer-local version of my-var, then
that value would be used instead. I'm not sure about frame-local
If a c-mode buffer switched to fundamental-mode, then the value of
my-var would go back to nil, (the default value).
> A side effect is that
> you could have minor modes that operate across both major modes in a
> single buffer, and that minor mode won't get tromped.
>How would this work?
A minor mode which works in an HTML buffer with embedded php in it
could use `mode-local-symbol-value' to get the value of some HTML
variable when inside a PHP block for, perhaps, fill-column, or other
variable even though the effective major mode is PHP.
Basically, any code could be written to be aware of the combination of
two modes for a specific case, and have access to both sets of
mode-local variable bindings, regardless of cursor position.
> It is obvious that if a mode-local type tool or syntax were adopted
> into Emacs, that it would be a big effort to transition everything to
>I hope we can design the mechanism to avoid the need for pervasive
>changes in the code of major modes. Perhaps we would need to change
>some of the current calls to make-local-variable to call some new
>primitive, make-mode-variable, instead. But even that would be a pain
>if every major mode HAD to do it.
I think it can be completely optional. Whichever multiple major-mode
tool that is chosen could take advantage of mode-local variables, and
major modes would adopt the use of them because of performance and
If a multi-major-mode tool knows a particular major-mode doesn't use
buffer-local variables, then it would not need to run the major-mode
function (which could call `kill-all-local-variables') for every
section switch and lots of work needed to save and restore
buffer-local values that may or may not be mode-specific would be
I like providing the mode-local values in a declarative way outside of
the mode function. It provides a place to add documentation and talk
about the change. That alone, I think, is worthwhile.
Eric Ludlam: address@hidden, address@hidden
Home: http://www.ludlam.net Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
Re: Multiple major modes, Eric M. Ludlam, 2007/07/04
Re: Multiple major modes, Richard Stallman, 2007/07/01
- Re: Multiple major modes,
Eric M. Ludlam <=