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

[Stefan Monnier]

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

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

>> (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.  AFAICT in your currently suggested solution you have
no other way to get that behavior than to "create" an island.

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.

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


        Stefan