GNU bug report logs - #60186
29.0.60; ruby-mode indentation of multi-line expressions

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Tue, 20 Dec 2022 17:53:31 +0200

On 20/12/2022 07:56, Aaron Jensen wrote:
> On Mon, Dec 19, 2022 at 11:48 PM Aaron Jensen<aaronjensen <at> gmail.com>  wrote:
>> On Mon, Dec 19, 2022 at 9:12 PM Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
>>> On 19/12/2022 04:54, Aaron Jensen wrote:
>>>> Follow-up to bug#60110
>>> Thanks!
>>>
>>>> I prefer rather simplictic indentation for Ruby (and this appears to be
>>>> pretty common from codebases I've seen). Essentially, the rule is: If an
>>>> expression continues on another line, indent it once.
>>> FWIW, this feels a little wasteful -- working to emulate the editors
>>> which don't have much of a grammar definition, so they mostly line up
>>> things to the beginning of the previous line (plus maybe the indentation
>>> offset).
>>>
>>> But I guess that can make some experience better when working in teams.
>> The implication here is that the current indentation
>> rules are somehow objectively better. I'd argue the opposite,
>>                                        that they have usability issues.
>>
>> 😄
>>
>> In all seriousness though,
> Sorry, I was going to say, this style of indentation is more inline
> with what I see in the wild in Ruby codebases and essentially every
> other editor I've seen. Also, enh-ruby-mode is what I'm using as a
> guide here, and it has a pretty much perfect grasp of the grammar
> since it uses the Ruby parser. It's just a simpler indentation norm.

I do believe it's "better" in the sense that can give more hints to the 
user WRT to the program structure -- which, unlike in Lisp, is not 
always obvious. For example, this:

  some_variable = some_number + some_other_number *
                                some_third_number +
                  some_fourth_number -
                  some_fifth_number

conveys the implicit grouping, based on the operator precedence. It 
might be less important for * vs +, but others can be more obscure.

That's not to say that it must be everyone's cup of tea, or that you 
want it to look "lispy" every time. Ideally, there will always be a way 
to write the code, with default indentation config, that the result 
looks "mundane". E.g.

  some_variable = if true
                    2
                  else
                    3
                  end

=>

  some_variable =
    if true
      2
    else
      3
    end

(this is also customizable)

or

  some_method(foo,
              bar,
              baz)

=>

  some_method(
    foo,
    bar,
    baz
  )

And I'll be the first to admit that the current behavior still has some 
usability issues (though perhaps we'll disagree on the full list).

One example would be the previous bug report of yours, where the 
existing (the current default) behavior didn't really benefit anybody much.

Another -- expressions like

  some_method({
                foo: bar,
                tee: qux
              }, zzz)

where it's not 100% obvious what TRT is, but we could probably do better.

Previous Next

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