From: Ian Zimmerman <bayard@newsguy.com>
Subject: Re: comment-kill and the state of the world
Date: 24 Oct 2003 10:17:17 -0700 [thread overview]
Message-ID: <87ekx2v9lu.fsf@newsguy.com> (raw)
In-Reply-To: jwvznfqslow.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca
Stefan> Could you explain why you'd want the code to be moved into
Stefan> comment-indent?
The next part of the thread/post.
Ian> Second, do you have any advice for me when I _want_ them to behave
Ian> the same?
Stefan> Which difference are you referring to ? Since I have trouble
Stefan> understanding your problems, please try to be very precise and
Stefan> concrete.
Ian> Let's say the language's comment delimiters look like this: {- -} .
Ian> I can configure comment-dwim to leave appropriate amount of
Ian> whitespace and put the point in the right place, so the situation
Ian> after an empty comment is inserted looks like this: {- | -} . But
Ian> that won't affect non-empty lines, because that is handled by
Ian> comment-indent. And vice versa.
Stefan> By "configure comment-dwim", I assume you mean "configure
Stefan> comment-padding".
Stefan> Note that if you "configure comment-dwim" by changing
Stefan> comment-end and comment-start instead (by setting them to "{- "
Stefan> and " -}" for example), it will work the same way for
Stefan> comment-indent.
I'd tried that. comment-indent then leaves point in the wrong place
(right before the second hyphen).
Stefan> Sometimes you want it to behave the same in both case, sometimes
Stefan> you want it to behave differently, which is why there are two
Stefan> ways to configure the spacing. Admittedly, the
Stefan> `comment-padding' way is easier and very different from the
Stefan> other, so it's pretty ugly, but that's the way it worked in
Stefan> Emacs-20, so I had to support it in Emacs-21. RMS would
Stefan> probably accept a patch for a new config option something like
Stefan> `comment-padding-foo' which would be used for comments on
Stefan> non-empty lines and could be set to nil to mean use the same
Stefan> value as `comment-padding'. You'd have to come up with a good
Stefan> name for the variable, tho. It's just that the need hasn't come
Stefan> up yet because configuring comment-start and comment-end works
Stefan> as well in all the actual cases I've come across.
I think it's just sound engineering. Even if the two branches can be
made to behave the same now, the more they change the harder it will be
to achieve that.
I'll see what I can do regarding the name :-)
next prev parent reply other threads:[~2003-10-24 17:17 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
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 [this message]
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=87ekx2v9lu.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.
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).