I like to write the doc strings for functions using the following style, when writing Javascript (using `js-mode`).
/**
* Erase floor tile, if any.
*/
function removeFloor (x, y) {
var old = Map.data.get(x, y).floor;
if (old)
replaceFloor(x, y, old, null);
}
By default, hitting `RET` inside a comment or writing long comment lines does nothing special. Here’s what I prefer:
(add-hook 'js-mode-hook
(lambda ()
(setq indent-tabs-mode nil
js-indent-level 2)
(idle-highlight-mode 1)
;; writing longer comments
(setq-local comment-auto-fill-only-comments t)
(auto-fill-mode 1)
(setq-local comment-multi-line t)
(local-set-key (kbd "RET") 'c-indent-new-comment-line)))
Writing long comment lines will fill them automatically, and when I hit `RET`, comments are continued using the prefix “ _ “ instead of just “ ”._
#Emacs
(Please contact me if you want to remove your comment.)
⁂
Thanks for this, Alex. I don’t write Javascript often, and had never been sufficiently motivated to figure out why `(local-set-key (kbd "RET") (key-binding (kbd "M-j")))` was so broken for Javascript block comments. Presumably js-mode should actually be binding `M-j` to `c-indent-new-comment-line`
– Anonymous 2016-03-07 03:41 UTC
---
...in fact I see that it’s the *combination* of `(setq-local comment-multi-line t)` and `(local-set-key (kbd "RET") 'c-indent-new-comment-line)` which fixes this, rather than the command alone. (So that `comment-multi-line` setting is important for both the indent-new-comment-line behaviour and the auto-fill behaviour).
My `(local-set-key (kbd "RET") (key-binding (kbd "M-j")))` happens in `prog-mode-hook` so I’ve added the following at `js-mode-hook`:
`(setq-local comment-multi-line t)`
`(local-set-key [remap indent-new-comment-line] 'c-indent-new-comment-line))`
– Phil 2016-03-07 04:30 UTC
---
I did not consider using *remap*. Interesting.
My setup has the strange effect that `//` are also continued on the next line. That’s unexpected:
/**
* test
*/
function () {
foo; // bar
// █
Actually, now that I’ve gone back, it seems to me that `comment-multi-line` can still be `nil`. I use `M-q` on long comments with `comment-multi-line` set to `nil` and got the following:
/**
* test test test test test test test test test test test test test
* test test test test test test test
*/
function () {
foo; // bar test test test test test test test test test test test
// test test test test test test test test
quux;
Good enough for `M-q`? Yes.
But now I remember: `comment-multi-line` has an effect on `auto-fill-mode`. Here’s what you get as you type a long comment line with `comment-multi-line` set to `t`:
/**
* test test test test test test test test test test test test test
test █
*/
function () {
foo; // bar
//
Here’s what you get as you type a long comment line with `comment-multi-line` set to `nil`:
/**
* test test test test test test test test test test test test test */
/**test █
*/
function () {
foo; // bar
//
OK, so that explains `comment-multi-line`. I still thought I had a good solution for `auto-fill-mode` and now it seems that I don’t. Looking at `do-auto-fill` it seems that `fill-context-prefix` finds no prefix. It determines `first-line-prefix` to be the empty string and `second-line-prefix` to be “ _ “. So why isn’t it used?_
There’s this test: `(string-match re first-line-prefix)` with `re` being `\`.**”`. So where's the problem? Should`first-line-prefix`be`***`such that this test succeeds and`second-line-prefix` is picked? Because now we’re getting to “the longest common substring of both prefixes” resulting in the empty string.***
It seems to me that `fill-match-adaptive-prefix` ought to return `/**` and it does not. There, we find `(looking-at adaptive-fill-regexp)` which matches and `(match-string 0)` which returns the empty string.
Sooo... `(setq adaptive-fill-regexp "[ ]*\\(//+\\|/?\\**\\)[ ]*\\([ ]*\\([-–!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)")` fixes this by inserting `/?`. The segment in question is from `c-comment-prefix-regexp` which is set to `//+\\|\\**`. Now what? It’s doc string says: “it does not need to match a block comment starter” Does it?
So, I propose:
(setq c-comment-prefix-regexp "//+\\|/?\\**") (let ((c-buffer-is-cc-mode t)) (c-setup-paragraph-variables))
Either way, it’s not too bad in `//` comments:
/**
* test
*/
function () {
foo; // bar test test test test test test test test test test test
// test █
– Alex Schroeder 2016-03-07 11:28 UTC