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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sun, Feb 26, 2017 at 08:47:55 -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.

> Hmm... no, that's exactly what I'm talking about.  I'm pointing out that
> cases where Elisp code uses narrowing is technically quite different
> from cases where `C-x n n` is used.  In both cases, there is an
> ambiguity (i.e. some uses expect syntax to start at point-min others at
> 1).

OK.  Resolving that ambiguity is what my proposal will do.

> >> > 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"?

> The same as your "it", AFAIK (i.e. "it will work" meaning something like
> "we provide a way for the user/code to tell Emacs where syntax starts").

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

> No, as I said, it's just a way to think about the *problem*.  In the
> actual solution/API/implementation we'l probably still want to treat
> strings/comments specially rather than as islands.

I am proposing implementing islands as a solution to the problem, not as
a way of thinking about it.

> >> (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[*]?

> "create"?  As such, no.
> But the issue is that the syntax beginning in the above example should be
> point-min, not 1.

Should it?  Why?  Are you positing this as a possibility, or are you
saying that in this code, the syntax beginning must always definitely
begin at point-min.

When does it actually make a difference, apart from when point-min is
inside a string or a comment?  I don't think it makes a difference in
the (backward-sexp 1) case above.

> AFAICT in your currently suggested solution you have no other way to
> get that behavior than to "create" an island.

That is correct.  The creation of an island will not be an expensive
action, unless it is in a tight loop - recording two current syntactic
elements, and calculating and setting two syntax-table text properties;
then restoring these later.

> BTW, I'm quite willing to tell authors that the above chunk of code
> needs to be rewritten with a new macro, if that can help.

Thanks.

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

> Right.  But I think we need to resolve this "somehow" as part of the
> new "island" design.

Do we?  This is more a problem with syntax-ppss, which needs resolving
regardless of whether or not islands get implemented.

In the case where an island is a permanent feature of a buffer with its
own syntax table, the syntax-ppss cache would not become invalid on
scanning past the island open position.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).