Re[2]: Multiple major modes

["Eric M. Ludlam" <eric@siege-engine.com>]

>>> Richard Stallman <rms@gnu.org> 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
variables.

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

;; programmatic
(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
variables.

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
>    it.
>
>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
usage enhancement.

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


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

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org