From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: comment-kill and the state of the world Date: Fri, 24 Oct 2003 19:48:21 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <878ynldq65.fsf@newsguy.com> <87r81byg53.fsf@newsguy.com> <87brsejvdc.fsf@newsguy.com> <87vfqfd35x.fsf@newsguy.com> <87ekx2v9lu.fsf@newsguy.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067025848 16028 80.91.224.253 (24 Oct 2003 20:04:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2003 20:04:08 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Oct 24 22:04:05 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AD8AH-0006ZT-00 for ; Fri, 24 Oct 2003 22:04:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AD886-00081Y-Lk for geh-help-gnu-emacs@m.gmane.org; Fri, 24 Oct 2003 16:01:50 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.24.42 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1067024901 132.204.24.42 (Fri, 24 Oct 2003 15:48:21 EDT) Original-NNTP-Posting-Date: Fri, 24 Oct 2003 15:48:21 EDT Original-Xref: shelby.stanford.edu gnu.emacs.help:117599 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:13532 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13532 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). But that's the case as well if you call `comment-indent' with a pre-existing comment, right? So it's an unrelated bug which comment-padding-foo would not fix (one I remember fixing a while back, but probably only in Emacs-CVS). What was happening is that comment-indent skips the comment starter and the leading spaces to get to the actual content of the comment, but with an empty comment, that tends to leave you right before the commend-end which is not what you want when there's padding. 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. Believe me I haven't met many people who hate redundancy as much as I do. > 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. Feel free to write the patch for it. It already took significant effort to get things as they are, such that it all works the way all the major modes expect it, including using various combinations of comment-start, comment-end, block-comment-start, block-comment-end, comment-multi-line, various ways to call auto-fill, ... And don't forget to come up with a good argument to convince RMS that it's worth it to change the behavior of comment-indent (he happens to like code duplication, as odd as it sounds to most of us). A new pair of eyes will surely help to simplify the code, tho. Stefan