[Top][All Lists]

[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-

From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8670: closed (OT: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment')
Date: Fri, 13 May 2011 17:06:02 +0000

Your message dated Fri, 13 May 2011 14:05:06 -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

8667: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8667
GNU Bug Tracking System
Contact address@hidden with problems
--- 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'

--- End Message ---
--- Begin Message --- Subject: Re: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment' Date: Fri, 13 May 2011 14:05:06 -0300 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Installed a patch along the lines of what you suggested.

>> I think `forward-whitespace' is incorrect: \n should be \n+, like this:
>> (defun forward-whitespace (arg)
>> (interactive "p")
>> (if (natnump arg)
>> (re-search-forward "[ \t]+\\|\n+" nil 'move arg)
>> (while (< arg 0)
>> (if (re-search-backward "[ \t]+\\|\n+" nil 'move)
>> (or (eq (char-after (match-beginning 0)) 10)
>> (skip-chars-backward " \t")))
>> (setq arg (1+ arg)))))

The current behavior is clearly intentional (the (skip-chars-backward "
\t") shows that the function wants to treat newlines as
not-just-whitespace).  So I'd rather not change it.


--- End Message ---

reply via email to

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