all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.

  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.