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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 04/05/2016 07:29 PM, Alan Mackenzie wrote:

>> As one option, yes. Let's call it option A, and it entails renumerating
>> buffer positions to avoid gaps.
>
> I'm solidly against using alternative buffer positions.  The unforeseen
> side effects we'd have to cope with would be excessive.  The machinery
> we'd have to set up to convert from "real" offsets to "no gaps" offsets
> would be horrendous.

That's my expectation, too.

> There's no reason forward-char shouldn't jump to
> the next island in a chain without renumbering buffer positions.
> (Assuming `restrict-to-island' has been bound to non-nil by the super
> mode.)

s/shouldn't/couldn't; I'm not sure it should, actually. forward-char 
doesn't normally skip over syntactic whitespace.

> When the key variable `restrict-to-island' is bound to non-nil, things
> like search-forward would skip over islands.  Otherwise it would see the
> insides of islands.  The latter would be what a user doing C-s would
> normally want to happen.

Maybe seeing inside islands is not that terrible. Good code should check 
syntax-ppss anyway, even if it finds a match inside a foreign island.

> parse-partial-sexp would always
> save its state on encountering the start of an island, and restore it at
> the end of the island.

Sure, OK. Or it could just treat the foreign islands as comments, and 
avoid creating a stack of states. Whichever way is easier to implement.

> For the island itself, it would set the state to
> that at the end of the previous island in the chain, or to "nil".

Are you thinking of syntax-ppss instead? The return value of 
parse-partial-sexp must has to depend on where is the start position.

Although if it uses a stack of states internally, it will be easier for 
syntax-ppss to work with (syntax-ppss would be able to reuse cache 
points within islands foreign to the current one).

> I think thinking of it as "changing the value of a variable" is a clumsy
> way to regard it.  "Accessing the correct binding for the current buffer
> position" is more how I would describe it.

Any way we call it now will essentially be a post factum rationalization 
if a programmer is surprised by the behavior. I'm describing the 
behavior. Maybe it's not too bad, IDK.

>>> What sort of variables are you thinking about here?  [ Some time later:]
>>> Could it be that it might be better to have "island chain local"
>>> variables rather than merely "island local" ones?
>
>> mmm-mode has both kinds.
>
> Maybe, but having two extra kinds of locals is more than twice as
> complicated as only having one.

"island chain local" variables are used a lot more often than the 
"island local" ones, in mmm-mode.

> I think "the above concern" was about the lack of newlines in the three
> ruby lines of the example, and the difficulties this would cause
> indentation.  One thing we could do is to make an island syntactically
> equivalent to a newline for the enclosing code.  Maybe.

Yes, it doesn't sounds like a natural solution. Adding a newline in the 
middle of a line might change the meaning of an expression, or at least 
throw off some heuristics we're using in indentation code.

> But we'd surely be happy enough with
>
> <% if foo %>
> <%     = bar(boo) %>
> <% end %>

Not really, no. That's just not how ERB is traditionally formatted. And 
see below (note how the HTML tags, which belong to the superior mode, 
are indented an extra level when inside <% if ... %>...<% end %>).

EJS and JSP are also formatted similarly.

> As a matter of interest, is it really likely that users will type in
> embedded ruby code with <%...%> delimiters around each line, rather than
> one pair around, say, a function or an entire program?

The latter would be an exception. Here's a real-life ERB example:

https://github.com/swanson/stringer/blob/master/app/views/archive.erb

>> - Code complexity: new code paths that might be exercised not very often
>> in the future. Hence, they could be prone to breakage. A dedicated test
>> suite would help with that, though.
>
> If the abstraction we're talking about is sound, then the code complexity
> will be manageable.  People cope with buffer local variables, people cope
> with the regexp engine searching for syntactic things.

Yes, a sound abstraction is key.