Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.

[Alan Mackenzie <acm@muc.de>]

Hello, Emacs.

Bug #22983 is that syntax-ppss is broken.  It's text is this:

    The fundamental contract in syntax-ppss is that (syntax-ppss POS)
    returns the same value as (parse-partial-sexp (point-min) POS) (with the
    exception of elements 2 and 6).  This is currently not always the case.

    In the master branch, emacs -Q and visit xdisp.c with C-x C-f.  Follow
    this recipe:

        M-: (syntax-ppss-flush-cache 1)
        M-: (setq ppss-0 (syntax-ppss 40000))
        M-<
        C-s #include " <CR>
        M->
        C-x n n
        M-: (setq ppss-1 (syntax-ppss 40000))
        M-: (setq parse (parse-partial-sexp (point-min) 40000))

    At this point, `ppss-1' and `parse' should match (apart from elements 2
    and 6).  What we actually have is:

        ppss-1: (2 39992 nil nil nil nil 2 nil nil (39975 39992))
        parse:  (0 nil 15674 34 nil nil 0 nil 15675 nil)

    . 

.  I've just tried it again in the emacs-25 branch, and it is as badly
broken as it was back in March.

Personally, I believe that syntax-ppss is such a bad function, we should
work to expunge it from Emacs.  However, I recognise that that is a view
unlikely to prevail.

My suggestion for a fix, discussed in the thread for the bug, is to come
up with a new function similar to syntax-ppss which always returns the
equivalent of

    (parse-partial-sexp 1 pos)

in place of syntax-ppss's

    (parse-partial-sexp (point-min) pos)

.  Being realistic, this new function would have to bear the name
"syntax-ppss", leaving lots of room for confusion, but it's probably the
best fix we'll get.  I'm willing to make and commit this change.

With this fix, and using this new function in place of the current
syntax-ppss in accordance with its spec, the above bug wouldn't happen.

If my fix isn't wanted, can somebody who likes syntax-ppss PLEASE fix it
before the release, so that, finally, it behaves according to its
specification.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).