Re: one key-press to comment out lines of code?

[Emanuel Berg <embe8573@student.uu.se>]

Drew Adams <drew.adams@oracle.com> 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