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

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

bug#16811: 24.3.50; [ruby-mode] Implicit hash indentation bug


From: Dmitry Gutov
Subject: bug#16811: 24.3.50; [ruby-mode] Implicit hash indentation bug
Date: Sun, 23 Feb 2014 07:55:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 20.02.2014 16:11, Stefan Monnier wrote:
The problem seems to be that (let (smie--parent) (smie-indent--parent))

Which does little more than (smie-backward-sexp 'halfsexp) in this case.

Yes.

called between "=>" and "{" doesn't stop at "=>", but goes straight to
the parent "{".

Which seems correct.

Maybe according to the current grammar. But not if we want expressions after `=>' to have consistent additional indentation. Which I'm now thinking we probably don't, since otherwise, if it works right,

     {
       'HashSyntax' => {
         'EnforcedStyle'   => 'ruby19',
         'SupportedStyles' => %w(ruby19 hash_rockets)
       },

would turn into

     {
       'HashSyntax' => {
           'EnforcedStyle'   => 'ruby19',
           'SupportedStyles' => %w(ruby19 hash_rockets)
         },

and that doesn't look good. So indenting the left and right sides of `=>' to the same level is probably the way to go.

Changed in revision 116534, fixing this bug.

Thanks for the questions!

This said, I don't understand why

    {
      'HashSyntax' => {
        'EnforcedStyle'   => 'ruby19',
        'SupportedStyles' => %w(ruby19 hash_rockets)
      },
      'SpaceAroundOperators' => { 'Enabled' => true }
    }

is indented differently from

    {'HashSyntax' => {
                      'EnforcedStyle'   => 'ruby19',
                      'SupportedStyles' => %w(ruby19 hash_rockets)
                    },
     'SpaceAroundOperators' => {
       'Enabled' => true }}
>
It seems like "it jumps back to { instead of =>" is not the full explanation.

That's because we always insert an implicit semicolon after { at eol, and that's because it's hard to distinguish between a curly that's opening a hash and a curly than opens a curly block.

And we need those after block-opening curlies, otherwise some token on the first line of the block might consider the curly as its parent, align to it, and block-opening curlies themselves align to the beginning of the statement.

So

it("is too!") {
  bar
    .qux
}

turns into

it("is too!") {
  bar
  .qux
}





reply via email to

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