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: Sun, 19 Oct 2003 23:14:46 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066605477 25981 80.91.224.253 (19 Oct 2003 23:17:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2003 23:17:57 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Oct 20 01:17:55 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 1ABMo6-0000FB-01 for ; Mon, 20 Oct 2003 01:17:54 +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 1ABMmJ-0001hk-0Y for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Oct 2003 19:16:03 -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: 126 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 1066605286 132.204.24.42 (Sun, 19 Oct 2003 19:14:46 EDT) Original-NNTP-Posting-Date: Sun, 19 Oct 2003 19:14:46 EDT Original-Xref: shelby.stanford.edu gnu.emacs.help:117422 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:13353 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13353 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? Looks like I don't understand either. You complained about a behavior of comment-kill and I replied that I had no idea why the behavior was like that and that I didn't know anybody who used comment-kill. Then you said "but the same applies to comment-dwim", at which point I tried to clear up the fact that my earlier answer applied to the comment-kill function as much as the command. 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. The only non-dispatch part of the code is the part that inserts a comment on an empty line. Are you saying that we should move that code out into its own function? That'd be fine by me. > 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. I'm sorry, I felt you were not being constructive, whereas what is going on is just that I have difficulty understand what you want. `comment-dwim' is meant to be just a dispatch function, so if there's a part that isn't and that you need it to be, it should be easy to fix. > 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. Can you say precisely which part? > First, comment-indent already tests for an empty line. Why not add the > special code there, rather than in comment-dwim? History. `comment-indent' (or more specifically indent-for-comment) in Emacs-20 inserted a comment at `comment-column' when called on an empty line. I did not dare to change this behavior. > Second, do you have any advice for me when I _want_ them to behave the same? Which difference are you referring to ? Since I have trouble understanding your problems, please try to be very precise and concrete. > (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. It's important for things that are used. I don't think the behavior of comment-kill is that important, I expect that we can convince RMS to change it. OTOH, changing the way comment-indent and comment-region are configured by elisp packages is a lot more difficult because the elisp packages might not be maintained any more and those functions are used heavily, so backward compatibility is a lot more constraining. > 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 Indeed, that's a clear bug. Does the patch below fix it for you ? > (which is always, now that comment-dwim handles the empty case itself). It's not always: comment-indent can still be called directly by the user, and (more importantly), it is called by comment-indent-new-line, i.e. by the auto-fill code. > Fortunately, this is easy to work around, I just make sure my > comment-indent-function _never_ returns nil. The nil return value is new in Emacs-21, and obviously not well-tested yet. Thanks for your report, Stefan Index: newcomment.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/newcomment.el,v retrieving revision 1.68 diff -u -u -b -r1.68 newcomment.el --- newcomment.el 1 Sep 2003 15:45:13 -0000 1.68 +++ newcomment.el 19 Oct 2003 23:07:20 -0000 @@ -501,6 +501,10 @@ (goto-char begpos) ;; Compute desired indent. (setq indent (save-excursion (funcall comment-indent-function))) + ;; If `indent' is nil and there's code before the comment, we can't + ;; use `indent-according-to-mode', so we default to comment-column. + (unless (or indent (save-excursion (skip-chars-backward " \t") (bolp))) + (setq indent comment-column)) (if (not indent) ;; comment-indent-function refuses: delegate to line-indent. (indent-according-to-mode)