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

Previous Next

Full log

Message #86 received at 60186 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 60186 <at> debbugs.gnu.org
Subject: Re: bug#60186: 29.0.60; ruby-mode indentation of multi-line
 expressions
Date: Wed, 28 Dec 2022 03:02:11 +0200

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.

Previous Next

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