Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 23.06.2013 10:20, Bozhidar Batsov wrote:
> > I'm less sure about these. Every method on Kernel is usually called
> > without an explicit receiver, and there are more of them.
> > Let's wait for another opinion.
> There are more of them, but most of them exist only when ruby is invoked
> with -n/-p (for perl-like scripting) - normally chomp, chomp!, chop, etc
> are not bound, which means we should not add them to the built-in list,
> since nobody is actually wring Ruby applications using them. Matz
> himself recommends that all the command-like methods from Kernel be
> treated as reserved words - meaning it's considered a bad idea for
> someone to introduce variables or methods named this way. If they were
> highlighted properly fewer developers would fail to recognize their
> "special" status. Looking at the Kernel module's docs there are less
> than 30 such commands and they've barely changed in recent years.

That makes sense, but should we highlight them the same way as 
keyword-like methods (which I've roughly defined for myself as stuff 
having to do with control flow, code generation and loading)?

> > 1) I don't subscribe to your principle of single quotes vs. double
> > quotes. So, when I'm adding an interpolation to a string, it's usually
> > double-quoted already.
> It's not exactly my principle :-)

Well, it's in the style guide you're maintaining, and I haven't seen 
this exact phrasing elsewhere, IIRC. And there are enough popular 
projects that contradict or ignore it.

> The toggling between string and symbol is pretty useful.

Yes, I could've used it myself just the other day. It's not something I 
do too often either, though.

> Btw, Dmitry, I noticed something strange about ruby-mode (at least in
> 24.3) - the calculations for method and block boundaries seem to be off.
> I'm not sure if you're aware of the problem or you need a more detailed
> report.

Not exactly sure what you mean, so yes, more details would be helpful. 
But please try the current trunk first.