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

[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: Stefan Monnier
Subject: bug#15594: trunk r114639: * lisp/progmodes/ruby-mode.el (ruby-smie-grammar): Add rule for paren-free
Date: Mon, 14 Oct 2013 23:31:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> No, space is significant(++),

I guess we're lucky.

> 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.

> How would that look?
> (unless (member (save-excursion (ruby-smie--forward-token) '("]" "}" "end"
> "+" "-" "?" ":" ...)))

(looking-at "\\s)\\|\\s.") ?

> 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"?

Calling ruby-smie--forward-token is a bit dangerous since that function
might itself be called from ruby-smie--forward-token.  It might work,
but you'll have to think hard about why an inf-loop is not possible.

> 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

Please add this URL in a comment somewhere near ruby-smie-grammar (for
example).

>> +# 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.

Getting `foo' and `bar' aligned is just a matter of adding && to the set
of infix operators (i.e. completing the table of infix operators).
Getting `bar' to be indented one more than `foo' here but not in other
cases of "foo && \n bar" would require more work.


        Stefan





reply via email to

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