Re: Permission requested to merge branch comment-cache into master.

[Stefan Monnier]

> syntax-ppss is simply unsuitable for use in a primitive, and using it
> never entered into my considerations.  It is difficult to understand,
> difficult to maintain high level lisp

Huh?  syntax-ppss is very simple code, and I have no idea where you
could have gotten the idea that it's "difficult to maintain".

> and it calls out to user functions via a hook.  It is crazy and in bad
> taste to make a primitive depend on such a thing.  It is just the
> Wrong Thing to do.

The only case where it calls to user function is via syntax-propertize.
In the case of back_comment this should never happen (because we're
moving backward, so syntax-propertize has already been called on
positions further down and hence isn't needed at this position), but in
case it were to happen it could only be because it's necessary *for
correctness*.

So, again: when my patch to back_comment calls syntax-ppss, it will not
call syntax-propertize-function.  Of course, it still means we call an
Elisp function, which could be adviced and whatnot.  If you want to
rewrite it in C go for it, but I'd oppose it unless you have good
*concrete* reasons for it, rather than vague allegations about it being
"crazy" or "wrong".

> Anything we use in primitives should be robust and rigorous, and as
> far as possible, simple.

Exactly.  But in my book, robust includes "has the needed syntax-table
properties applied".

> Stefan's idea for a solution is to construe the problem as something
> more limited, leave the backward scanning in place, and just make bug
> #22884 go away (until the next bug happens).

Alan, you're a good coder and good thinker.  I know you can make
a much better case against my code than that kind of FUD.

I have acknowledged all the weaknesses you point out (hell, I could give
you a few more if you were more welcoming).  But syntax-ppss was
introduced in Emacs-22.1, i.e. it has close to 9 years of wide use.
So these issues aren't nearly as serious as you make it out to be.
And furthermore, if/when they need to be fixed, they can be probably be
fixed rather easily.

>     char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */
>                       ^
> , narrow it such that point-min is at the marked point.  syntax-ppss
> then sees the following strings, but no comments:

As mentioned, depending on the *reason* behind narrowing, what you say
that syntax-ppss does actually makes perfect sense.  Better yet: that's
also what (forward-comment -1) does in Emacs-24.  And it's not because
of a bug in (forward-comment -1) but because (forward-comment -1) also
decided to start parsing from (point-min) in that particular case.

Now, I'm far from opposed to changing the behavior so as to treat the
last /*   '"'"  */ as a comment in the narrowed region.  I think this
choice doesn't really matter much, except for a few specific
circumstances, where the caller needs to provide more info in order to
clarify which behavior she wants.

[ Of course, syntax-ppss will sometimes do one and sometimes the other,
  depending on the state of its cache.  So, yes, syntax-ppss's behavior in
  this respect is inconsistent.  And noone has reported a single bug about
  it in all those years.
  Should we fix this problem?  Why not!
  Is it urgent?  Imperative?  Worthy of writing a whole new system
  (which fundamentally suffers from the exact same problem just with
  different arbitrary choices)?  Really?  ]

>     " "
>     "; /* "
>     " */ /*  */  /*   '"
>     "  */      ; no closing string quote
>
> (forward-comment -1) from the end of line, using syntax-ppss, thus
> fails.

And as mentioned it also fails in all versions of Emacs released so far.

> In comment-cache, of course, it works without trouble.

Hmm... sure sounds like a backward incompatibility to me.

> What I predict is now going to happen is that a different function,
> based on syntax-ppss, but returning the equivalent of
> (parse-partial-sexp 1 pos) is going to get written.  I also predict that
> it will be given the name syntax-ppss, and the 200 or so calls in our
> code, and an indeterminate number in users' code are going to be left as
> they are to fend for themselves, regardless of the change in
> functionality.

Right, because they are already fending for themselves against
syntax-ppss's inconsistent behavior in the presence of narrowing.

> How about, as a compromise, merging comment-cache into master for now,
> while syntax-ppss gets sorted out, then deciding what to do once that
> has happened?

You make it sound like your solution is rock-solid bullet-proof whereas
syntax-ppss is completely wobbly.  This verges on the ridiculous.
They're both wobbly, by the very nature of their work.


        Stefan