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

[Dmitry Gutov]

Hi Alan,

On 03/23/2016 11:16 PM, Alan Mackenzie wrote:

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

I disagree about ugly. Co-opting narrowing to do something useful for 
once is a pretty neat, and minimal, approach.

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

Each multi-mode package implements something like this already. It 
doesn't work well e.g. because font-lock rules of each particular 
language, indentation code, etc, are free to widen.

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

That part is already doable (and done), for most practical purposes.

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

You'll have to present the total list of facilities, decide how the 
islands would be applied, and other issues will likely come up from 
unexpected places.

For instance, you said that there could be island-local variables. Can I 
put some cache into one? Earlier, you suggested that the islands would 
be applied via text properties. What happens to all island-local 
variables when someone, somewhere, changes an island's boundary (maybe 
adds, maybe removes, maybe moves it)? On the one hand, we'd probably 
want to retain some variables, in order not to rerun the major mode 
functions over and over again. On the other hand, if we were to put e.g. 
syntax-ppss-last into an island-local variable (and it's a logical 
continuation of this idea), after island boundaries change it should 
what... become unbound? Nil? Or carefully managed by the mult-mode 
package, which happens already.

Next, at which points exactly would Emacs look at the island boundaries 
and change the island-local variables to the values set in the current 
island? Probably not after each point movement. In post-command-hook? 
That's also already done.

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

I'm sure this is eventually doable. But this proposal looks rather 
similar to what Lennart Borgman has been asking, in multi-mode related 
discussions, on several occasions separated by years. Also in broad 
strokes (probably a bit broader that these). Nobody has been both 
capable and invested enough into the issue of multi-mode buffers to even 
start working on it, AFAIK.

On the other hand, using narrowing for multi-mode purpose is a familiar 
ground already, and the changes in Emacs core required to do so are 
minimal. And most of the code written for Emacs has been taught to 
respect narrowing bounds (even if only by the virtue of always using 
(point-min) instead of 1), so we can utilize that.

Another (probably minor, it's hard to tell now) disadvantage, is if the 
multi-mode package sets narrowing bounds itself, it will decide which 
islands are visible from the current island, dynamically, so to speak. 
Maybe just the current one. Or it can copy just a couple of islands from 
the same mode to a temp buffer, call the indentation function there, and 
use the result. Doing that using an islands framework limits it to a 
predefined set of semantics (e.g. all Ruby islands see all other Ruby 
islands).

That's not to say that being able to make parse-partial-sexp to skip 
over certain intervals wouldn't be valuable. But you can do that, sort 
of, already, by applying existing text properties to those intervals 
(like beginning-of-comment/end-of-comment, or just "whitespace" over the 
whole of it), and then removing them at the end of an operation. But the 
end benefits might not be high enough to justify the necessary work and 
the increase in complexity in internals.