RE: Just a thought about comment-line

[Drew Adams]

> > For block commenting, `comment-dwim' doesn't let
> > you nest and unnest a given level of commenting,
> 
> It automatically decides whether to comment or to uncomment, indeed.

Precisely.  It's a compromise, and not a great
one (IMO).  Better to have two commands, one for
block commenting and the other for end-of-line
commenting.

> > and control the number of comment chars used, etc.
> 
> Hmm... works for me.  At least `C-u 5 M-;` seems to correctly use 5 `#`
> chars to comment the region when used in a Makefile.

Yes.  But it can't provide comment-block nesting,
because it UNcomments any selected lines that are
already commented, instead of adding a level of
commenting for them. 

IMO, `comment-dwim' doesn't provide good behavior
for block commenting because it tries to do too
much conditionally.  I count 10 different behaviors
for it, from the doc string (if, unless, else, else,
if, if, else, else, if, else).

IF what you happen to want, when you hit that one
key (M-;), happens to coincide with what the
designer of that command thought you should want,
THEN it fits, for that occurrence.

It's not just that it has to correctly guess what
you mean.  It's also that _you_ have to guess what
it's guessing you mean. ;-)

(OK, using all combinations of its conditional
behavior often enough might give you finger
familiarity.  In that case, the only problem is
that it doesn't offer some commenting behaviors.)

As for most everything, the strength of a DWIM
command is also its weakness.  It tells you what
you want, instead of making you or letting you
say just what you want.  When it guesses what you
want correctly it can be handy.  But too often
it doesn't really let you say, and thus get, what
you want.

If Elisp, like Common Lisp, had a second comment
syntax for block commenting, i.e., so-called
"balanced" comment macro-char syntax (#|...|#),
then the behavior you'd want for that is pretty
much what command `comment-region-lines' provides.
It's handy for commenting-out and uncommenting
blocks of code, which can involve nested blocks.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html#SECTION002614000000000000000

> >> FWIW I agree with you: a region that ends at the physical start of
> >> line, before indentation, should not be considered to include that
> >> line.
> > FWIW, I too agree about this.
> 
> Right, as a general rule, the LF char belongs to the line that it
> terminates, so a position at BOL is really "between lines".
> Of course, that would require a special case when START=END=BOL.

That special case is what `comment-region-lines'
handles.  It just does this:
(comment-region BOL EOL PREFIX-ARG).