A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:]

[Alan Mackenzie]

Hello, Vitalie.

On Wed, Mar 23, 2016 at 12:58:27PM +0100, Vitalie Spinu wrote:

> >> On Wed, Mar 23 2016 08:16, Andreas Röhler wrote:

> > preventing unwanted widen instead seems the way to go.

> That's precisely what extra limit do. Prevent unwanted widen. How do you 
> propose
> to implement that?

> I see 4 ways to go about it:

>   1) Add an extra prog-widen and teach all modes out there to use it in 
> contexts
>      like syntax-parsing, indentation, font-lock and who know what else. A 
> half
>      backed version of this in already part of emacs.

>   2) Have low level restrictions directly in `widen` and a macro
>      `with-widen-limit` that multi-modes can use. This is the current patch.

>   3) Have two types of narrowing (soft and hard). This is harder to implement
>      but has the benefit that it can be used in non-transient situations like
>      Info mode.

>   4) Bring widen to elisp and allow minor modes (and Info mode) advice widen 
> in
>      whatever way they see.

> I think (1) is a bad idea. (4) is simplest and very general. (3) might be 
> useful
> but it's hard. (2) is implemented to get rid of (1).

> I proposed (4) very early in the thread, but didn't hear much support for
> it. There are only three trivial usages of Fwiden in C code. Bringing `narrow`
> to elisp is equally easy.

All these options strike me as artificial, ad hoc, and ugly.  I would go
for option number (5) - to transcend the "unwanted widen" problem - to
enhance Emacs such that users and Lisp hackers can freely narrow and
widen _without_ upsetting the @dfn{super mode} (the multiple mode
handling mode).

What is a major mode?  It is a collection of local variable settings, a
syntax table, an abbreviation table, a mode specific key map, font lock
mode settings, an indentation engine, Imenu settings, and one or two
other things.

Let us then have all these things in our super mode, such that their
current values are according to where point is - if we have an AWK
script embedded in a shell script, when point is in the AWK bit, the
mode line should say "AWK", the C-c C-? bindings from CC Mode should be
in force, the font locking should be AWK's, etc.

For this we will need a new type of local variable, an "island-local" or
"span-local" variable, or whatever you want to call it.  Values of these
variables will vary according to where point is.

To transcend the "unwanted widen" problem, there will be a very special
variable `restrict-to-island' or `restrict-to-span', or .....  When
bound to non-nil (by the super mode), this instructs certain primitives
to confine their attention to the individual island/span (or possibly a
chain of them).  There will be no restrictions on `widen' or
`parse-partial-sexp', because there won't need to be.
`parse-partial-sexp' would simply skip over "foreign spans" looking for
the delimiter marking the beginning of the interesting span.  Regexp
searching would likewise restrict its attentions, as would several other
facilities.

Although the above vision implies a lot of development work, there is
nothing there which is beyond our abilities to implement readily.  It
would give us a true multi major mode capability, yet the impact on
individual major modes would be minimal.

>   Vitalie

-- 
Alan Mackenzie (Nuremberg, Germany).