Re: comment-kill and the state of the world

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Ah, but you get the same thing with comment-dwim with an argument on a
> line with an existing comment.  Is that any better?

The command throuh which you reach the code is not very relevant.

> It comes down to comment-dwim.  It really tries to do too much.  The
> different situations should be separated, and then common patterns will
> emerge to make into subroutines.

Huh?  They are separate.  You can call comment-indent or comment-region
or uncomment-region or comment-kill directly.  It's just that after many
years of using those commands (they were there in Emacs-18 already), it
appeared that most of their combined functionality could be provided with
a single key binding.  Feel free not to use it or to criticize
it constructively.

> Right now, comment-dwim calls comment-indent if not a blank line, but
> inserts a comment itself on a blank one.  The two braches are quite
> different, use different customization variables, etc.

They don't use the same settings because experience indicates that they
should behave differently.  For example, in Lisp, comment-indent should use
a single `;' whereas when inserting a comment on a blank line to be
indented at the same level as code, it should use `;;'.  Also in one
circumstance a space might be desired but not in the other, ...

The way to customize those could be improved.  It is currently mostly due
to historical baggage.  For example, the number of spaces to put after
the comment marker in comment-indent can only be specified directly in
`comment-start', whereas comments on their own line specify it with
`comment-add' (which incidentally cannot remove space from
`comment-start').

Suggestions are welcome, but don't forget that supporting people's current
settings (embedded in packages written in 1997, for example) is important.

> And, let me repeat myself, the reindent in comment-kill is a bug.

You can repeat it all you want here, but it will only get heard by the
powers that be if you post it via M-x report-emacs-bug.
I'd tend to agree, BTW, after thinking about it a bit more.


        Stefan