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.