bug#17057: 24.3.50; [ruby-mode] Font-locking of special global variables like $$ is broken(missing)

[Bozhidar Batsov <bozhidar@batsov.com>]

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

On Friday, March 21, 2014 at 4:53 PM, Bozhidar Batsov wrote:
> On Friday, March 21, 2014 at 4:47 PM, Dmitry Gutov wrote:
> > Bozhidar Batsov <bozhidar@batsov.com (mailto:bozhidar@batsov.com)> writes:
> >  
> > > Here's a few examples:
> > >  
> > > "this is #$$"
> > >  
> > > var = $!
> > >  
> > > Things are different for:
> > >  
> > > "this is #$1"
> > >  
> > > var = $1
> >  
> > Have you tried it in the latest Emacs? For me, only one example
> >  
> > "this is #$$"
> >  
> > is not highlighted (I'll fix that).
> >  
> > > There's another thing to consider - do built-in global vars should be
> > > font-locked like built-ins or like the other (user-defined) global
> > > variables? Personally I'd font-lock them as built-in to underline their
> > > significance.
> > >  
> >  
> >  
> > Hmmm, maybe. But we also highlight nil, self, true, false, __LINE__,
> > __ENCODING__ and __FILE__ with font-lock-variable-name-face. Should we
> > change these, too?
> >  
> >  
> >  
>  
> Technically speaking all of those are keywords, not variables. Somewhat odd __LINE__ and friends are  
> treated at string literals by the Ruby parser. As all of those evaluate to some value unlike most other keywords I guess it makes some sense to font-lock them as variables, but I’d prefer if we used font-locking that makes their special status more apparent.  
>  
>  

There’s one more thing to consider - the special variables aliases defined in `English`. Those are considered de facto built-in (and are actually built-in in some implementations like JRuby; will probably be available out-of-the-box in MRI 3 as well), so I’d suggest treating them the same way as vars like $$, etc.  

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