emacs-devel
[Top][All Lists]
Advanced

[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: Alan Mackenzie
Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:]
Date: Thu, 24 Mar 2016 18:38:35 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Thu, Mar 24, 2016 at 12:34:58AM +0200, Dmitry Gutov wrote:
> On 03/23/2016 11:16 PM, Alan Mackenzie wrote:

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

With islands it should work well, regardless of whether any major mode
widens or narrows.  That's because primitives (such as regexp search)
would constrain themselves to the island.

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

Except you said above that it doesn't work very well.

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

That will require more investigation.  But syntax based searching and
regexp based searching will certainly be amongst them.

> For instance, you said that there could be island-local variables. Can I 
> put some cache into one?

I can't see why not.

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

The island-local variables would stay with the island, so that when
somebody inserts or removes text the right thing would be done.  If
somebody deletes the island, those variables would disappear (just as
buffer local ones do when a buffer is deleted).

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

That's for the application to decide.  The island local binding would
countinue to exist for as long as the island exists, and the application
would be free to use it.

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

It wouldn't use any high level facility like post-command-hook.  The
mechanism would be more like a buffer local variable, entirely handled
by the C level, so that such a binding would simply exist.

> > 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 worried by this.  Already narrowing/widening which is currently
simple, straightforward, and rigorously defined, is looking like
becoming complicated.  Major modes are going to be constrained in what
they can do.  I get the impression that major modes are going to be
restricted in how they can use parse-partial-sexp.  These are serious
matters, but I haven't seen any widespread debate on emacs-devel about
them.

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

What is "(narrow-to-region 1 (point-max))" going to become?  It seems
there will be a need for "the bounds of the island", which will impose
complexities in major mode code.

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

How will this be done when narrowing is the tool used?  It you narrow to
an island, none of the other islands in a chain are visible.  If you
narrow to the smallest region which spans those islands, you leave a lot
of stuff visible which shouldn't be.

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

I don't see why.  There's no reason why islands couldn't be linked to
and unlinked from eachother freely at runtime.

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

Not really.  If you "whitespace" a region out, you've got to remember
the text properties that were there originally, and restore them
afterwards.  There's no easy way to do that.  The comment-fence text
properties won't work either, because, in the general case, there will
already be comment-fence properties in your region which will foul
things up.  I'm worried that the multi-mode projects will suborn these
text properties, making them unavailable for major modes to use.

> But the end benefits might not be high enough to justify the necessary
> work and the increase in complexity in internals.

They might not.  They might.  Basically, nobody else really seams
interested in my idea, so it doesn't look like it will happen.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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