[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:]
Mon, 18 Apr 2016 21:32:26 +0000
Sorry this reply has taken so long. I've been preoccupied with things
in real life.
On Wed, Apr 06, 2016 at 01:52:23AM +0300, Dmitry Gutov wrote:
> Hi Alan,
> On 04/05/2016 07:29 PM, Alan Mackenzie wrote:
> > 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.)
I've now renamed `restrict-to-island' to `in-islands', because it's
shorter to write and read, and also with the "s", it's more accurate.
> s/shouldn't/couldn't; I'm not sure it should, actually. forward-char
> doesn't normally skip over syntactic whitespace.
I think I agree with you here. All the searching and skipping commands
will have to be considered. For example, under what circumstances
should skip-syntax-forward skip the gap between two chained islands?
I'm coming round to the idea that both a "foreign" island and a gap in a
chain should be treated as a single unit of whitespace, and should match
"\\s-" - and possibly "[[:space:]]".
> > 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.
I'm thinking of major modes searching for somethingi, rather than users'
> > 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.
No, it can't treat a foreign island as a comment, since its end point
might be inside that island.
[ .... ]
> 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 it must use a stack of states.
> > 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.
Most programmers will be working on major modes, or things like them, so
the bindings will stay the same. I'm hoping there won't be surprises
[ .... ]
> > 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.
I now think this is a tangent to the discussion. Whatever solution is
settled on, it will probably be a part of a particular super mode (? ERB
Mode??) rather than part of the island mechanism. I now don't think
that that newline idea was good.
[ .... ]
> > 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:
Thanks. I've downloaded it.
> >> - 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.
I'm writing a more detailed outline of the island idea. I hope to post
it on emacs-devel in the next day or two.
There are two things I'm currently unhappy about - (i) That buffer local
variables (as they are now) will need to be rigidly classified as either
ones which would be island chain local, or ones which would be entire
buffer variables. This applies particularly to variables defined and
used in the C code; (ii) It's looking like major modes will explicitly
have to bind `in-islands' to non-nil when their commands are executed.
Alan Mackenzie (Nuremberg, Germany).