On Saturday, February 1, 2014 at 5:19 PM, Dmitry Gutov wrote:
> Bozhidar Batsov <bozhidar@batsov.com (mailto:bozhidar@batsov.com)> writes:
>  
> > In the following snippet `format` is font-locked as the built-in
> > function, but it's actually a variable.
> >  
> > respond_to do |format|
> > format.json do
> > # ...
> > end
> > end
> >  
> > This problem obviously exists for all built-ins, but it's not a big
> > issue in general, since most of them don't have names that are likely to
> > be used as variable names. Not sure if we can have a simple solution for
> > this problem without a parser, though. I guess we can have a check if
> > the built-in methods have arguments (as most of them have).
> >  
>  
>  
> A lot of them don't, though (or have no required arguments): __callee__,
> __dir__, __method__, binding, caller, block_given?, exit, exit!, raise,
> (s)rand, readline(s), sleep.
>  
> Guess we can separate these, and for all others, check if they're
> followed by " *[]|,.)}]\\|$".
>  
>  

Separating the methods sounds reasonable. Variables can’t end with ?, so block_given? is always clear. Same goes for exit!. Pretty sure no one will ever name a var __xxx__. `binding` & `caller` seem the most likely names in the list to cause a problem like `format`, since they’d be good variable names (at least in code making use of metaprogramming).