Just a thought about comment-line

Just a thought about comment-line

[PEDRO ANDRES ARANDA GUTIERREZ]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

Hi,

Take any file, code or not, but let's say it is code...
Now select two or more lines. The mark should be at the beginning of a line
and the point at the beginning of a line two or more lines further down. If
you copy this region and paste it somewhere else you get what you want.

However let's suppose that your theme is highlighting the region and you
comment the region with M-x comment-line. You will have the line at the
point:
1.- not highlighted before M-x comment-line
2.- commented after M-x comment-line

This is something you get used after n-ty something years of use. However,
it is confusing the "newer generation" because it doesn't happen on other
"popular" editors. Could we consider a variable customise the behaviour and
allow the last line *not*  to be commented when the mark is at the start of
line?

Just a random thought after talking to novice users,
-- 
---
PEDRO ANDRES ARANDA GUTIERREZ
Universidad Carlos III de Madrid

"Fragen sind nicht da um beantwortet zu werden.
Fragen sind da, um gestellt zu werden" Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

Re: Just a thought about comment-line

[Yuri Khan]

On Sun, 31 May 2020 at 14:40, PEDRO ANDRES ARANDA GUTIERREZ <paranda@it.uc3m.es>

> Take any file, code or not, but let's say it is code...
> Now select two or more lines. The mark should be at the beginning of a line
> and the point at the beginning of a line two or more lines further down. If you copy this region and paste it somewhere else you get what you want.
>
> However let's suppose that your theme is highlighting the region and you comment the region with M-x comment-line. You will have the line at the point:
> 1.- not highlighted before M-x comment-line
> 2.- commented after M-x comment-line

Since you are selecting whole lines to be commented, you might find
comment-dwim (M-;) more to your liking. (If you select partial lines,
it may also split them if the current mode only has end-of-line
comments.)

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.

Re: Just a thought about comment-line

[Eli Zaretskii]

> From: PEDRO ANDRES ARANDA GUTIERREZ <paranda@it.uc3m.es>
> Date: Sun, 31 May 2020 09:39:37 +0200
> 
> Take any file, code or not, but let's say it is code...
> Now select two or more lines. The mark should be at the beginning of a line
> and the point at the beginning of a line two or more lines further down. If you copy this region and paste it
> somewhere else you get what you want.
> 
> However let's suppose that your theme is highlighting the region and you comment the region with M-x
> comment-line. You will have the line at the point:
> 1.- not highlighted before M-x comment-line
> 2.- commented after M-x comment-line

I'm probably misunderstanding something in the recipe, because if I
repeat it, I don't see what you describe.  I only see the lines
commented out which were highlighted before "M-x comment-line".

RE: Just a thought about comment-line

[Drew Adams]

> you comment the region with M-x comment-line.
> You will have the line at the point:
> 1.- not highlighted before M-x comment-line
> 2.- commented after M-x comment-line
>
> ...it doesn't happen on other "popular" editors.
> Could we consider a variable customise the behaviour
> and allow the last line not to be commented when the
> mark is at the start of line?

Yes, you can.  (And yes, Emacs should offer this
behavior out of the box, IMO.)

I use this command (I bind it to `C-x C-;).  It's
from library `misc-cmds.el'.

(defun comment-region-lines (beg end &optional arg)
  "Like `comment-region' (which see), but comment or uncomment whole lines."
  (interactive "*r\nP")
  (when (> beg end)
    (setq beg  (prog1 end (setq end  beg))))
  (let ((bol  (save-excursion
                (goto-char beg)
                (line-beginning-position)))
        (eol  (save-excursion
                (goto-char end)
                (if (bolp)
                    (point)
                  (line-end-position)))))
    (comment-region bol eol arg)))

https://www.emacswiki.org/emacs/download/misc-cmds.el

RE: Just a thought about comment-line

[Drew Adams]

> Since you are selecting whole lines to be commented, you might find
> comment-dwim (M-;) more to your liking. (If you select partial lines,
> it may also split them if the current mode only has end-of-line
> comments.)

IMO, `comment-dwim' is an inferior command.
It's OK for end-of-line commenting, and I use it
(only) for that.

(And the command that `M-;' was bound to by
default before `comment-dwim' was just as good for
end-of-line commenting.)

For block commenting, `comment-dwim' doesn't let
you nest and unnest a given level of commenting,
and control the number of comment chars used, etc.

For block commenting, `comment-region' is much
better.  And better still, I think, is the command
I posted a few minutes ago, `comment-region-lines'.

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

Re: Just a thought about comment-line

[Stefan Monnier]

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

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

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


        Stefan

Re: Just a thought about comment-line

[Dmitry Gutov]

On 31.05.2020 19:58, Drew Adams wrote:
> For block commenting, `comment-dwim' doesn't let
> you nest and unnest a given level of commenting,
> and control the number of comment chars used, etc.

If your job is writing code (and not, say, comment accounting and 
management), I'm fairly sure the functionality provided there is well 
sufficient.

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).

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,
> > and control the number of comment chars used, etc.
> 
> If your job is writing code (and not, say, comment accounting and
> management), I'm fairly sure the functionality provided there is well
> sufficient.

You're fairly sure for whom?  For you?  Not for me.

Tell me why Common Lisp behavior for block comments
(#|...|#) is missing?  I don't mean that those macro
chars are missing, but that the block-commenting
behavior (nesting, unnesting) is missing.

Re: Just a thought about comment-line

[Dmitry Gutov]

On 31.05.2020 21:08, Drew Adams wrote:
> You're fairly sure for whom?  For you?  Not for me.

The only complaints against comment-dwim I have seen were along the 
lines "I want to micromanage how comments are made", and not "this 
code-writing scenario becomes suboptimal".

Are you still writing code? I'm surprised, not having seen any patches 
from you in a long while.

> Tell me why Common Lisp behavior for block comments
> (#|...|#) is missing?  I don't mean that those macro
> chars are missing, but that the block-commenting
> behavior (nesting, unnesting) is missing.

You might want to elaborate.

It definitely can create nested comments (i.e. in the cases they are 
really needed, when you call it on a region containing both commented 
and non-commented lines).

Re: Just a thought about comment-line

[Stefan Monnier]

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

I have never seen someone comment a comment.  Do you have a use case for it?

> 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. ;-)

That in nature of DWIM commands, yes.

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

At the detriment of the other case.

> It just does this:
> (comment-region BOL EOL PREFIX-ARG).

But that's what the OP complained about when you do

    C-a C-SPC
    C-n C-n M-x comment-region-lines RET

where it ends up commenting 3 lines, even though there are only 2 lines
enclosed in the region.


        Stefan

RE: Just a thought about comment-line

[Drew Adams]

> >> 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.
> 
> I have never seen someone comment a comment.
> Do you have a use case for it?

Commenting out some code, perhaps temporarily.

Doing so regardless of whether some, or all, of
it is already commented out.  And maybe doing
so again, with a larger scope.  And then maybe
uncommenting the outermost commenting level.
And so on.

But let me be clear that I'm expressing, first
of all, my personal preference.  I don't say
that everyone has to, will, or should prefer it.

That said, I do think that Emacs itself should
provide such behavior, e.g. some such command,
out of the box.  Whether it gets a default
binding, or the default binding, is a different
story.  (In fact, it has one, `comment-line',
but it suffers from the problem raised in this
thread.)

There have been previous discussions here about
the question.[1]  And although I said the same
then as now, it was others who raised the
question in the first place.  And other
suggestions given were along the same lines as
what I offered.

The result of the last such discussion was the
addition of command `comment-line' - again, to
comment whole lines.  It, however, suffers from
the behavior complained about in this thread:
it comments an extra line when the region ends
at bol.

Finally, if you think there's no use case for
such comment nesting ("comment a comment", as
you say), then maybe you can explain why Common
Lisp was so foolish as to provide for such a
non-use case - with a specific, separate
comment syntax, no less.

The use case is described this way by CLTL2
(I already gave the URL):

  The main purpose of this construct is to allow
  "commenting out" of blocks of code or data.
  The balancing rule allows such blocks to contain
  pieces already so commented out. In this respect
  the #|...|# syntax of Common Lisp differs from
  the /*...*/ comment syntax used by PL/I and C.

`comment-dwim' gets you partway there.

> > 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. ;-)
> 
> That in nature of DWIM commands, yes.

That's a general problem with DWIM, commands, yes.

But this one, with 10 different behaviors, for 10
different conditional situations, suffers from it
in spades.  (IMHO.)

Since I use `M-;' only for end-of-line comments
I don't suffer from its congeries of behaviors.
And if others are fine with the trade-offs it
makes, that's fine too.  I haven't suggested
changing or removing `comment-dwim' - it doesn't
bother me, the way I use it.

> >> 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.
> 
> At the detriment of the other case.

How so?  In what "other case" does it fall down?

I don't claim it always does what every Mr. WXYZ
wants.  I say that its behavior is straightforward
and useful, and it's easy to know what behavior
you'll get.

And I don't argue that Emacs should adopt the
exact same code.  `comment-line' could be fixed,
for example, so that it doesn't suffer from the
problem raised in this thread.

And there are a couple other improvements that
could be made to `comment-line' at the same time,
which I suggested when it was added, 5 years ago.[2]

> > It just does this:
> > (comment-region BOL EOL PREFIX-ARG).
> 
> But that's what the OP complained about when you do
> 
>     C-a C-SPC
>     C-n C-n M-x comment-region-lines RET
> 
> where it ends up commenting 3 lines, even though
> there are only 2 lines enclosed in the region.

No, it does not.  With that recipe it comments only
the two lines enclosed in the region.  Full code:

(defun comment-region-lines (beg end &optional arg)
  (interactive "*r\nP")
  (when (> beg end)
    (setq beg  (prog1 end (setq end  beg))))
  (let ((bol  (save-excursion
                (goto-char beg)
                (line-beginning-position)))
        (eol  (save-excursion
                (goto-char end)
                (if (bolp)
                    (point)
                  (line-end-position)))))
    (comment-region bol eol arg)))
____

[1] https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00900.html

[2] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00491.html

RE: Just a thought about comment-line

[Drew Adams]

> > You're fairly sure for whom?  For you?  Not for me.
> 
> The only complaints against comment-dwim I have seen

I wasn't complaining about `comment-dwim'.
I was saying that it's not the be-all and
end-all.  I use it for end-of-line comments.
And I use something else for block commenting.

It doesn't matter to me if you use `M-;' for
everything.  If you're happy that way, great.

> were along the lines "I want to micromanage
> how comments are made", 

I see.  If someone says your one-size-fits-all
dream command doesn't fit all then their idea
for doing something additional or different
just wastes your time.  Sorry to hear that.

> and not "this code-writing scenario becomes
> suboptimal".
> 
> Are you still writing code? I'm surprised,

Surprise!  And irrelevant.

> > Tell me why Common Lisp behavior for block comments
> > (#|...|#) is missing?  I don't mean that those macro
> > chars are missing, but that the block-commenting
> > behavior (nesting, unnesting) is missing.
> 
> You might want to elaborate.

I think I did.  Maybe you can show us how
`comment-dwim' provides the same behavior.

> It definitely can create nested comments (i.e. in
> the cases they are really needed, when you call it
> on a region containing both commented and
> non-commented lines).

A bit of a tautology.  I can leap over buildings
in a single bound, in the cases where that's
really needed, which is when the buildings are
at most 1-foot tall.

Anyway.  The point of this thread is the problem
with `comment-line' raised by the OP.  If you're
curious why `comment-line' was added, since we
already had `comment-dwim', see the thread I
pointed to, where `comment-line' was discussed
and added.

Re: Just a thought about comment-line

[PEDRO ANDRES ARANDA GUTIERREZ]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

Hey,

thanks for all the answers so far. It's nice to see people getting
passionate about this.
I too had my code to deal with (bol-p end-of-region) and I'm passing it on
to people,
but I started writing a short introduction for students who get interested
in Emacs by
seeing how I use it and well, it'd be so much better for Emacs if I could
get one of the
FAQ answered by something like 'customise variable so-and-so to get your
desired
behaviour' instead of 'include <listing 100> in your .emacs.d/functions.el
and bind function
sensible-comment-lines to M-;'

I hope the discussion crystallises in some better future :-)

Best, /PA
PS: and as my signature translates ;-) "questions exist to be made, not to
be answered"

El dom., 31 may. 2020 a las 23:54, Drew Adams (<drew.adams@oracle.com>)
escribió:

> > > You're fairly sure for whom?  For you?  Not for me.
> >
> > The only complaints against comment-dwim I have seen
>
> I wasn't complaining about `comment-dwim'.
> I was saying that it's not the be-all and
> end-all.  I use it for end-of-line comments.
> And I use something else for block commenting.
>
> It doesn't matter to me if you use `M-;' for
> everything.  If you're happy that way, great.
>
> > were along the lines "I want to micromanage
> > how comments are made",
>
> I see.  If someone says your one-size-fits-all
> dream command doesn't fit all then their idea
> for doing something additional or different
> just wastes your time.  Sorry to hear that.
>
> > and not "this code-writing scenario becomes
> > suboptimal".
> >
> > Are you still writing code? I'm surprised,
>
> Surprise!  And irrelevant.
>
> > > Tell me why Common Lisp behavior for block comments
> > > (#|...|#) is missing?  I don't mean that those macro
> > > chars are missing, but that the block-commenting
> > > behavior (nesting, unnesting) is missing.
> >
> > You might want to elaborate.
>
> I think I did.  Maybe you can show us how
> `comment-dwim' provides the same behavior.
>
> > It definitely can create nested comments (i.e. in
> > the cases they are really needed, when you call it
> > on a region containing both commented and
> > non-commented lines).
>
> A bit of a tautology.  I can leap over buildings
> in a single bound, in the cases where that's
> really needed, which is when the buildings are
> at most 1-foot tall.
>
> Anyway.  The point of this thread is the problem
> with `comment-line' raised by the OP.  If you're
> curious why `comment-line' was added, since we
> already had `comment-dwim', see the thread I
> pointed to, where `comment-line' was discussed
> and added.
>


-- 
---
PEDRO ANDRES ARANDA GUTIERREZ
Universidad Carlos III de Madrid

"Fragen sind nicht da um beantwortet zu werden.
Fragen sind da, um gestellt zu werden" Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 3759 bytes --]

Re: Just a thought about comment-line

[PEDRO ANDRES ARANDA GUTIERREZ]

[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]

And BTW, my code looks like:

(defun my-comment-line-region (beg end)
  "Comment all complete lines in a region using comment-line
if the region does not start at a beginning of line, expand it"
  (interactive "r")
  (save-excursion
   (save-restriction
   (narrow-to-region (get-bol beg) end)
   (push-mark (point-min))
   (goto-char (point-max))
   (call-interactively 'comment-line)
   (pop-mark))))

It seems that narrowing helps avoiding that last comment. Don't know how
much of an overkill this might be, but
it works for me(tm)

Best PA

El lun., 1 jun. 2020 a las 7:18, PEDRO ANDRES ARANDA GUTIERREZ (<
paranda@it.uc3m.es>) escribió:

> Hey,
>
> thanks for all the answers so far. It's nice to see people getting
> passionate about this.
> I too had my code to deal with (bol-p end-of-region) and I'm passing it on
> to people,
> but I started writing a short introduction for students who get interested
> in Emacs by
> seeing how I use it and well, it'd be so much better for Emacs if I could
> get one of the
> FAQ answered by something like 'customise variable so-and-so to get your
> desired
> behaviour' instead of 'include <listing 100> in your .emacs.d/functions.el
> and bind function
> sensible-comment-lines to M-;'
>
> I hope the discussion crystallises in some better future :-)
>
> Best, /PA
> PS: and as my signature translates ;-) "questions exist to be made, not to
> be answered"
>
> El dom., 31 may. 2020 a las 23:54, Drew Adams (<drew.adams@oracle.com>)
> escribió:
>
>> > > You're fairly sure for whom?  For you?  Not for me.
>> >
>> > The only complaints against comment-dwim I have seen
>>
>> I wasn't complaining about `comment-dwim'.
>> I was saying that it's not the be-all and
>> end-all.  I use it for end-of-line comments.
>> And I use something else for block commenting.
>>
>> It doesn't matter to me if you use `M-;' for
>> everything.  If you're happy that way, great.
>>
>> > were along the lines "I want to micromanage
>> > how comments are made",
>>
>> I see.  If someone says your one-size-fits-all
>> dream command doesn't fit all then their idea
>> for doing something additional or different
>> just wastes your time.  Sorry to hear that.
>>
>> > and not "this code-writing scenario becomes
>> > suboptimal".
>> >
>> > Are you still writing code? I'm surprised,
>>
>> Surprise!  And irrelevant.
>>
>> > > Tell me why Common Lisp behavior for block comments
>> > > (#|...|#) is missing?  I don't mean that those macro
>> > > chars are missing, but that the block-commenting
>> > > behavior (nesting, unnesting) is missing.
>> >
>> > You might want to elaborate.
>>
>> I think I did.  Maybe you can show us how
>> `comment-dwim' provides the same behavior.
>>
>> > It definitely can create nested comments (i.e. in
>> > the cases they are really needed, when you call it
>> > on a region containing both commented and
>> > non-commented lines).
>>
>> A bit of a tautology.  I can leap over buildings
>> in a single bound, in the cases where that's
>> really needed, which is when the buildings are
>> at most 1-foot tall.
>>
>> Anyway.  The point of this thread is the problem
>> with `comment-line' raised by the OP.  If you're
>> curious why `comment-line' was added, since we
>> already had `comment-dwim', see the thread I
>> pointed to, where `comment-line' was discussed
>> and added.
>>
>
>
> --
> ---
> PEDRO ANDRES ARANDA GUTIERREZ
> Universidad Carlos III de Madrid
>
> "Fragen sind nicht da um beantwortet zu werden.
> Fragen sind da, um gestellt zu werden" Georg Kreisler
>


-- 
---
PEDRO ANDRES ARANDA GUTIERREZ
Universidad Carlos III de Madrid

"Fragen sind nicht da um beantwortet zu werden.
Fragen sind da, um gestellt zu werden" Georg Kreisler

[-- Attachment #2: Type: text/html, Size: 5231 bytes --]

Re: Just a thought about comment-line

[Clément Pit-Claudel]

On 31/05/2020 03.39, PEDRO ANDRES ARANDA GUTIERREZ wrote:
> However let's suppose that your theme is highlighting the region and you comment the region with M-x comment-line. You will have the line at the point:
> 1.- not highlighted before M-x comment-line
> 2.- commented after M-x comment-line

Is this bug 21921, or am I misunderstanding the report? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21921
If it is the same issue, then I agree with you wholeheartedly :)