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 #19 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 16:41:48 -0700

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

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.