Re: Small improvements to ruby-mode

[Bozhidar Batsov <bozhidar@batsov.com>]

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]



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

[-- Attachment #2: Type: text/html, Size: 5489 bytes --]