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

[Vitalie Spinu]

>> On Thu, Mar 24 2016 18:38, Alan Mackenzie wrote:

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

> I can't see why not.

Not sure why would you need island local variables but sub-mode local variables
are very meaningful. For instance, polymode gives each submode its own indirect
buffer. So all those critical variables that you mentioned are already sub-mode
local and independent between sub-modes. Polymode never bothers with thing like
syntax-tables, font-lock keywords and most of other buffer local vars.

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

Are islands of same mode connected in any way? If you delete one char of a chunk
head, the island disappears. You type it back and the islands re-appears. Is
this a new island? Or is it the same old one? Are local variables from old
island preserved or not?

This stuff is stuffy. If you are so excited about your general proposal, then
why not give it a try and implement a proof of concept - a new multi-mode
engine?

> What is "(narrow-to-region 1 (point-max))" going to become?  

Out-of-range error. Unless a mode is already smart enough to use (point-min) it
will have to learn that the hard way.

> I'm worried that the multi-mode projects will suborn these
> text properties, making them unavailable for major modes to use.

Not if there will be special "whitespace-begin/end" syntax class designed for
multitudes only. But that work won't be complete without tackling regexp
search. Your idea of "whitespacing" the regexp search might be handy but it's
probably a lot of complex work with long list of problems which no-one has ever
seen before.

For instance a lot of searches are user level and must be on the whole
buffer. So you will need to differentiate between sub-mode search/replace and
user search/replace. Then you need to define the semantics of matching or
replacing on the boundaries. What if a mode wants to replace a regexp that
starts in one chunk and ends in another? More generally, you will need to decide
if the mode is allowed to manipulate regions that start in one of its chunks and
end in another of its chunks. And if so with what semantics. Etc. etc.

Restricting a sub-mode to it's own bubble within a single span is a much simpler
implementation and is quite well understood by now. In so many years no-one came
across with a better idea than widen/narrow. AFAIK this situation is unlikely to
change in the foreseeable future.

  Vitalie