GNU bug report logs -
#60321
29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Sun, 25 Dec 2022 21:30:02 UTC
Severity: normal
Merged with 72099
Found in versions 29.0.60, 31.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60321 in the body.
You can then email your comments to 60321 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
aaronjensen <at> gmail.com, bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sun, 25 Dec 2022 21:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
New bug report received and forwarded. Copy sent to
aaronjensen <at> gmail.com, bug-gnu-emacs <at> gnu.org
.
(Sun, 25 Dec 2022 21:30:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
X-Debbugs-CC: aaronjensen <at> gmail.com
Splitting off from debbugs#60186, second try.
Since this setting also seems orthogonal to the "simplified" preference,
and it'll require some more work.
For future reference, here are the relevant Rubocop settings:
https://docs.rubocop.org/rubocop/cops_layout.html#layoutfirsthashelementindentation
https://docs.rubocop.org/rubocop/cops_layout.html#layoutfirstarrayelementindentation
On 25/12/2022 02:12, Aaron Jensen wrote:
>> We could also discuss cases like
>>
>> foo = bar({
>> tee: 1,
>> qux: 2
>> })
>>
>> baz([
>> 1,
>> 2,
>> 3
>> ])
>>
>> but those would be an orthogonal feature. And I don't see them much in
>> the wild, for some reason.
> The same logic would apply. It doesn't matter how many indent starters
> there are in a line, the indentation should only increase by one:
>
>
> foo = bar({
> tee: 1,
> qux: 2
> })
>
> baz([
> 1,
> 2,
> 3
> ])
>
> Of course, that begs the question what happens if you do this:
>
> baz([
> 1,
> 2,
> 3
> ]
> )
Here are a couple trickier examples:
takes_multi_pairs_hash(x: {
a: 1,
b: 2
})
and_in_a_method_call({
no: :difference
},
foo,
bar)
AFAICT even Rubocop doesn't have a setting which would indent the second
one somewhat reasonably, while keeping two-space indent before "no".
> And, I think again, the answer is a social one, rather than a technical one.
>
> enh-ruby-mode and vim both do this this:
>
> baz([
> 1,
> 2,
> 3
> ]
> )
Yup, that looks pretty bizarre. OTOH, I don't see why a developer would
put a newline between "]" and ")" in this case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sun, 25 Dec 2022 23:47:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 60321 <at> debbugs.gnu.org (full text, mbox):
On Sun, Dec 25, 2022 at 4:30 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> X-Debbugs-CC: aaronjensen <at> gmail.com
>
> Splitting off from debbugs#60186, second try.
>
> Since this setting also seems orthogonal to the "simplified" preference,
> and it'll require some more work.
>
> For future reference, here are the relevant Rubocop settings:
>
> https://docs.rubocop.org/rubocop/cops_layout.html#layoutfirsthashelementindentation
> https://docs.rubocop.org/rubocop/cops_layout.html#layoutfirstarrayelementindentation
>
> On 25/12/2022 02:12, Aaron Jensen wrote:
> >> We could also discuss cases like
> >>
> >> foo = bar({
> >> tee: 1,
> >> qux: 2
> >> })
> >>
> >> baz([
> >> 1,
> >> 2,
> >> 3
> >> ])
> >>
> >> but those would be an orthogonal feature. And I don't see them much in
> >> the wild, for some reason.
> > The same logic would apply. It doesn't matter how many indent starters
> > there are in a line, the indentation should only increase by one:
> >
> >
> > foo = bar({
> > tee: 1,
> > qux: 2
> > })
> >
> > baz([
> > 1,
> > 2,
> > 3
> > ])
> >
> > Of course, that begs the question what happens if you do this:
> >
> > baz([
> > 1,
> > 2,
> > 3
> > ]
> > )
>
> Here are a couple trickier examples:
>
> takes_multi_pairs_hash(x: {
> a: 1,
> b: 2
> })
enh-ruby-mode and vim do the same thing, which I think is fine:
takes_multi_pairs_hash(x: {
a: 1,
b: 2
})
Though again, the best answer imo is "don't do this".
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
enh-ruby-mode:
and_in_a_method_call({
no: :difference
},
foo,
bar)
Vim:
and_in_a_method_call({
no: :difference
},
foo,
bar)
I think this falls under something I wouldn't put too much effort into
fixing. I would write it like this:
and_in_a_method_call(
{
no: :difference
},
foo,
bar
)
Which indents in a straightforward manner.
If I had to type it as above, I would probably indent it like this:
and_in_a_method_call({
no: :difference
},
foo,
bar)
But I can't imagine that would be easy to implement at all, so I
wouldn't bother.
> AFAICT even Rubocop doesn't have a setting which would indent the second
> one somewhat reasonably, while keeping two-space indent before "no".
>
> > And, I think again, the answer is a social one, rather than a technical one.
> >
> > enh-ruby-mode and vim both do this this:
> >
> > baz([
> > 1,
> > 2,
> > 3
> > ]
> > )
>
> Yup, that looks pretty bizarre. OTOH, I don't see why a developer would
> put a newline between "]" and ")" in this case.
Exactly, that's what I meant by a social problem. We have a (somewhat
harsh) saying for stuff like this: you get what you deserve. That's
actually why I don't mind enh-ruby-mode's behavior here. It's clearly
undefined/out of bounds, so that tells a person they are currently out
of bounds and they should get back in bounds.
Aaron
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Tue, 27 Dec 2022 01:17:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 60321 <at> debbugs.gnu.org (full text, mbox):
On 26/12/2022 01:46, Aaron Jensen wrote:
> enh-ruby-mode and vim do the same thing, which I think is fine:
>
> takes_multi_pairs_hash(x: {
> a: 1,
> b: 2
> })
Makes sense to me, I just wanted to keep this case in the bug report
because it will likely need a separate indentation rule or a separate
clause.
>> and_in_a_method_call({
>> no: :difference
>> },
>> foo,
>> bar)
>
> enh-ruby-mode:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
>
> Vim:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
Vim's choice looks saner to my eye. Probably comes down to the choice of
indentation algorithm, though.
> I think this falls under something I wouldn't put too much effort into
> fixing. I would write it like this:
>
> and_in_a_method_call(
> {
> no: :difference
> },
> foo,
> bar
> )
>
> Which indents in a straightforward manner.
Indeed. But this works already, no changes required.
> If I had to type it as above, I would probably indent it like this:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> But I can't imagine that would be easy to implement at all, so I
> wouldn't bother.
The indentation logic itself might be not that difficult to write, but
the fact that the expression will have to be reindented as soon as the
method call grows a second argument (after the user types the comma?),
makes it a hard sell usability-wise.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Tue, 27 Dec 2022 01:39:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 60321 <at> debbugs.gnu.org (full text, mbox):
On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Vim's choice looks saner to my eye. Probably comes down to the choice of
> indentation algorithm, though.
Agreed, though it's hard to pick which is more sane when all the
options start with insanity.
> > If I had to type it as above, I would probably indent it like this:
> >
> > and_in_a_method_call({
> > no: :difference
> > },
> > foo,
> > bar)
> >
> > But I can't imagine that would be easy to implement at all, so I
> > wouldn't bother.
>
> The indentation logic itself might be not that difficult to write, but
> the fact that the expression will have to be reindented as soon as the
> method call grows a second argument (after the user types the comma?),
> makes it a hard sell usability-wise.
Right, I think that's just more of the same thing... We are looking at
ways of writing code that are out of the realm of reason. It's a
challenge to define behavior when the behavior could very well be
undefined. But, if we must define it, then what are our guiding
principles? Not having to reindent preceding lines when adding a new
line may be a very reasonable one. In that case, the only two options
I could think of would be:
and_in_a_method_call({
no: :difference
},
foo,
bar)
or
and_in_a_method_call({
no: :difference
},
foo,
bar)
The difference being if we decide to dedent upon the last closing
indent-requiring-token or the first.
I think a reasonable rule of thumb for a human might be: "If you open
N indents on one line, you must close N indents on one line". Any time
you stray away from this, behavior becomes... not ideal.
Aaron
Forcibly Merged 60321 72099.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 24 Jul 2024 04:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sat, 31 Aug 2024 23:44:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 60321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I made an attempt at this (attached). It introduces a new variable:
ruby-bracketed-args-indent
It is set to t by default and the behavior will be as it was before this
patch.
If it is something other than t, it will cause enable indentation like this:
update({
key => value,
other_key:
}, {
key => value,
other_key:
})
update([
1,
2
], [
3,
4
])
It does not handle cases such as:
some_method({
key: :value
},
other_argument)
It will indent other_argument to be aligned with the (. This could be
elaborated further, but I contend that if people are formatting their code
this way that they likely have rather idiosyncratic formatting requirements
and they would be best left to do what they want manually.
Thanks,
Aaron
On Mon, Dec 26, 2022 at 8:38 PM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Vim's choice looks saner to my eye. Probably comes down to the choice of
> indentation algorithm, though.
>
> Agreed, though it's hard to pick which is more sane when all the options
> start with insanity.
>
> If I had to type it as above, I would probably indent it like this:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> But I can't imagine that would be easy to implement at all, so I wouldn't
> bother.
>
> The indentation logic itself might be not that difficult to write, but the
> fact that the expression will have to be reindented as soon as the method
> call grows a second argument (after the user types the comma?), makes it a
> hard sell usability-wise.
>
> Right, I think that's just more of the same thing... We are looking at
> ways of writing code that are out of the realm of reason. It's a challenge
> to define behavior when the behavior could very well be undefined. But, if
> we must define it, then what are our guiding principles? Not having to
> reindent preceding lines when adding a new line may be a very reasonable
> one. In that case, the only two options I could think of would be:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> or
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> The difference being if we decide to dedent upon the last closing
> indent-requiring-token or the first.
>
> I think a reasonable rule of thumb for a human might be: "If you open N
> indents on one line, you must close N indents on one line". Any time you
> stray away from this, behavior becomes... not ideal.
>
> Aaron
>
[Message part 2 (text/html, inline)]
[0001-Add-ruby-bracketed-argument-indentation-option.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sun, 01 Sep 2024 00:57:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 60321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Updated patch with more precise variables in the new test.
Aaron
On Sat, Aug 31, 2024 at 7:41 PM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> I made an attempt at this (attached). It introduces a new variable:
>
> ruby-bracketed-args-indent
>
> It is set to t by default and the behavior will be as it was before this
> patch.
>
> If it is something other than t, it will cause enable indentation like
> this:
>
> update({
> key => value,
> other_key:
> }, {
> key => value,
> other_key:
> })
>
> update([
> 1,
> 2
> ], [
> 3,
> 4
> ])
>
> It does not handle cases such as:
>
> some_method({
> key: :value
> },
> other_argument)
>
> It will indent other_argument to be aligned with the (. This could be
> elaborated further, but I contend that if people are formatting their code
> this way that they likely have rather idiosyncratic formatting requirements
> and they would be best left to do what they want manually.
>
> Thanks,
>
>
> Aaron
>
>
> On Mon, Dec 26, 2022 at 8:38 PM, Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
> On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Vim's choice looks saner to my eye. Probably comes down to the choice of
> indentation algorithm, though.
>
> Agreed, though it's hard to pick which is more sane when all the options
> start with insanity.
>
> If I had to type it as above, I would probably indent it like this:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> But I can't imagine that would be easy to implement at all, so I wouldn't
> bother.
>
> The indentation logic itself might be not that difficult to write, but the
> fact that the expression will have to be reindented as soon as the method
> call grows a second argument (after the user types the comma?), makes it a
> hard sell usability-wise.
>
> Right, I think that's just more of the same thing... We are looking at
> ways of writing code that are out of the realm of reason. It's a challenge
> to define behavior when the behavior could very well be undefined. But, if
> we must define it, then what are our guiding principles? Not having to
> reindent preceding lines when adding a new line may be a very reasonable
> one. In that case, the only two options I could think of would be:
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> or
>
> and_in_a_method_call({
> no: :difference
> },
> foo,
> bar)
>
> The difference being if we decide to dedent upon the last closing
> indent-requiring-token or the first.
>
> I think a reasonable rule of thumb for a human might be: "If you open N
> indents on one line, you must close N indents on one line". Any time you
> stray away from this, behavior becomes... not ideal.
>
> Aaron
>
>
[Message part 2 (text/html, inline)]
[0001-Add-ruby-bracketed-argument-indentation-option.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sun, 01 Sep 2024 16:38:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 60321 <at> debbugs.gnu.org (full text, mbox):
Hi Aaron!
On 01/09/2024 03:54, Aaron Jensen wrote:
> Updated patch with more precise variables in the new test.
Thanks for taking the initiative.
Here's an example which seems to get worse with the new variable set to nil:
def foo
foo.update(
{
key => value,
other_key: foo
}
)
end
I'd like to flip the default value (now or in Emacs 31), so it would be
great to deal with examples like this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Sun, 01 Sep 2024 19:32:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 60321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Dmitry,
Here's a corrected patch for that particular example. Thank you for finding
that. I think I missed it because as long as you type the code in, it
indents fine. I still have a lot to understand about SMIE, so if anything
looks off in my patch, please let me know.
I didn't change the default. I wasn't sure if you wanted to change the
defaults of all of the variables you added in the last round or just this
one, so I'll let you handle that the way you want to.
Thanks,
Aaron
On Sun, Sep 01, 2024 at 12:36 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> Hi Aaron!
>
> On 01/09/2024 03:54, Aaron Jensen wrote:
>
> Updated patch with more precise variables in the new test.
>
> Thanks for taking the initiative.
>
> Here's an example which seems to get worse with the new variable set to
> nil:
>
> def foo
> foo.update(
> {
> key => value,
> other_key: foo
> }
> )
> end
>
> I'd like to flip the default value (now or in Emacs 31), so it would be
> great to deal with examples like this.
>
[Message part 2 (text/html, inline)]
[0001-Add-ruby-bracketed-argument-indentation-option.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Mon, 02 Sep 2024 00:21:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 60321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/09/2024 22:28, Aaron Jensen wrote:
> Here's a corrected patch for that particular example. Thank you for
> finding that. I think I missed it because as long as you type the code
> in, it indents fine. I still have a lot to understand about SMIE, so if
> anything looks off in my patch, please let me know.
Thanks! Just being thorough. We can add this example to the args-indent
test file, too.
Here's a bonus example which looks off but would be more difficult to
fix (and it's not urgent, given the expression is in mixed styles):
foo([{
a: 2
},
{
b: 3
},
4
])
It would be nice to at least handle the last arg correctly - maybe we'll
just get that supported in the ts mode at some later date.
> I didn't change the default. I wasn't sure if you wanted to change the
> defaults of all of the variables you added in the last round or just
> this one, so I'll let you handle that the way you want to.
Sure. I think we can add this into Emacs 30 too, while the change is off
by default.
A few other things:
* I think the docstring should say "Set it to nil to align to the line
with the open bracket" - it doesn't necessarily align to the beginning
of the statement (seems like a good thing).
* Let's change the first example to this, for less ambiguity?
foo
.update({
key => value,
other_key:
}, {
key => value,
other_key:
})
* Support for the new option in ruby-ts-mode (it's good to have parity).
Could you take the attached patch for a spin? Seems to work here, but
I'd like to have an extra confirmation.
[ruby-ts-bracketed-argument-indentation-option.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Mon, 02 Sep 2024 00:53:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 60321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Sep 1, 2024 at 8:19 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> On 01/09/2024 22:28, Aaron Jensen wrote:
>
> > Here's a corrected patch for that particular example. Thank you for
> > finding that. I think I missed it because as long as you type the code
> > in, it indents fine. I still have a lot to understand about SMIE, so if
> > anything looks off in my patch, please let me know.
>
> Thanks! Just being thorough. We can add this example to the args-indent
> test file, too.
>
> Here's a bonus example which looks off but would be more difficult to
> fix (and it's not urgent, given the expression is in mixed styles):
>
> foo([{
> a: 2
> },
> {
> b: 3
> },
> 4
> ])
Yes, that's connected to the case I mentioned... how do you think it
should be indented? I wonder if it should just be 2 spaces in (rather
than aligned with the opening bracket)
> It would be nice to at least handle the last arg correctly - maybe we'll
> just get that supported in the ts mode at some later date.
>
> > I didn't change the default. I wasn't sure if you wanted to change the
> > defaults of all of the variables you added in the last round or just
> > this one, so I'll let you handle that the way you want to.
>
> Sure. I think we can add this into Emacs 30 too, while the change is off
> by default.
Sounds good.
> A few other things:
>
> * I think the docstring should say "Set it to nil to align to the line
> with the open bracket" - it doesn't necessarily align to the beginning
> of the statement (seems like a good thing).
Good call.
> * Let's change the first example to this, for less ambiguity?
>
> foo
> .update({
> key => value,
> other_key:
> }, {
> key => value,
> other_key:
> })
>
Done
> * Support for the new option in ruby-ts-mode (it's good to have parity).
> Could you take the attached patch for a spin? Seems to work here, but
> I'd like to have an extra confirmation.
I don't have the treesitter stuff installed at the moment, will try
this out shortly.
Thanks,
Aaron
[0001-Add-ruby-bracketed-argument-indentation-option.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Mon, 02 Sep 2024 01:27:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 60321 <at> debbugs.gnu.org (full text, mbox):
On 02/09/2024 03:49, Aaron Jensen wrote:
>> Here's a bonus example which looks off but would be more difficult to
>> fix (and it's not urgent, given the expression is in mixed styles):
>>
>> foo([{
>> a: 2
>> },
>> {
>> b: 3
>> },
>> 4
>> ])
>
> Yes, that's connected to the case I mentioned... how do you think it
> should be indented? I wonder if it should just be 2 spaces in (rather
> than aligned with the opening bracket)
It seems to me that anything other than 0 spaces would look inconsistent
with the first element (the hash), and its closing brace in particular.
Anyway, it's not urgent and like you said in the first message, people
formatting code this way might have other unusual requirements as well.
>> * Support for the new option in ruby-ts-mode (it's good to have parity).
>> Could you take the attached patch for a spin? Seems to work here, but
>> I'd like to have an extra confirmation.
>
> I don't have the treesitter stuff installed at the moment, will try
> this out shortly.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Mon, 02 Sep 2024 02:11:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 60321 <at> debbugs.gnu.org (full text, mbox):
> It seems to me that anything other than 0 spaces would look inconsistent
> with the first element (the hash), and its closing brace in particular.
Yeah, that's my sense as well, even if it looks awful, but you get what you get.
> >> * Support for the new option in ruby-ts-mode (it's good to have parity).
> >> Could you take the attached patch for a spin? Seems to work here, but
> >> I'd like to have an extra confirmation.
> >
> > I don't have the treesitter stuff installed at the moment, will try
> > this out shortly.
>
> Thanks in advance.
I installed it and gave it a run on a few things. I didn't observe any
issues with it.
Aaron
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
You have taken responsibility.
(Mon, 02 Sep 2024 19:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
bug acknowledged by developer.
(Mon, 02 Sep 2024 19:03:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 60321-done <at> debbugs.gnu.org (full text, mbox):
On 02/09/2024 04:56, Aaron Jensen wrote:
>> It seems to me that anything other than 0 spaces would look inconsistent
>> with the first element (the hash), and its closing brace in particular.
> Yeah, that's my sense as well, even if it looks awful, but you get what you get.
>
>>>> * Support for the new option in ruby-ts-mode (it's good to have parity).
>>>> Could you take the attached patch for a spin? Seems to work here, but
>>>> I'd like to have an extra confirmation.
>>> I don't have the treesitter stuff installed at the moment, will try
>>> this out shortly.
>> Thanks in advance.
> I installed it and gave it a run on a few things. I didn't observe any
> issues with it.
Great!
I've pushed both patches to emacs-30 (6c15b7710d4 and 24f12bdd77e) and
now marking the issue as done. Thanks again for the patch.
To summarize for future readers: the default behavior doesn't change -
at least not now - you need to customize the option for different
indentation.
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
You have taken responsibility.
(Mon, 02 Sep 2024 19:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Aaron Jensen <aaronjensen <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 02 Sep 2024 19:03:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60321
; Package
emacs
.
(Mon, 02 Sep 2024 19:24:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 60321-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you, and thanks for your help.
Aaron
On Mon, Sep 2 2024 at 3:01 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 02/09/2024 04:56, Aaron Jensen wrote:
>
> It seems to me that anything other than 0 spaces would look inconsistent
> with the first element (the hash), and its closing brace in particular.
>
> Yeah, that's my sense as well, even if it looks awful, but you get what
> you get.
>
> * Support for the new option in ruby-ts-mode (it's good to have parity).
> Could you take the attached patch for a spin? Seems to work here, but I'd
> like to have an extra confirmation.
>
> I don't have the treesitter stuff installed at the moment, will try this
> out shortly.
>
> Thanks in advance.
>
> I installed it and gave it a run on a few things. I didn't observe any
> issues with it.
>
> Great!
>
> I've pushed both patches to emacs-30 (6c15b7710d4 and 24f12bdd77e) and now
> marking the issue as done. Thanks again for the patch.
>
> To summarize for future readers: the default behavior doesn't change - at
> least not now - you need to customize the option for different indentation.
>
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 02 Oct 2024 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 162 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.