[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-bug-tracker] bug#8670: closed (OT: bug#8667: 24.0.50; `bounds-of-
GNU bug Tracking System
[Emacs-bug-tracker] bug#8670: closed (OT: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment')
Fri, 20 May 2011 02:13:02 +0000
Your message dated Thu, 19 May 2011 23:12:40 -0300
with message-id <address@hidden>
and subject line Re: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N .
N) for `comment'
has caused the GNU bug report #8667,
regarding OT: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for
to be marked as done.
(If you believe you have received this mail in error, please contact
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message ---
OT: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'
Fri, 13 May 2011 07:24:56 -0700
> > (Dunno why some people insist on using `(if (and...)
> > singleton)'. It gets in the way of readability and just
> > represents extra noise. Binary `if' is generally an
> > impediment to readability and communicating intention.)
> Readability is in the eye of the beholder, intention is in
> the mind of the author.
Which is why I said "readability AND communicating intention". And I said
"COMMUNICATING intention", not just "intention". Communicating involves both
the writer and the reader. If the writer's intent is to be communicated well
then readers need to be able to grasp it easily by reading.
> Personally, I think (if (and...) result) communicates the
> intent more clearly than (and ... result)
Really? What's the intent? The result of evaluating
(and A B C D E) is pretty clear: nil or E.
You write that which way? What does adding `if' do for you?
You can add `if' quite a bit, but what does it help?
(and A B C D E)
(if (and A B C D) E) - clearer?
(if (if (and A B C) D) E) - even clearer?
(if (if (if (and A B) C) D) E) - yet clearer?
(if (if (if (if A B) C) D) E) - clearest?
To each his own...
The problem with binary `if' is that it requires more careful parsing, to
distinguish a single sexp from two (2 sexps from 3). It can be pretty easy to
mistake a binary for a ternary `if', or vice versa, depending on the actual
But if you know that a writer systematically uses:
(a) `when' and `unless' to indicate that the result is
unimportant/unused (only side effects matter),
(b) `if' only as ternary, never binary,
(c) `and' and `or' when args are to be eval'd in order
and the result is significant/used
then it is very quick to follow the code's meaning and author's intent. Coming
across a binary `if' in this context then raises a red flag. Of course, when
debugging a section of code that is problematic you must always double-check
that the writer actually respected the convention, but otherwise it's a breeze.
Is this a widespread convention? Yes and no. Many writers of Common Lisp
follow it; some (many?) do not. It helps when you pretty much know that the
writer follows it (e.g. when I read my own code). All bets are off if no
convention is followed wrt these functions.
Personally, I consider use of `if' when the result is not important, and use of
`when' or `unless' when the result matters, to be perverse. The other parts of
the convention are less important/useful, to me.
If you want to super-if-ify the Emacs source code, as above, feel free. Reduce
all uses of `and' to binary `and' if you want, or eliminate use of `and'
--- End Message ---
--- Begin Message ---
Re: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'
Thu, 19 May 2011 23:12:40 -0300
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
> No, I don't think you did. I just downloaded the latest thingatpt.el.
> There is no fix AFAICT.
>From which branch?
> You need to add these conditions to the tests:
> (and beg real-end (<= beg orig) (<= orig real-end)
> (/= beg real-end) ; <===== NEEDED
> (cons beg real-end))
> (and real-beg end (<= real-beg orig) (<= orig end)
> (/= real-beg end) ; <===== NEEDED
> (cons real-beg end))
The code you show here is not on the trunk any more (e.g. I removed the
non-null test of real-beg and end because they were redundant).
--- End Message ---