Re: comment-kill and the state of the world

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

Ian> Ah, but you get the same thing with comment-dwim with an argument
Ian> on a line with an existing comment.  Is that any better?
Stefan> The command throuh which you reach the code is not very
Stefan> relevant.
> I don't understand.  Are you saying people delete comments by hand with,
> say, M-; C-p C-p C-k ?  Or is there some other way I don't know about?

Looks like I don't understand either.  You complained about a behavior of
comment-kill and I replied that I had no idea why the behavior was like
that and that I didn't know anybody who used comment-kill.
Then you said "but the same applies
to comment-dwim", at which point I tried to clear up the fact that
my earlier answer applied to the comment-kill function as much as
the command.

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

Stefan> Huh?  They are separate.  You can call comment-indent or
Stefan> comment-region or uncomment-region or comment-kill directly.

> Yes.  But comment-dwim does more than just dispatch to them.  If you
> call them directly, you lose the benefit of that additional code,
> whatever it is.

The only non-dispatch part of the code is the part that inserts
a comment on an empty line.  Are you saying that we should move
that code out into its own function?  That'd be fine by me.

> How am I not being constructive?  I am driven by desire to improve the
> code.  I feel that comment-dwim, unless changed into a dispatch routine
> and nothing else, is a bad idea and getting rid of it would be an
> improvement. 

I'm sorry, I felt you were not being constructive, whereas what is going on
is just that I have difficulty understand what you want.
`comment-dwim' is meant to be just a dispatch function, so if there's
a part that isn't and that you need it to be, it should be easy to fix.

> Maybe I should clarify: my point of view is not an end user's one, but a
> Lisp programmer's one, specifically one writing a major mode for a
> programing language.  I'd like to use the existing generic comment code,
> but I find its complexity gets in the way.

Can you say precisely which part?

> First, comment-indent already tests for an empty line.  Why not add the
> special code there, rather than in comment-dwim?

History.  `comment-indent' (or more specifically indent-for-comment)
in Emacs-20 inserted a comment at `comment-column' when called on an
empty line.  I did not dare to change this behavior.

> Second, do you have any advice for me when I _want_ them to behave the same?

Which difference are you referring to ?
Since I have trouble understanding your problems, please try to be
very precise and concrete.

> (Perhaps with the exception of indentation, but comment-indent-function
> should take care of that).  Just ignoring comment-dwim doesn't solve it
> because comment-region also uses the "other" settings.

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

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

> Isn't that exactly what I wrote in my first post?  And you seemed to
> indicate it wans't as important as I thought.

It's important for things that are used.  I don't think the behavior of
comment-kill is that important, I expect that we can convince RMS to
change it.  OTOH, changing the way comment-indent and comment-region
are configured by elisp packages is a lot more difficult because
the elisp packages might not be maintained any more and those
functions are used heavily, so backward compatibility is a lot
more constraining.

> BTW, another bug is that comment-indent uses (indent-according-to-mode)
> to position the comment when comment-indent-function returns nil.  That
> makes no sense when there's preceding code on the line

Indeed, that's a clear bug.  Does the patch below fix it for you ?

> (which is always, now that comment-dwim handles the empty case itself).

It's not always: comment-indent can still be called directly by
the user, and (more importantly), it is called by comment-indent-new-line,
i.e. by the auto-fill code.

> Fortunately, this is easy to work around, I just make sure my
> comment-indent-function _never_ returns nil.

The nil return value is new in Emacs-21, and obviously not
well-tested yet.  Thanks for your report,


        Stefan


Index: newcomment.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/newcomment.el,v
retrieving revision 1.68
diff -u -u -b -r1.68 newcomment.el
--- newcomment.el	1 Sep 2003 15:45:13 -0000	1.68
+++ newcomment.el	19 Oct 2003 23:07:20 -0000
@@ -501,6 +501,10 @@
       (goto-char begpos)
       ;; Compute desired indent.
       (setq indent (save-excursion (funcall comment-indent-function)))
+      ;; If `indent' is nil and there's code before the comment, we can't
+      ;; use `indent-according-to-mode', so we default to comment-column.
+      (unless (or indent (save-excursion (skip-chars-backward " \t") (bolp)))
+	(setq indent comment-column))
       (if (not indent)
 	  ;; comment-indent-function refuses: delegate to line-indent.
 	  (indent-according-to-mode)