[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15594: trunk r114639: * lisp/progmodes/ruby-mode.el (ruby-smie-gramm
From: |
Dmitry Gutov |
Subject: |
bug#15594: trunk r114639: * lisp/progmodes/ruby-mode.el (ruby-smie-grammar): Add rule for paren-free |
Date: |
Tue, 15 Oct 2013 04:23:50 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
On 14.10.2013 16:44, Stefan Monnier wrote:
So basically, I think we'd like to check if the token following POS is
either not "special", or if it is, it begins an expression. Can we do
that?
...(+) But it'll be more difficult to handle
...(++)
since there's no space to use as "implicit method call infix operator".
No, space is significant(++), I'm not suggesting to revert the addition
of the " @ " token. But we need a better predicate in
`ruby-smie--args-separator-p' to check that the thing after POS is
probably an argument. "Starts with a word character" is too narrow.
> (+) I don't see anything that would stop us.
How would that look?
(unless (member (save-excursion (ruby-smie--forward-token) '("]" "}"
"end" "+" "-" "?" ":" ...)))
?
Can we extract the "prohibited" list from the already defined grammar?
Or should the check be more like "is the next token in
`ruby-smie-grammar', and if yes, is its left priority more than ' @ 's
right priority"?
(++)
> method(arg1),
> arg2
> or
> method{arg1},
> arg2
>
Both examples would result in syntax errors. The second one doubly so,
since the first arg there is not a hash, but a block, and a block can
only come after all other arguments.
Even if the first argument were {:a => 1, :b => 2}, actually, it won't
work because "{" in this position is parsed as the beginning of a block
(that means one of the examples I added is wrong, sorry!).
You've probably already found this, but on the off chance you haven't,
here's its syntax in (incomplete, somewhat outdated, etc) BNF form:
http://www.cse.buffalo.edu/~regan/cse305/RubyBNF.pdf
+# Shouldn't "bar" be aligned with "foo"? --Stef
if foo &&
bar
end
Maybe. Either option would be better than the current behavior. I've
picked this one because the old engine indents it like so, and
additional indentation of 2 (compared to the if body) would likely be
more useful that 1, when reading the code.
+# Shouldn't "arg2" be aligned with "!" rather than with "arg1"? --Stef
method !arg1,
arg2
Yes, sorry. Fixed, and added a couple of new examples, like usual.