GNU bug report logs -
#32504
[PATCH] syntax-is-{comment|string}-p
Previous Next
Reported by: Alex Branham <alex.branham <at> gmail.com>
Date: Wed, 22 Aug 2018 20:20:02 UTC
Severity: wishlist
Tags: fixed, patch
Fixed in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Thu 30 Aug 2018 at 20:21, Noam Postavsky <npostavs <at> gmail.com> 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
This bug report was last modified 5 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.