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: Aaron Jensen <aaronjensen <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60186 <at> debbugs.gnu.org
Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Tue, 27 Dec 2022 19:38:14 -0500

On Tue, Dec 27, 2022 at 6:04 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 27/12/2022 18:34, Aaron Jensen wrote:
>
> >>> Simple is what it is in comparison to something more complex.
> >>
> >> Just 1 indent vs arbitrary number of indents depending on operator
> >> priority/ast nesting. Seems like "simpler" is appropriate.
> >
> > Right, but that was my point. The name doesn't stand on its own. It
> > only stands relative to some other more complex indentation scheme. If
> > we can find a name that stands on its own, I think that would be
> > better.
>
> That's true.
>
> But it seems we've rejected most of each other's suggestions by now.
>
> >>> All
> >>> indentations are pretty much about line continuation in one way or
> >>> another.
> >>
> >> Okay, how about ruby-indent-operator-continuation?
> >>
> >> Or ruby-indent-binary-op-continuation. Which would include all binary
> >> operators and method calls. *shrug* We could also split off the method
> >> call indentation to a separate option too.
> >
> > Right, maybe it makes sense to consider one of two directions:
> >
> > 1. A single option to enable this "simple" indentation mode, i.e.
> > ruby-indent-alignment: line/statement/start/beginning vs. sibling/end
> > 2. Split each different rule into its own option and name them
> > according to the specific circumstance the rule covers. I still don't
> > know what the options would be.
> >
> > That said, when you say method calls, you mean the '.' operator, yes?
> > I see what you're getting at with this naming and I think it's
> > probably cohesive enough to be one option per #2 above.
>
> Right. If we consider "." as something distinct, it could use a separate
> option. Or not. But it's trivial to separate.
>
> >> "Standard" is a point of view. ;-)
> >
> > Indeed... there is also https://github.com/testdouble/standard but I
> > think it's a bit of a land grab to call it standard and I've never
> > really looked at it.
>
> Concur.
>
> > I put incremental in the last list since I was trying to get at the
> > fact that the indentation increases by one increment at a time.
>
> IDK, there might be different connotations, e.g. it always grows (though
> slowly).
>
>  >  Is
>  > there something about it being that vs it context-aware?
> > Obviously all
> > indentation is context aware, so I'm not sure that that's the right
> > direction.
>
> "More" context-aware, one could say. Or less. But that's the same as
> "simpler".
>
> I suppose we could call it structural..? The current behavior, that is.
> As in
> https://github.com/yairchu/awesome-structure-editors#structural-code-editor-projects.
>
> 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?

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?

Aaron

Previous Next

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