M-q on comments in source code

M-q on comments in source code

[lee]

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.

Re: M-q on comments in source code

[Eli Zaretskii]

> 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.

Re: M-q on comments in source code

[Stefan Monnier]

> 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

Re: M-q on comments in source code

[Andreas Röhler]

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?

Re: M-q on comments in source code

[lee]

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.

Re: M-q on comments in source code

[lee]

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.

Re: M-q on comments in source code

[Stefan Monnier]

> 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

solved: M-q on comments in source code

[lee]

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.