all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Eric M. Ludlam" <eric@siege-engine.com>
To: rms@gnu.org
Cc: jasonr@gnu.org, lennart.borgman@gmail.com, sdl.web@gmail.com,
	monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re[2]: Multiple major modes
Date: Mon, 25 Jun 2007 10:04:39 -0400	[thread overview]
Message-ID: <200706251404.l5PE4dgc011720@projectile.siege-engine.com> (raw)
In-Reply-To: <E1I2THC-0001hv-Db@fencepost.gnu.org> (message from Richard Stallman on Sun, 24 Jun 2007 10:41:18 -0400)

Hi,

>>> Richard Stallman <rms@gnu.org> seems to think that:
>      Define all your variables with `defvar-mode-local'.
>      If changing a default value, use `setq-mode-local'
>
>Does this mean we would have to go thru all of Emacs and put in
>such definitions for all the variables that major modes can change?

First, I'd like to be clear that I did not concoct the mode-local
program so that I could write a cheap multi-major-mode type program.
For semantic, which is a parser-generator, and has many minor modes,
it allows someone to write mode-specific code and variable values in a
way that is declarative, instead of in a giant hook function.  It
makes it very easy to write a tool (like semantic) that can work in
many major modes, and where the differences between major modes is
very small.

Another advantage is that it allows each mode to add documentation
specific to its needs.

As for adopting it for all modes, I expect it is optional.  It would
replace the big block in most mode functions that create and set
buffer-local values for tools that are not specific to that
major-mode.

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

>Would it make sense for `defvar' itself to do whatever you want
>`defvar-mode-local' to do?

That could simplify things greatly, though I haven't though too hard
on this idea.

>      For a program, use `define-overload' to specify a function that
>      can have a mode specific override.  Supply a default body for modes
>      that accept the default.
>
>Since multiple major modes work (in different buffers) without this
>feature, why would we need to add this feature merely to support
>multiple major modes in one buffer?

The function overload mechanism is also a feature I use in semantic.
Most features that work in multiple major modes today provide a
variable where you can put a symbol that is a function that would then
provide some mode-specific functionality.

My semantic tool has hundreds of these functions, so I abstracted the
concept up so that the implementations could be declarative, instead
of programmatic.  It also makes it easy to make most functions
overridable, which helps avoid forcing users to use advice when
customizing my tool.

As for the multi-major-mode case, if the technique of a variable w/ a
symbol in it is used, then you are correct, this already works.


>      The mode-local system will automatically assign buffer-local values
>      to mode-local defined variables.
>
>I don't understand.  Does this mean that everything defined with
>`defvar-mode-local' gets buffer-local in all buffers?  If so,
>how is that different from `make-variable-buffer-local'?
>
>I guess there must be parts of this explanation that are missing.

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.

In summary, the mode-local tool is useful (to me at least) because it
lets me write more declarative code while setting up values for a
major mode.

For the multi-major-mode case, it would allow a multi-major-mode tool
to operate on predefined lists of variables and it would know the
difference between a variable that is specific to that major mode (and
thus must be swapped in and out) and a variable that is buffer local
for some other reason, such as a minor-mode.  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.

I used this technique for semantic's grammar mode which swaps between
the grammar syntax, and Emacs Lisp which is the grammar
implementation.


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 also don't recommend that David's mode-local implementation be
taken as a sole implementation.  The real advantage would come if the
concepts were built into Emacs and the help system which could then
show chains of values (For C-h v) or chains of function doc (for C-h f)
based on mode.  The readability of my code increased greatly when I
transitioned to a more declarative way of setting up deltas to
different major-modes.  It also made the grammar mode easy to
implement, and that's why I suggest it here.

Thanks
Eric

  reply	other threads:[~2007-06-25 14:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-11 23:27 Should nXML be included Leo
2007-06-12 10:50 ` Lennart Borgman (gmail)
2007-06-12 11:21   ` Jason Rumney
2007-06-12 12:57     ` Lennart Borgman (gmail)
2007-06-12 13:42       ` Peter Heslin
2007-06-12 14:20       ` Jason Rumney
2007-06-12 15:06         ` Multiple major modes (was: Should nXML be included) Stefan Monnier
2007-06-12 15:15           ` Multiple major modes Leo
2007-06-12 18:48           ` Lennart Borgman (gmail)
2007-06-12 20:14             ` Re[2]: " Eric M. Ludlam
2007-06-12 21:04               ` Lennart Borgman (gmail)
2007-06-12 23:10                 ` Stefan Monnier
2007-06-13 16:22                   ` Richard Stallman
2007-06-13 16:22               ` Richard Stallman
2007-06-19  2:09                 ` Re[2]: " Eric M. Ludlam
2007-06-24 14:41                   ` Richard Stallman
2007-06-25 14:04                     ` Eric M. Ludlam [this message]
2007-07-01 20:40                       ` Richard Stallman
2007-07-05  2:29                         ` Re[2]: " Eric M. Ludlam
2007-07-05 20:34                           ` Richard Stallman
2007-07-01 20:40                       ` Richard Stallman
2007-07-04 16:35                         ` T. V. Raman
2007-07-04 17:01                           ` David Kastrup
2007-07-05  1:31                           ` Richard Stallman
2007-07-05 14:49                             ` Stefan Monnier
2007-07-06  4:38                               ` Richard Stallman
2007-07-06  6:01                                 ` Stephen J. Turnbull
2007-07-07 13:07                                   ` Richard Stallman
2007-07-07 14:13                                     ` Lennart Borgman (gmail)
2007-07-08 16:56                                       ` Richard Stallman
2007-09-04  9:03                                         ` Highlight advice (was: Multiple major modes) Johan Bockgård
2007-07-07 17:43                                     ` Multiple major modes Stephen J. Turnbull
2007-07-06 16:00                                 ` Stefan Monnier
2007-07-06 16:10                                   ` Drew Adams
2007-07-07 13:06                                     ` Richard Stallman
2007-07-07 17:21                                       ` Stephen J. Turnbull
2007-07-08 16:55                                         ` Richard Stallman
2007-07-09  5:29                                           ` Stephen J. Turnbull
2007-07-09 17:21                                             ` Richard Stallman
2007-07-07  0:48                             ` Johan Bockgård
2007-07-05  1:44                         ` Re[2]: " Eric M. Ludlam
2007-07-08 22:23                           ` Richard Stallman
2007-07-09  0:49                             ` Re[2]: " Eric M. Ludlam
2007-07-09 17:21                               ` Richard Stallman
2007-06-12 13:26   ` Should nXML be included Stefan Monnier
2007-06-12 13:16 ` Peter Heslin
2007-06-12 13:11   ` Leo
2007-06-12 13:59     ` joakim
2007-06-12 14:17       ` Peter Heslin
2007-06-12 14:14         ` David Kastrup
2007-06-12 15:11           ` Stefan Monnier
2007-06-13  8:06           ` Richard Stallman
2007-06-13 17:45             ` Claus
2007-06-14 16:19               ` Richard Stallman
2007-06-14 16:28                 ` Leo
2007-06-15 19:21                   ` Richard Stallman
2007-06-14 17:44                 ` Eric Hanchrow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706251404.l5PE4dgc011720@projectile.siege-engine.com \
    --to=eric@siege-engine.com \
    --cc=emacs-devel@gnu.org \
    --cc=jasonr@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=sdl.web@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.