From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16811-done@debbugs.gnu.org, Bozhidar Batsov <bozhidar@batsov.com>
Subject: bug#16811: 24.3.50; [ruby-mode] Implicit hash indentation bug
Date: Sun, 23 Feb 2014 07:55:37 +0200 [thread overview]
Message-ID: <53098D59.1000007@yandex.ru> (raw)
In-Reply-To: <jwvk3cpnakx.fsf-monnier+emacsbugs@gnu.org>
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
}
prev parent reply other threads:[~2014-02-23 5:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 17:44 bug#16811: 24.3.50; [ruby-mode] Implicit hash indentation bug Bozhidar Batsov
2014-02-20 6:22 ` Dmitry Gutov
2014-02-20 14:11 ` Stefan Monnier
2014-02-23 5:55 ` Dmitry Gutov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53098D59.1000007@yandex.ru \
--to=dgutov@yandex.ru \
--cc=16811-done@debbugs.gnu.org \
--cc=bozhidar@batsov.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.