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

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Fri, Mar 25, 2016 at 02:11:34AM +0200, Dmitry Gutov wrote:
> On 03/24/2016 08:38 PM, Alan Mackenzie wrote:

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

> It might work well. Without so much as a proof of concept, there's no 
> way to tell, really.

I can't really see a proof of concept happening.  Either the thing is
implemented or it's not.  There's hardly a half way point.

> Submode-local, and chunk-local, variables work fine. But you don't get 
> functioning facilities just by having variables.

No.  But you certainly don't get them without variables.  ;-)

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

> What about
looking-at? Probably.
char-after? No.
syntax-after? No. (This works only on a single char, hence must be in a
              single island, it can't span two.)
forward-char? Maybe.  In fact, there's a good argument for not moving
              forward when `forward-char' hits an island boundary.
goto-char? No.

(All assuming `restrict-to-island' is bound to non-nil.)

> Speaking of the last one, will the buffer positions, as visible to the
> submode code, be renumerated, or will they have gaps?

It would retain the global buffer position, for consistency with the rest
of Emacs.  For example, in narrowed buffers, the position relative to
point-min is never used.

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

> Depending on your answer to the previous question, even simply inserting 
> text inside one of the preceding islands might make syntax-ppss-cache 
> out of date in the current island.

That could probably be solved by making positions in that cache relative
to the beginning of the island, and things like that.  I think you'd want
to make `syntax-propertize--done' island local, too.

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

> Something would have to create and maintain the island identities, as 
> users add and remove text, including island delimiters, it's not like 
> Emacs could do that automagically. My point is, implementing significant 
> part in Elisp is unavoidable anyway.

The job of the super mode would be to maintain the islands, including
creating them, and deleting them when the user deletes text which
characterizes an island.  This would of course be mainly in Lisp, yes.

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

> You didn't answer my question, though. When will the bindings apply?

Sorry, an island local binding would be current when point is within that
island.  Or, perhaps there could be some variable which would be set to a
position to do this job.

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

> Replacing '1' with (point-min) everywhere sounds like a minor change all 
> modes can bear.

> I don't know if we'd need the island-beginnig/island-end accessors in 
> your proposal.

I think we would.  (narrow-to-region (point-min) (point-max)) is a null
operation.  If the major mode has narrowed, and needs to set point-min to
"1", it will need to know the island-beginning, somehow.

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

> I think it's doable using char-property-alias-alist. The multi-mode will 
> define its own property as an alias of `syntax-table', and then put it 
> on and remove it from text at will.

I don't think that would work at the moment.  syntax-table text
properties would take priority over syntax-table-1 properties.  Something
similar to char-property-alias-alist, but giving syntax-table-1 priority,
would need to be implemented.

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

> It sounds somewhat attractive to me, but we should understand more 
> clearly the goals we'll reach with it, as well as the semantics of the 
> new feature.

It would relieve super modes of the tedious necessity to maintain island
local variables using functions in post-command-hook, and things like
that.  It would not be necessary to use widening and narrowing to
restrict indentation/fontification code to an island.

> In order to deliver on the promise of seamless-ness, I think the islands 
> should be able to believe that every one of them starts with position 1, 
> and that they all have no gaps. I.e. every primitive would have to 
> behave that way, at least as long as the relevant global variable is 
> non-nil.

I don't think having islands start at position 1 is a good idea.  But
having the relevant primitives skip the gaps between chained islands, and
stop at an island boundary when not chained, when `restrict-to-island' is
non-nil, would be a central idea.

-- 
Alan Mackenzie (Nuremberg, Germany).