[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Honesty with parse-partial-sexp

From: Stefan Monnier
Subject: Re: Honesty with parse-partial-sexp
Date: Tue, 12 Dec 2006 14:29:44 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]