bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions


From: Dmitry Gutov
Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Tue, 20 Dec 2022 17:53:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 20/12/2022 07:56, Aaron Jensen wrote:
On Mon, Dec 19, 2022 at 11:48 PM Aaron Jensen<aaronjensen@gmail.com>  wrote:
On Mon, Dec 19, 2022 at 9:12 PM Dmitry Gutov<dgutov@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]