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: Wed, 28 Dec 2022 03:02:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 28/12/2022 02:38, Aaron Jensen wrote:

Or here's a step back: looking at how the two other user options I named
previously were ruby-method-params-indent and ruby-block-indent, the
latest might as well be called ruby-operator-indent, or
ruby-operator-indent and ruby-method-call-indent.

I wasn't too crazy about those names originally, but the approach is
very extensible with styles by adding new symbols as possible values.

This may end up being the right direction. If the values are symbols
you can use things that are relative to one another like "simple".
There could be a benefit to all of these having a "simple" option.
What would it mean if it were nil?
What's the current behavior called?

For the sake of uniformity, I wanted to start with simple values -- t and nil, and explain their meanings in the docstring.

't' would mean the current behavior, and I'd call it "structural", or structure-based indentation. Or based on implicit expression grouping.

It may be that if we only intend to support two indentation schemes we
just have default and simplified as you suggested and then we can use
boolean values. I don't know how Emacs-like this is, but what if there
were one variable like `ruby-indent-simple` that could either be `t`
or a list of things to indent simply?

That can work too, but what is "simple"? ;-)

Further, I'm not sure if we're going to get more than 2 "things" this way (operators and method calls). OTOH, if we have a separate var for operators -- ruby-operator-indent -- we could enumerate which operators to indent "structurally" after. Or something like that.

Not sure which direction the feature requests will drive this extension toward, though. Maybe mostly nowhere, given the previous history. But Rubocop's example seems to indicate that there are many different styles out there.





reply via email to

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