unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: comment-kill and the state of the world
Date: Fri, 17 Oct 2003 20:01:09 GMT	[thread overview]
Message-ID: <jwvfzhrprua.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca> (raw)
In-Reply-To: 87r81byg53.fsf@newsguy.com

> 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

  reply	other threads:[~2003-10-17 20:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-16 17:54 comment-kill and the state of the world Ian Zimmerman
2003-10-16 19:11 ` Stefan Monnier
2003-10-17 16:37   ` Ian Zimmerman
2003-10-17 20:01     ` Stefan Monnier [this message]
2003-10-18 17:42       ` Ian Zimmerman
2003-10-19 23:14         ` Stefan Monnier
2003-10-23 22:01           ` Ian Zimmerman
2003-10-24 15:41             ` Stefan Monnier
2003-10-24 17:17               ` Ian Zimmerman
2003-10-24 19:48                 ` Stefan Monnier
2003-10-30 23:59                   ` Ian Zimmerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvfzhrprua.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca \
    --to=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).