--- Begin Message ---
|
Subject: |
OT: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment' |
|
Date: |
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
argument sexps.
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'
altogether.
--- End Message ---
--- Begin Message ---
|
Subject: |
RE: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment' |
|
Date: |
Sat, 21 May 2011 07:52:58 -0700 |
> > No, I don't think you did. I just downloaded the latest
> > thingatpt.el. There is no fix AFAICT.
>
> From which branch?
>From here:
http://repo.or.cz/w/emacs.git/tree/HEAD:/lisp
In the past that has always given the trunk AFAIK. And in the past it has been
the _only_ HTTP access that has been reliable (works). But apparently it is no
longer kept up-to-date.
I just now tried
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/
and got this, which is typically the case:
Please try again
Sorry, there was a problem connecting to the Launchpad server.
Try reloading this page in a minute or two. If the problem persists,
let us know in the #launchpad IRC channel on Freenode.
Thanks for your patience.
It used to be easy to access Emacs source code via HTTP (back when you used CVS,
IIRC). Now it is difficult, even if occasionally still possible. After
repeatedly trying that second URL, I was finally able to get your fixed file.
The first part of this bug report does seem to be fixed: no empty thing
returned.
The second part is not fixed. `bounds-of-thing-at-point' can still return a
cons when it should return nil. It can easily return a cons that represents a
purely whitespace, non-comment for thing-type `comment'. This in turn means
that `thing-at-point' returns a whitespace, non-comment for thing-type
`comment'.
This is a bug in `thingatpt.el'. It is either a bug in
`bounds-of-thing-at-point', if we expect that general function to DTRT in this
case, or it is a bug in that there is a missing function
`bounds-of-comment-at-point' and consequent (put 'comment
'bounds-of-thing-at-point 'bounds-of-comment-at-point). Or some such fix.
I already gave the recipe to reproduce the bug. I can repeat it if necessary.
`b-o-t-a-p' depends for its generic effect on functions such as `forward-THING'.
Sometimes that is enough to make `b-o-t-a-p' DTRT; sometimes it is not enough.
When it is not, as in this case, other measures need to be taken, such as
defining a THING-specific `bounds-of-THING-at-point' function and putting that
on the THING symbol as property `bounds-of-thing-at-point'.
One way or the other, and there are several alternatives, this needs to be
fixed. It is a bug for `b-o-t-a-p' to return non-nil when there is no comment
at point, and thus for `thing-at-point' to return a non-nil, non-comment value.
--- End Message ---