bug#22983: syntax-ppss returns wrong result.

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> That's pure sophistry.  The semantics needed are quite clear:

For your use case, yes.  It's quite clear *in your mind*.  There are
other use cases.  Worse yet: Elisp doesn't generally know if the
narrowing was setup by the user or by some Elisp caller up the stack.
So even if we were to pretend that the use-case is clear when the
narrowing is set by the user, we'd still have to figure out if that's
the case.

> Lets define them as I said in the previous paragraph.  Or can you
> conceive of a use case where one would want narrowing to invert strings
> and non-strings, leaving comments totally random?

There's the case where some Elisp code does

    (save-restriction
      (narrow-to-region beg end
        (with-syntax-table ...)))

to parse a sub-part of your buffer in a different way.  Of course this
completely breaks syntax-ppss and friends.  I need to do exactly that in
sm-c-mode (when parsing the C code inside CPP directives, since those
directives are marked as comments), for example and had to use

      (let ((syntax-propertize-function nil)
            (syntax-ppss-cache nil)
            (syntax-ppss-last nil))
        ...)

to deal with it.  It would be easy/natural to add a binding of
syntax-ppss-dont-widen in there (and/or literal-cache-dont-widen for
that matter).

> Do you have any views on how the bug should be resolved?

Look up some past discussions of how to number lines in a narrowed
buffer (same basic issue), where we discussed this.

We basically need to add information about which kind of narrowing is
in effect.  IIRC one way suggested was to have 2 narrowing states at the
same time: the current one, plus a new one which is a kind of "hard
narrowing" (the current narrowing would have to be "narrower" than the
"hard narrowing"), with corresponding new kind of "widen".


        Stefan