Updated patch with more precise variables in the new test.


Aaron


On Sat, Aug 31, 2024 at 7:41 PM, Aaron Jensen <aaronjensen@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@gmail.com>
> wrote:
>
> On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov@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
>
>