bug#25904: Formatting bug with js-mode

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Felipe!

On 11/8/17 1:55 AM, Felipe Ochoa wrote:
> Here's an initial implementation of a solution for this issue. (Also 
> filed as js2#314 [1])
> 
> foo.bar.baz(very =>  very  // current code aligns return value to paren 
> above ).biz(baz =>  baz
> );
> 
> I've been using this code successfully for a number of days now, but 
> since it's my first time touching indentation code, it likely needs 
> review for I comments and whitespace handling, etc.

I think the code is reasonable, but the patch needs a few examples for 
emacs/test/manual/js*.js. Maybe add a new file, or maybe reuse an 
existing one.

It also wouldn't hurt that the existing examples are unchanged with the 
new code.

>               (skip-chars-backward " \t")
>               (or (bobp) (backward-char))
>               (and (> (point) (point-min))
> -                  (save-excursion (backward-char) (not (looking-at 
> "[/*]/")))
> +                  ;; Need to exclude => here since 
> js--looking-at-operator-p thinks
> +                  ;; it's looking at an assignment operator
> +                  (save-excursion (backward-char) (not (looking-at 
> "[/*]/\\|=>")))

OK.

> @@ -2107,7 +2109,18 @@ indentation is aligned to that column."
>                   (continued-expr-p (js--continued-expression-p)))
>               (goto-char (nth 1 parse-status)) ; go to the opening char
>               (if (or (not js-indent-align-list-continuation)
> -                     (looking-at "[({[]\\s-*\\(/[/*]\\|$\\)"))
> +                     (looking-at "[({[]\\s-*\\(/[/*]\\|$\\)")
> +                     ;; check for a arrow function without parens
> +                     (and (looking-at "(\\s-*\\(async\\s-*\\)?")
> +                          ;; TODO: should call (forward-comment 
> most-positive-fixnum)?

To allow comments between the opening paren and the arglist? Does 
anybody write them there?

> +                          (save-excursion
> +                            (goto-char (match-end 0))
> +                            (cond
> +                             ((eq (char-after) ?\()
> +                              (forward-sexp)
> +                              (looking-at-p 
> "\\s-*=>\\s-*\\(/[/*]\\|$\\)"))
> +                             (t (looking-at-p
> +                                 (concat js--name-re 
> "\\s-*=>\\s-*\\(/[/*]\\|$\\)")))))))

I imagine this (*) could be transformed into a single regexp, though it 
would be pretty complex (rx could help, though!).

(*) Looking at an opening paren followed by ([optional] lambda arglist 
and an arrow) then [optional] comment and newline.

Arglist matcher might be on the big side, but I'm guessing the 
performance will be better. Not sure how big of an issue this is.

If it's not one regexp, moving some of the new code into a helper 
function (with a sensible name) seems prudent.