[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
Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:]
Wed, 6 Apr 2016 01:52:23 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
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
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:
- 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.