bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#32504: [PATCH] syntax-is-{comment|string}-p


From: Alex Branham
Subject: bug#32504: [PATCH] syntax-is-{comment|string}-p
Date: Thu, 30 Aug 2018 21:50:37 -0500
User-agent: mu4e 1.0; emacs 26.1

On Thu 30 Aug 2018 at 20:21, Noam Postavsky <address@hidden> wrote:

>> I'm not a big fan of the docstrings generated by this, is there a way to
>> change them to be more helpful?
>
> Hmm, doesn't look like it.  Well, that's just a convenient way of
> defining them all quickly for discussion, it wouldn't be that much
> harder to write out defuns I guess.

Fair enough.

> I don't think it should be a -p predicate, because there is meaningful
> distinction between non-nil values:
>
>      4. nil if outside a comment, t if inside a non-nestable comment,
>         else an integer (the current comment nesting).

That makes sense, but the -p predicate seems more discoverable to me. We
can always note in the docstring that the actual return value is usable.
I don't have a super strong opinion though.

>> CL-X defaults to point.
>
> And, my intention is to operate on the return value of syntax-ppss, not
> give a point to call it with.  So it could be used as:
>
>     (syntax-state-comment (syntax-ppss))
>
> or
>
>     (let ((ppss (syntax-ppss)))
>       (and (syntax-state-comment ppss)
>            (syntax-state-comment-or-string-start ppss)))
>
> or
>
>     (syntax-state-comment (parse-partial-sexp ...))

Right, but whenever I want to call on these functions, 90% of the time
the question I'm trying to answer is "Is point in a comment/string?" And
the 3rd party ***-is-comment/string-p functions I've looked at usually
(always?) look at positions.

Thanks,
Alex





reply via email to

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