[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:]
Date: Thu, 24 Mar 2016 00:34:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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

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.

reply via email to

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