GNU bug report logs - #6286
Ruby Mode Missing Syntax

Previous Next

Full log

Message #27 received at 6286 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6286 <at> debbugs.gnu.org
Subject: Re: General delimited literals in ruby-mode patch
Date: Sun, 29 Apr 2012 00:20:24 +0400

[Message part 1 (text/plain, inline)]

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"; =
>      /toto;
>
> 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.

[0001-lisp-progmodes-ruby-mode.el-Don-t-propertize-percent.patch (text/plain, attachment)]

[0002-lisp-progmodes-ruby-mode.el-Go-back-to-method-whitel.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.