From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: one key-press to comment out lines of code? Date: Thu, 01 May 2014 15:54:31 +0200 Organization: Aioe.org NNTP Server Message-ID: <87ha59ioyw.fsf@nl106-137-194.student.uu.se> References: <87fvku94ms.fsf@skimble.plus.com> <874n1ak5b9.fsf@nl106-137-194.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398952533 19556 80.91.229.3 (1 May 2014 13:55:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2014 13:55:33 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu May 01 15:55:28 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfrSP-0001Vm-Kj for geh-help-gnu-emacs@m.gmane.org; Thu, 01 May 2014 15:55:25 +0200 Original-Received: from localhost ([::1]:39754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfrSP-0006ZS-0z for geh-help-gnu-emacs@m.gmane.org; Thu, 01 May 2014 09:55:25 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 85 Original-NNTP-Posting-Host: VVbyYd/iFZoeWNmD9i++cQ.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:rMttpgzXEg03YsrdMSqNv50yDUY= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:205243 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:97510 Archived-At: Drew Adams writes: > `M-;' cannot uncomment the commented lines in the > region when there are also uncommented lines. Alright, nested comments! I never did that so I never thought about it. But what I can see, M-; works for those as well: ;; ;; commented-out comment into ;; commented-out comment and ;; (message "done") ; redundant comment into (message "done") ; redundant comment as well as "mulit-;" comments: ;;;; IMPORTANT into IMPORTANT Case 1 and 2 makes sense, case 3 sort of makes sense (?) but I can't visualize why you'd ever want to do that - actually it is clear it is not code so perhaps it shouldn't be uncommented. There are many use-cases for comments. I use several ; for headers, like ;;; summary (setq gnus-summary-line-format "%2{%U%} %0{%I%a%} %1{%s%}\n") (setq gnus-summary-mode-line-format "%G") Then one-liners explaining code only when it can't be deducted what the code says: (setq gnus-interactive-catchup nil) ; no confirm on catchup or the same case, but with an argument: (save-buffers-kill-terminal 1) ; don't ask, save I don't really comment-out code - but when I do, M-; always worked. What are the use-cases where M-; doesn't work? Perhaps that could be solved somehow - depends on how varied, and how advanced, those situations are, of course. > A DWIM command is often limited this way; it is a > compromise. It doesn't have to be. A DWIM command is a command with parameters just like any other, only (at least) one of those parameters are not supplied in the traditional way, instead it (or they) are extracted from the current program state. In Emacs, in my experience, the state has been related to either the existence of a region, *or* the point position and in particular the thing-at-point: if it is a URL, view it with w3m; if a file name, find-file; if a file name outside of HOME, find-file with /sudo::; etc. Now, in many cases you change (setup) the state before you invoke the DWIM command just to get a specific behaviour. So I guess that would be 50% DWIM, and 50% "provide the argument in an alternative way". But when you start using it, you never think about that distinction, of course. -- underground experts united: http://user.it.uu.se/~embe8573