GNU bug report logs - #60321
29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call

Previous Next

Full log

Message #22 received at 60321 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60321 <at> debbugs.gnu.org
Subject: Re: bug#60321: 29.0.60; ruby-mode indentation of hash or array as
 first arg in multiline method call
Date: Sat, 31 Aug 2024 17:54:05 -0700

[Message part 1 (text/plain, inline)]

Updated patch with more precise variables in the new test.


Aaron


On Sat, Aug 31, 2024 at 7:41 PM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:

> I made an attempt at this (attached). It introduces a new variable:
>
> ruby-bracketed-args-indent
>
> It is set to t by default and the behavior will be as it was before this
> patch.
>
> If it is something other than t, it will cause enable indentation like
> this:
>
> update({
>   key => value,
>   other_key:
> }, {
>   key => value,
>   other_key:
> })
>
> update([
>   1,
>   2
> ], [
>   3,
>   4
> ])
>
> It does not handle cases such as:
>
> some_method({
>   key: :value
> },
> other_argument)
>
> It will indent other_argument to be aligned with the (. This could be
> elaborated further, but I contend that if people are formatting their code
> this way that they likely have rather idiosyncratic formatting requirements
> and they would be best left to do what they want manually.
>
> Thanks,
>
>
> Aaron
>
>
> On Mon, Dec 26, 2022 at 8:38 PM, Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
> On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Vim's choice looks saner to my eye. Probably comes down to the choice of
> indentation algorithm, though.
>
> Agreed, though it's hard to pick which is more sane when all the options
> start with insanity.
>
> If I had to type it as above, I would probably indent it like this:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> But I can't imagine that would be easy to implement at all, so I wouldn't
> bother.
>
> The indentation logic itself might be not that difficult to write, but the
> fact that the expression will have to be reindented as soon as the method
> call grows a second argument (after the user types the comma?), makes it a
> hard sell usability-wise.
>
> Right, I think that's just more of the same thing... We are looking at
> ways of writing code that are out of the realm of reason. It's a challenge
> to define behavior when the behavior could very well be undefined. But, if
> we must define it, then what are our guiding principles? Not having to
> reindent preceding lines when adding a new line may be a very reasonable
> one. In that case, the only two options I could think of would be:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> or
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> The difference being if we decide to dedent upon the last closing
> indent-requiring-token or the first.
>
> I think a reasonable rule of thumb for a human might be: "If you open N
> indents on one line, you must close N indents on one line". Any time you
> stray away from this, behavior becomes... not ideal.
>
> Aaron
>
>

[Message part 2 (text/html, inline)]

[0001-Add-ruby-bracketed-argument-indentation-option.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.