Re: Syntax ambiguities in narrowed buffers and multiple major modes: a proposed solution.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sat, Feb 25, 2017 at 21:32:49 -0500, Stefan Monnier wrote:
> > I don't really see the distinction between users and code here.

> I think the details are very different: in Elisp code, it's typically
> combined with save-restriction, it's short lived, and performance is
> fairly important.  For C-x n n none of those three aspects apply.

Sorry, I've lost the thread, here.  The original point was that there is
currently an ambiguity in narrowed regions - that sometimes the
code/user wants to treat point-min as a syntactically neutral point,
other times it wants beginning of buffer to be that neutral point.

I think you've moved onto talking about something else, without saying
exactly what that something else is.

> > If we implement for one, it will work for the other, won't it?

> It's quite likely that if we can make it ...

"it" has no referent.  What is "it"?

> .... work for Elisp, we can also make it work satisfactorily for C-x n
> n.  But the other way around is not necessarily true, I think.

> >> [ I like to consider that strings and comments are also a form of
> >> "island", although we're probably better off supporting them in
> >> a special way like we do now.  ]

> > I think that's just confusing the meaning of "island", which I'd like to
> > keep clear and unambiguous.  Something to be decided is how we'd handle
> > an island within a comment or string.

> Suit yourself.  I find it to be a good way to think about it.

In that case, we'd need some other term to mean what I'm calling an
"island", i.e. a region of buffer bounded by island open/close
syntax-table text properties, possibly with its own syntax table, which
is syntactically disjoint from the surrounding buffer pieces.

> I don't see why an island within a comment/string should need any
> special treatment.  Just like an island within an island.

It doesn't need special treatment, but it does need to be dealt with
somehow.  Probably by silently skipping over the island.  A bit like how
comments are usually skipped in scan-lists.  But I think you're right,
it's not a big thing.

> >> >   o - narrow-to-region will be given an optional argument which, if set,
> >> >     directs Emacs to make the new region an island.  Thus, C-u C-x n n
> >> >     would enable a user to narrow to a "comment within a string" and edit
> >> >     it as though it were a comment.

> >> How would this work (especially for uses from Elisp)?
> >> Would it set syntax-table text-properties?

> > Yes, it would.  It would put an island open syntax-table property on the
> > character before START, and and island close on the character after END.
> > This would isolate the region syntactically from its surroudings.

> I don't think that's going to be fast enough, then.  I'm thinking of
> cases where current Elisp code does something like

>     (save-restriction
>       (narrow-to-region ...)
>       (with-syntax-table ...
>         (backward-sexp 1)))

> in order to efficiently jump over a small element (e.g. an SGML tag) and
> may very well want to do this within a loop.

Is there any need in that example for the narrow-to-region call to
create an island[*]?  Or, more precisely, _when_ is there any need to
create an island?  If this did need an island and were within a loop,
surely the code could be rearranged for the loop to be inside the
with-syntax-table form.

[*] I'm envisaging narrow-to-region getting an &optional parameter
make-island, if that's not clear.

> This usage doesn't correspond to an island, really and shouldn't cause
> caches to be flushed.

I don't think that code would normally need an island.  But the caches
(in particular, the syntax-ppss cache) are invalid inside the
with-syntax-table form anyway, and in the general case that has to be
dealt with somehow.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).