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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

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

It's quite likely that if we can make 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.  I don't
see why an island within a comment/string should need any special
treatment.  Just like an island within an island.

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

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


        Stefan