From: Ian Zimmerman <bayard@newsguy.com>
Subject: Re: comment-kill and the state of the world
Date: 18 Oct 2003 10:42:07 -0700 [thread overview]
Message-ID: <87brsejvdc.fsf@newsguy.com> (raw)
In-Reply-To: jwvfzhrprua.fsf-monnier+gnu.emacs.help@vor.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?
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.
Stefan> It's just that after many years of using those commands (they
Stefan> were there in Emacs-18 already), it appeared that most of their
Stefan> combined functionality could be provided with a single key
Stefan> binding. Feel free not to use it or to criticize it
Stefan> constructively.
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.
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.
Ian> Right now, comment-dwim calls comment-indent if not a blank line,
Ian> but inserts a comment itself on a blank one. The two braches are
Ian> quite different, use different customization variables, etc.
Stefan> They don't use the same settings because experience indicates
Stefan> that they should behave differently. For example, in Lisp,
Stefan> comment-indent should use a single `;' whereas when inserting a
Stefan> comment on a blank line to be indented at the same level as
Stefan> code, it should use `;;'. Also in one circumstance a space
Stefan> might be desired but not in the other, ...
First, comment-indent already tests for an empty line. Why not add the
special code there, rather than in comment-dwim?
Second, do you have any advice for me when I _want_ them to behave the same?
(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.
Ian> And, let me repeat myself, the reindent in comment-kill is a bug.
Stefan> You can repeat it all you want here, but it will only get heard
Stefan> by the powers that be if you post it via M-x report-emacs-bug.
Stefan> I'd tend to agree, BTW, after thinking about it a bit more.
OK. But please, let's stop the acrimonious tone. Again, all I want is
to improve Emacs.
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 (which is always,
now that comment-dwim handles the empty case itself). Fortunately, this
is easy to work around, I just make sure my comment-indent-function
_never_ returns nil.
--
Wer Schoenheit angeschaut mit Augen, hat dem Tode schon Anheim gegeben.
Von Platen.
next prev parent reply other threads:[~2003-10-18 17:42 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
2003-10-18 17:42 ` Ian Zimmerman [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87brsejvdc.fsf@newsguy.com \
--to=bayard@newsguy.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.