Re: Honesty with parse-partial-sexp

[Stefan Monnier]

> I don't think a special case should be made for point already being at
> top level:  It's surely more consistent just to return (point) in this
> case.  To return nil would make callers of the function have to take
> evasive action, such as:

>    (let ((base-pos (or (syntax-ppss-toplevel-pos ppss)
>                        (point))))

> instead of the more natural

>    (let ((base-pos (syntax-ppss-toplevel-pos ppss)))

But there can be other uses.  E.g. testing "toplevel-p" becomes just
(null (syntax-ppss-toplevel-pos (syntax-ppss))) rather than having to check
equality with (point).

More to the point, all places in syntax.el where I'd want to use this new
function currently use
                       
   (or (car (nth 9 ppss))
       (nth 8 ppss)
       (nth 2 ppss))

So with your function I'd end up having to do:

  (let ((pos (syntax-ppss-toplevel-pos ppss)))
    (if (eq pos (point)) (nth 2 ppss) pos))

Nothin terrible, of course, but it seems that it's marginally easier to add
(or ... (point)) than to detect the special case where the value returned in
(point).

There's a tension between making this function just an accessor to the raw
data, and making it a solution to a particular problem.

I was actually expecting someone to complain that she wants the raw
(car (nth 9 ppss)) data for her particular application.

> (or (car (nth 9 ppss))
>     (nth 8 ppss)
>     (point)))

Of course, the other problem with this code is that there's no guarantee
that (point) is the position of the end of the scan (we may even have
switched to some other buffer in the mean time).


        Stefan