Re: Small improvements to ruby-mode

[Bozhidar Batsov]

-- 

Cheers,

Bozhidar

On Saturday, June 22, 2013 at 4:28 PM, Dmitry Gutov wrote:

On 22.06.2013 11:05, Bozhidar Batsov wrote:

Should we add more, e.g. include,

attr_accessor, using, refine?

Yes, I think we should definitely add more. The ones you listed - for

sure. We should also add fail (it's a synonym for raise), extend, etc.

Btw catch is also a method, not a keyword. loop should also be on the

second list, as should be proc and lambda IMO.

Ok, also done (except for etc :)), together with other attr* methods,

and define_method.

Great! Btw, I now noticed that 'load' is missing from the list. I think that __dir__, __method__ and __callee__ should also be on the list.

I'd also suggest adding the "command-like" methods for Kernel that are

usually used without an explicit receiver everywhere. There's not that

many such commands:

abort

at_exit

eval

exec

exit

exit!

fail

fork

format

p

print

printf

putc

puts

rand

sleep

spawn

sprintf

srand

syscall

system

trap

warn

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.

On a somewhat related matter - I've noticed that in the Ruby spec BEGIN, END, __LINE__, __ENCODING__ and __FILE__ are keywords as well. ruby-mode should highlight them accordingly. 

I'm not so sure about re-implementing it, though. It's easy enough to

install in its current form, no?

Sure - my point is that not all Emacs users would know about the

package. I'd venture a guess saying most of them won't. The

functionality in it seems a perfect fit for ruby-mode. Even if it has to

be reimplemented - we're talking about a only a handful of not

particularly complex commands.

Patches welcome. :)

Personally, I haven't found myself using ruby-tools too often:

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 :-) There are other useful commands there for toggling between a symbol and string and blanking strings at point. The toggling between string and symbol is pretty useful.

2) Automatic insertion of curly braces after "#" in strings is annoying

when you're actually trying to type "#", for example when writing a

method signature. I also disagree with "don't leave out {} around

instance and global variables".

But as optional commands with less invasive bindings ("C-c #"?), they

would be fine.

Yep, I dislike the current behavior as well. Having it bound to a command that should be invoked manually would be much better indeed.

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.