[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: nxml-mode: Derive from prog-mode instead of text-mode

From: Drew Adams
Subject: RE: nxml-mode: Derive from prog-mode instead of text-mode
Date: Wed, 17 May 2017 09:02:38 -0700 (PDT)

> > it makes no sense to derive from special mode just to get the mundane
> > bindings for `q', `g', and `h' - providing just `quit-window',
> > `revert-buffer', and `describe-mode' hardly makes for a "special" mode.
> Derivation is not only a mechanism to get functionality. It is
> primarily a mechanism to express facts and relationships.
> What makes special-mode special is that ordinary character keys are
> divorced from their usual self-insert meaning, instead, they are all
> available for commands.


What you say "makes special-mode special" has nothing specially
to do with `special-mode'.  It's just `make-sparse-keymap'.

There are "special" modes (which include Dired) and there
is `special-mode' (which probably should have been given a
different name, since "special mode" has another meaning).


Your characterization of "makes special-mode special" is
elegant in the abstract, perhaps.

In reality, to accomplish that we already have a better, more
exact means, and it is what is used in practice:

In the delivered Lisp sources for GNU Emacs 24.5 there are 46
instances of deriving from `special-mode'.  And there are 829
instances of invoking `make-sparse-keymap'.

The fact that `special-mode' is _not_ used as much as your
"what makes special-mode special" would suggest suggests that
removing self-insertion from char keys is _not_ "what makes
special-mode special".

There are 875 (829 + 46) places where a sparse keymap is used.
These are generally modes where "ordinary character keys are
divorced from their usual self-insert meaning".  (Maybe a few
of those involve self-insertion, but probably very few.)

If existing uses of both `special-mode' and `make-sparse-keymap'
are well thought out then cases where "ordinary character keys
are divorced from their usual self-insert meaning" are 19 times
more common than cases where `special-mode' is used.  That's a

But let's allow for some cases that were not well thought out
or that are just old cruft - cases where, if well thought out
today would in fact call for using the `special-mode' keys and
not just a sparse keymap - i.e., not just "ordinary character
keys [being] divorced from their usual self-insert meaning".

How much such potential is there, would you suppose?

Or do you think that every mode that uses a sparse keymap
should instead be derived from `special-mode' and then
override any `special-mode' keys that it doesn't like/need?
I think not.

Modes that want the `special-mode' keys are already derived
from `special-mode'.  Those that don't aren't.  Modulo perhaps
some minor potential for retinkering.

Since not many use cases for a sparse keymap seem to call for
use of `special-mode' (its keys and hook - which is what it
offers), do you think we perhaps need another, more bare-bones,
not-so-special mode that just provides an empty sparse keymap
and a mode hook?  (Fundamental mode provides a hook but no map.)

Should every mode that needs a sparse keymap and doesn't
need/want the `special-mode' keys or doesn't want to be
affected by its hook inherit from such a new, purer mode?
I think not.

`make-sparse-keymap', not `special-mode', is the beast that
corresponds to your "ordinary character keys are divorced
from their usual self-insert meaning".  That divorce is not
"what makes special-mode special".

To come back to the start of this detour from the main thread:
Dired and similar modes already create sparse keymaps.  They
already know enough to use  `make-sparse-keymap'.  They use
your abstraction, without using `special-mode'.

And there is another thing special about `special-mode',
which is also not covered by your "what makes special-mode
special": It is a "special" mode, in the sense described in
(elisp) `Major Mode Conventions' (this property has been
applied to symbol `special-mode').

This kind of specialness is not something new.  It's been
around since Day One, but not as a predefined mode
(`special-mode' was added in Emacs 23).  Here it is:

  If [a] mode is appropriate only for specially-prepared text
  produced by the mode itself (rather than by the user typing
  at the keyboard or by an external file), then the major mode
  command symbol should have a property named ‘mode-class’ with
  value ‘special’, put on as follows:

    (put 'funny-mode 'mode-class 'special)

  This tells Emacs that new buffers created while the current
  buffer is in Funny mode should not be put in Funny mode, even
  though the default value of ‘major-mode’ is ‘nil’.  By default,
  the value of ‘nil’ for ‘major-mode’ means to use the current
  buffer’s major mode when creating new buffers (*note Auto Major
  Mode::), but with such ‘special’ modes, Fundamental mode is
  used instead.  Modes such as Dired, Rmail, and Buffer List use
  this feature.

  The function ‘view-buffer’ does not enable View mode in buffers
  whose mode-class is special, because such modes usually provide
  their own View-like bindings.

  The ‘define-derived-mode’ macro automatically marks the derived
  mode as special if the parent mode is special.  Special mode
  is a convenient parent for such modes to inherit from; *Note
  Basic Major Modes::.

[Note that such "special" modes make use of Fundamental mode,
not `special-mode', for such new buffers.  Note too that the
use of  "Special mode" in the last sentence does not refer to
`special-mode'.  That's unfortunate/confusing, but it is the
fault of naming the new (in Emacs 23) mode `special-mode'.]

Dunno how many of the many uses of `make-sparse-keymap' (most,
if not all, of which correspond to your "what makes special-mode
special") have property `mode-class' = `special'.  Easy enough
to find out, if someone wants to bother.

Dired is one.  It is a "special" mode in the Day One sense
quoted above.  But it is not derived from `special-mode'.
It makes use of `make-sparse-keymap' in its own way, as it

reply via email to

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