* M-q on comments in source code
@ 2014-05-24 11:37 lee
2014-05-24 12:47 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: lee @ 2014-05-24 11:37 UTC (permalink / raw)
To: help-gnu-emacs
Hi,
modes like c-mode indent comments with the code, which is fine as an end
result and not so ideal when writing them. To give an example:
,----
| if(full)
| {
| //
| // A max value might be removed when the arrays are shifted. In
| // that case, find a new one after shifting. Otherwise, the max
`----
Now press M-q to format the comment and the above looks like this:
,----
| if(full)
| {
| //
| // A max value might be
| // removed when the arrays are
| // shifted. In that case,
| // find a new one after
| // shifting. Otherwise, the
| // max continues to be known.
`----
This formatting is a bit silly ... What can I do to get the comments
formatted as in the first example, i. e. the comment indented with the
source but with each line trimmed to a length of about max 75
characters, not counting the indentation?
I can manually unindent the lines, edit them, format them and reindent
them, and I`m looking for a better way. Even something like
auto-fill-mode for comments that does it automatically would be nice.
--
Knowledge is volatile and fluid. Software is power.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 11:37 M-q on comments in source code lee
@ 2014-05-24 12:47 ` Eli Zaretskii
2014-05-24 14:21 ` Stefan Monnier
2014-05-24 15:41 ` Andreas Röhler
2 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2014-05-24 12:47 UTC (permalink / raw)
To: help-gnu-emacs
> From: lee <lee@yun.yagibdah.de>
> Date: Sat, 24 May 2014 13:37:03 +0200
>
> modes like c-mode indent comments with the code, which is fine as an end
> result and not so ideal when writing them. To give an example:
>
>
> ,----
> | if(full)
> | {
> | //
> | // A max value might be removed when the arrays are shifted. In
> | // that case, find a new one after shifting. Otherwise, the max
> `----
>
>
> Now press M-q to format the comment and the above looks like this:
>
>
> ,----
> | if(full)
> | {
> | //
> | // A max value might be
> | // removed when the arrays are
> | // shifted. In that case,
> | // find a new one after
> | // shifting. Otherwise, the
> | // max continues to be known.
> `----
>
>
> This formatting is a bit silly ... What can I do to get the comments
> formatted as in the first example, i. e. the comment indented with the
> source but with each line trimmed to a length of about max 75
> characters, not counting the indentation?
One way is to set fill-column to a larger value.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 11:37 M-q on comments in source code lee
2014-05-24 12:47 ` Eli Zaretskii
@ 2014-05-24 14:21 ` Stefan Monnier
2014-05-24 18:00 ` lee
2014-05-24 15:41 ` Andreas Röhler
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2014-05-24 14:21 UTC (permalink / raw)
To: help-gnu-emacs
> This formatting is a bit silly ... What can I do to get the comments
> formatted as in the first example, i. e. the comment indented with the
> source but with each line trimmed to a length of about max 75
> characters, not counting the indentation?
I find this to be a waste of space (you'll need windows
larger than 80 columns to comfortably edit/browse such files), but if
you really want that you can probably get it with something like:
(advice-add 'current-file-column :around
(lambda (orig)
(if (derived-mode-p 'c-mode)
(+ fill-column (current-indentation))
(funcall orig))))
-- Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 11:37 M-q on comments in source code lee
2014-05-24 12:47 ` Eli Zaretskii
2014-05-24 14:21 ` Stefan Monnier
@ 2014-05-24 15:41 ` Andreas Röhler
2014-05-24 17:32 ` lee
2 siblings, 1 reply; 8+ messages in thread
From: Andreas Röhler @ 2014-05-24 15:41 UTC (permalink / raw)
To: help-gnu-emacs
On 24.05.2014 13:37, lee wrote:
> Hi,
>
> modes like c-mode indent comments with the code, which is fine as an end
> result and not so ideal when writing them. To give an example:
>
>
> ,----
> | if(full)
> | {
> | //
> | // A max value might be removed when the arrays are shifted. In
> | // that case, find a new one after shifting. Otherwise, the max
> `----
>
>
> Now press M-q to format the comment and the above looks like this:
>
>
> ,----
> | if(full)
> | {
> | //
> | // A max value might be
> | // removed when the arrays are
> | // shifted. In that case,
> | // find a new one after
> | // shifting. Otherwise, the
> | // max continues to be known.
> `----
>
>
> This formatting is a bit silly ... What can I do to get the comments
> formatted as in the first example, i. e. the comment indented with the
> source but with each line trimmed to a length of about max 75
> characters, not counting the indentation?
>
> I can manually unindent the lines, edit them, format them and reindent
> them, and I`m looking for a better way. Even something like
> auto-fill-mode for comments that does it automatically would be nice.
>
>
M-x customize-variable RET comment-style RET
setting it to 0, "plain", does this solve it?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 15:41 ` Andreas Röhler
@ 2014-05-24 17:32 ` lee
0 siblings, 0 replies; 8+ messages in thread
From: lee @ 2014-05-24 17:32 UTC (permalink / raw)
To: help-gnu-emacs
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> I can manually unindent the lines, edit them, format them and reindent
>> them, and I`m looking for a better way. Even something like
>> auto-fill-mode for comments that does it automatically would be nice.
>>
>>
>
> M-x customize-variable RET comment-style RET
>
> setting it to 0, "plain", does this solve it?
Nope --- trying the different options doesn`t seem to make a difference.
And I`m not sure what to expect from "plain". I`d expect the comments
to be moved to the start of the line and formatted from there with M-q,
and that doesn`t happen.
--
Knowledge is volatile and fluid. Software is power.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 14:21 ` Stefan Monnier
@ 2014-05-24 18:00 ` lee
2014-05-24 18:50 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: lee @ 2014-05-24 18:00 UTC (permalink / raw)
To: help-gnu-emacs
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> This formatting is a bit silly ... What can I do to get the comments
>> formatted as in the first example, i. e. the comment indented with the
>> source but with each line trimmed to a length of about max 75
>> characters, not counting the indentation?
>
> I find this to be a waste of space (you'll need windows
> larger than 80 columns to comfortably edit/browse such files),
The lines in the source can easily get longer than 80 cpl, and my screen
is wider than it is high, so it`s the opposite for me: Source with long
lines is easier to review than source with short, broken lines. And
there`s astyle ...
;;
;; astyle buffer ...
;;
(defun astyle-buffer (mcl)
"Ask for code length and pipe all buffer contents through
astyle and replace with the output from astyle, then do
whitespace-cleanup."
(interactive "nMax code length: ")
(shell-command-on-region (point-min) (point-max) (format "astyle --max-code-length=%d" mcl) nil t 'shell-command-default-error-buffer t)
(whitespace-cleanup))
... which does break long lines but doesn`t put broken lines back
together. (I have an .astylerc with some settings I like.)
> but if you really want that you can probably get it with something
> like:
>
> (advice-add 'current-file-column :around
> (lambda (orig)
> (if (derived-mode-p 'c-mode)
> (+ fill-column (current-indentation))
> (funcall orig))))
Hmm, yes, this is like Eli suggested, thank you :)
I think I can come up with a function that is called instead of
c-fill-paragraph, adjusts fill-column when comments are formatted, calls
c-fill-paragraph and resets fill-column. That should work ...
I`ll post it once I wrote it.
--
Knowledge is volatile and fluid. Software is power.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: M-q on comments in source code
2014-05-24 18:00 ` lee
@ 2014-05-24 18:50 ` Stefan Monnier
2014-05-24 23:01 ` solved: " lee
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2014-05-24 18:50 UTC (permalink / raw)
To: help-gnu-emacs
> The lines in the source can easily get longer than 80 cpl,
Many coding guidelines recommend staying within 80 columns, so YMMV.
> and my screen is wider than it is high, so it`s the opposite for me:
I rarely look at a single file at a time, so wider windows means
fewer windows.
> Source with long lines is easier to review than source with short,
> broken lines.
We don't want them too short, indeed, which means not too
indented, mostly.
This typically goes hand-in-hand with keeping
functions/methods reasonably short.
Stetfan
^ permalink raw reply [flat|nested] 8+ messages in thread
* solved: M-q on comments in source code
2014-05-24 18:50 ` Stefan Monnier
@ 2014-05-24 23:01 ` lee
0 siblings, 0 replies; 8+ messages in thread
From: lee @ 2014-05-24 23:01 UTC (permalink / raw)
To: help-gnu-emacs
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> and my screen is wider than it is high, so it`s the opposite for me:
>
> I rarely look at a single file at a time, so wider windows means
> fewer windows.
Usually, I can fit two side by side and can split vertically when I need
to.
>> Source with long lines is easier to review than source with short,
>> broken lines.
>
> We don't want them too short, indeed, which means not too
> indented, mostly.
I`m finding things easier to read with what you might call excessive
indentation :)
> This typically goes hand-in-hand with keeping functions/methods
> reasonably short.
Mostly, I`m writing things in LSL --- which is a scripting language
somewhat similar to C. Such scripts are limited to 64kB each, and
functions are big memory eaters, so you have to avoid them as much as
you can :( It`s pretty horrible and makes for "lengthy" code like no
sane programmer wants to write. I`m running the source through cpp and
use #defines somewhat heavily, which helps a lot ...
Anyway, here`s what I came up with:
(defun my-fill-comment ()
(interactive)
(save-excursion
(beginning-of-line)
(if (search-forward comment-start (line-end-position) t)
(let ((orig-fill-column fill-column))
(setq fill-column (+ orig-fill-column (current-indentation)))
(c-fill-paragraph)
(setq fill-column orig-fill-column))
(c-fill-paragraph))))
I haven`t tested it much yet, but it seems to do what I want :) I`ll
make a key binding for it and see how it turns out.
Perhaps
(re-search-forward (concat "^[:space:]*" comment-start)
(line-end-position) t)
is better, but I don`t plan on using the function on anything else than
comments (starting with "//") anyway.
--
Knowledge is volatile and fluid. Software is power.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-05-24 23:01 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-24 11:37 M-q on comments in source code lee
2014-05-24 12:47 ` Eli Zaretskii
2014-05-24 14:21 ` Stefan Monnier
2014-05-24 18:00 ` lee
2014-05-24 18:50 ` Stefan Monnier
2014-05-24 23:01 ` solved: " lee
2014-05-24 15:41 ` Andreas Röhler
2014-05-24 17:32 ` lee
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).