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

Previous Next

Full log

Message #11 received at 17057 <at> debbugs.gnu.org (full text, mbox):

From: Bozhidar Batsov <bozhidar <at> batsov.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 17057 <at> debbugs.gnu.org
Subject: Re: bug#17057: 24.3.50; [ruby-mode] Font-locking of special
 global variables like $$ is broken(missing)
Date: Fri, 21 Mar 2014 16:53:08 +0200

[Message part 1 (text/plain, inline)]

On Friday, March 21, 2014 at 4:47 PM, Dmitry Gutov wrote:
> Bozhidar Batsov <bozhidar <at> batsov.com (mailto:bozhidar <at> 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.  

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.