[pro] #; comments...
Janis Dzerins
jonis at latnet.lv
Tue May 15 09:10:08 UTC 2012
On 13 May 2012 19:47, Pascal Costanza <pc at p-cos.net> wrote:
>
> On 8 May 2012, at 20:02, Alessio Stalla wrote:
>
>> On topic: the proposed syntactic addition is nice, but imho too
>> trivial and too easily provided as a library to bother with a CDR
>> (that would need to be included in each implementation).
>
>
> Interesting discussion so far.
I'm sorry I'm contributing to this boring discussion. But I think it is
turning from boring into entertaining.
> I can perfectly understand those who voiced their opinion that the
> existing mechanisms for commenting out s-expressions are good
> enough. (I especially liked the #+| here is a bug | variant that puts
> a comment in the feature expression.)
>
> However, the suggestion that #; could just be put in a library is not
> a valid counter argument. The main reason for adding #; to a
> specification (and thus suggesting it as a quasi-standard for the
> language) is that it should be straightforward and simple to use
> it.
That's exactly the reason why it should not be added to the
specification since it already provides means of addressing the issue.
> Adding #; in any way makes only sense if it can be used in a
> considerably faster way than any other of the existing options.
I already use a single key (M-; - paredit-comment-dwim) key for my
commenting needs. If I was commenting out single expressions frequently
enough, I'd probably assign it to a key, too (probably C-M-; - which
would be consistent with other key bindings that act on expressions).
Therefore I do not see how using #; as instead of #-(and) or #+(or)
would be "considerably faster", since I expect the editor to insert all
of them with the same percievable speed.
> If I want to comment out an s-expression, I probably want to do this
> during development because I quickly want to try out a variant of my
> code. I don't want to be interrupted in my flow of thinking about the
> problem at hand when doing so.
Yes, the keyboard shortcuts have a tendency to get into the subconscious
so we don't think about them at all.
> That's the very reason why I never use the #+(and) and #-(or) options,
> because they require me to think at least for a few seconds which way
> the operators go, and that disrupts what I'm actually interested in
> [1].
As I already noted, I personally use #-(and) when I do need/want to
comment out a [lengthy] expression. And I will teach you a trick I have
learned from other great minds that will allow you to deal with this
little inconvenience. It takes two steps:
1. Try to associate the "minus" sign with removing something, and
"plus" sign with adding something.
2. Forget about (or), and use only (and).
You're done. Now, if you want to remove an expression, you use #-(and)
(notice the minus sign!). If you want to have it back [temporarily],
you change that to #+(and) (see, the minus has been changed into plus!).
Also, if the association in step 1 somehow contradicts your experience,
and is the other way around, all you have to do is forget about (and)
and use (or) instead.
In any case, this is a one time investment, and you think about it only
once, and then use for the rest of your life. I accept your advance
gratitude on all the hours you will save not thinking about this issue
in your future programming endeavours. You are welcome!
> Likewise, I think, with the other options. I already find that
> placing a pair of #| |# around the s-expression in question takes far
> too much time than necessary.
Yes, using this facility also is troublesome for different reason: in my
experience it has confused the editor on too many occasions that I have
completely stopped using it. Not that I miss it since I learned of M-;
(usually used in together with expression selection commands).
> [1] They are intentionally chosen wrong in this sentence, and if you
> missed that, it proves my point.
Now that I have revealed my secret trick, you yourself can see that your
point is not only not proven, but the very existence of it is in
question.
--
Jānis
More information about the pro
mailing list