[Top][All Lists]

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

bug#6286: General delimited literals in ruby-mode patch

From: Dmitry Gutov
Subject: bug#6286: General delimited literals in ruby-mode patch
Date: Sun, 29 Apr 2012 00:20:24 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0

On 25.04.2012 22:00, Stefan Monnier wrote:
So could it be refined so as to check for a "%" char?  I.e. instead of
removing the old (not (eq ?/ c)), replace it with (not (memq c '(?/ ?%)))?
No, 'c' here is the char at the end of the previous line (see comment above
"let"), and the closing delimiter can be any punctuation char.

OK, then I don't understand what the code used to do.  That's OK, I have
plenty of better things to do anyway ;-)

AFAIU, it was just an optimization. '/' was the only binary operator to have double syntactic meaning. If c is not it, we definitely have continued expression, and can skip checking parse status.

x = toto / foo if /do
bar/ =~ "dobar" # Shortened version.
still has the exact same problem.
Yes.  But let's face it, seeing this code in the wild is not very likely.

You might be right.

And it's as easy to change as // ->  %r//.

I'm not sure what change you're referring to: how should I change the
above code to make it unambiguous that the first / is a division rather
than a regexp?

You would move the whole regexp to the next line, or (if the constraint I suggested is in place) replace the line break with "\n":

x == toto / foo if /do\nbar/ =~ "dobar"

Anyway, the second patch does away this this approach.

Or is it also linked to the presence of a preceding space?  That might
not be so bad, then.  E.g. " / " is division but "/ ", " /", and "/"
is regexp.
The lack of preceding space can turn a regexp into division, but not the
other way around.

So you're saying that " / ", "/", and "/ " are for division, whereas " /"
is for regexps?

Yes, though not without exceptions. "if / boo /" and "if/boo/" are both considered to contain regexps. As well as "/ boo /" when not after a word. The algorithm is likely more complex, I'm just describing how it works with specific examples.

That's one more reason to do this just like TextMate, though.

You mean because the problem can be fixed on the user's side without
changing the Ruby code?  Yes, that's a clear advantage, especially when
browsing other people's code.

If TextMate bundles are easily editable by user, I don't know about that (they might be). I just meant that having the same level of syntax support across editors is a good thing. So that if you have resort to %r//, it's the same for the other team members. And vice versa.

I'm speaking mostly hypothetically, but the percent literals patch is in fact indirect result of my colleague using this syntax in TextMate, with unclosed paren inside.

I'm not exactly sure why, but percent literal starting within a comment is
already (not) propertized as expected.

Not in all cases:

    x #= "tot %q/to"; =

now add&remove a space on the second line; then do the same on the
first line.
The approach I suggested is based on years of experience ;-)

I wasn't arguing against the approach, just making an observation. :)
But it's always good to have a counter-example.

I did something close to what you described (patch 0001), but it didn't seem proper to call the same function in two different situations (before search and after search when we already have match data), so there's still two of them.

Attachment: 0001-lisp-progmodes-ruby-mode.el-Don-t-propertize-percent.patch
Description: Text document

Attachment: 0002-lisp-progmodes-ruby-mode.el-Go-back-to-method-whitel.patch
Description: Text document

reply via email to

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