From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.bugs Subject: bug#17057: 24.3.50; [ruby-mode] Font-locking of special global variables like $$ is broken(missing) Date: Sat, 22 Mar 2014 12:05:42 +0200 Message-ID: References: <87bnwzwqu8.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="532d6076_43f18422_fda4" X-Trace: ger.gmane.org 1395482772 32744 80.91.229.3 (22 Mar 2014 10:06:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 10:06:12 +0000 (UTC) Cc: 17057@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 22 11:06:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WRIoj-00024Y-F4 for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Mar 2014 11:06:17 +0100 Original-Received: from localhost ([::1]:56332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIoi-0006bb-Ss for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Mar 2014 06:06:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIoa-0006Vn-53 for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:06:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRIoU-0001ch-Eq for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:06:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIoU-0001cW-A4 for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WRIoT-0006uD-Kq for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bozhidar Batsov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Mar 2014 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17057 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17057-submit@debbugs.gnu.org id=B17057.139548274926524 (code B ref 17057); Sat, 22 Mar 2014 10:06:01 +0000 Original-Received: (at 17057) by debbugs.gnu.org; 22 Mar 2014 10:05:49 +0000 Original-Received: from localhost ([127.0.0.1]:44195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WRIoG-0006ti-Rk for submit@debbugs.gnu.org; Sat, 22 Mar 2014 06:05:49 -0400 Original-Received: from mail-ee0-f54.google.com ([74.125.83.54]:63497) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WRIoE-0006ta-SO for 17057@debbugs.gnu.org; Sat, 22 Mar 2014 06:05:47 -0400 Original-Received: by mail-ee0-f54.google.com with SMTP id d49so2609150eek.41 for <17057@debbugs.gnu.org>; Sat, 22 Mar 2014 03:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=umClmIyi2tnv04k3YHdw1iTCxUFRBeeys9c3/a7p0Yc=; b=JY9bAkDX15YuBpTguqjxQMh6FOJfrxFj+z4dro2lCbZkP6+ommRjYKibiTUWsA4XvC PpRo5KdAwlPi2H5hnjpHFr6Am+4xtaDyGkdh5qV7hGwAGqJgZO9fg9BbIq86rQ6D+JE0 l/qO800nx/7jVHw5gzLwOuoofTyKW/ERi9CsgkGS3XMhPmilN+ewilSPkMN2xy4xl5OY tMd19qQLGjIqH3DNWcj6E+7OOkqQSwv7pMCZmDsAAEJ0TQhjwz99kCLMa2ViVVR0j9Wd 9ADZhMDGZHelukQaeE75Qrk5c0ot6G1/ZO0Htu0Fp4KweCcF7LK2Cdm+3tIKFBdAiX0p j5Fw== X-Received: by 10.14.111.66 with SMTP id v42mr17732eeg.107.1395482746016; Sat, 22 Mar 2014 03:05:46 -0700 (PDT) Original-Received: from [192.168.1.28] ([95.87.231.111]) by mx.google.com with ESMTPSA id f45sm17864082eeg.5.2014.03.22.03.05.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 22 Mar 2014 03:05:45 -0700 (PDT) In-Reply-To: X-Mailer: sparrow 1.6.4 (build 1178) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:87145 Archived-At: --532d6076_43f18422_fda4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday, March 22, 2014 at 12:02 PM, Bozhidar Batsov wrote: > On =46riday, March 21, 2014 at 4:53 PM, Bozhidar Batsov wrote: > > On =46riday, March 21, 2014 at 4:47 PM, Dmitry Gutov wrote: > > > Bozhidar Batsov writes: > > > =20 > > > > Here's a few examples: > > > > =20 > > > > =22this is =23=24=24=22 > > > > =20 > > > > var =3D =24=21 > > > > =20 > > > > Things are different for: > > > > =20 > > > > =22this is =23=241=22 > > > > =20 > > > > var =3D =241 > > > =20 > > > Have you tried it in the latest Emacs=3F =46or me, only one example= > > > =20 > > > =22this is =23=24=24=22 > > > =20 > > > is not highlighted (I'll fix that). > > > =20 =241 gets font-locked immediately, but =24=24 currently gets font-locked = only after some =E2=80=9Cword-boundary=E2=80=9D character gets inserted (= like space, newline, etc). =20 > > > =20 > > > > There's another thing to consider - do built-in global vars shoul= d be > > > > font-locked like built-ins or like the other (user-defined) globa= l > > > > variables=3F Personally I'd font-lock them as built-in to underli= ne their > > > > significance. > > > > =20 > > > =20 > > > =20 > > > Hmmm, maybe. But we also highlight nil, self, true, false, =5F=5FLI= NE=5F=5F, > > > =5F=5FENCODING=5F=5F and =5F=5F=46ILE=5F=5F with font-lock-variable= -name-face. Should we > > > change these, too=3F > > > =20 > > > =20 > > > =20 > > =20 > > Technically speaking all of those are keywords, not variables. Somewh= at odd =5F=5FLINE=5F=5F and friends are =20 > > treated at string literals by the Ruby parser. As all of those evalua= te to some value unlike most other keywords I guess it makes some sense t= o font-lock them as variables, but I=E2=80=99d prefer if we used font-loc= king that makes their special status more apparent. =20 > > =20 > > =20 > > =20 > =20 > There=E2=80=99s one more thing to consider - the special variables alia= ses defined in =60English=60. 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=E2=80=99d suggest tre= ating them the same way as vars like =24=24, etc. =20 > =20 > =20 --532d6076_43f18422_fda4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Sa= turday, March 22, 2014 at 12:02 PM, Bozhidar Batsov wrote:
On =46= riday, March 21, 2014 at 4:53 PM, Bozhidar Batsov wrote:
On =46= riday, March 21, 2014 at 4:47 PM, Dmitry Gutov wrote:
Bozhidar Batsov <bozhidar=40batsov.com> writes:

Here's a few exa= mples:

=22this is =23=24=24=22

var =3D =24=21

Things are different for:=

=22this is =23=241=22

= var =3D =241

Have you tried i= t in the latest Emacs=3F =46or me, only one example

<= div>=22this is =23=24=24=22

is not highlighted (= I'll fix that).

=241 gets font-locked immediately, but= =24=24 currently gets font-locked only after some =E2=80=9Cword-bou= ndary=E2=80=9D character gets inserted (like space, newline, etc).=  
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=3F Personally I'd font-lock them as built-in = to underline their
significance.
<= br>
Hmmm, maybe. But we also highlight nil, self, true, false, = =5F=5FLINE=5F=5F,
=5F=5FENCODING=5F=5F and =5F=5F=46ILE=5F=5F w= ith font-lock-variable-name-face. Should we
change these, too=3F=
=20 =20 =20 =20
Technically speaking = all of those are keywords, not variables. Somewhat odd =5F=5FLINE=5F=5F a= nd friends are
treated at str= ing literals by the Ruby parser. As all of those evaluate to some value u= nlike most other keywords I guess it makes some sense to font-lock them a= s variables, but I=E2=80=99d prefer if we used font-locking that makes th= eir special status more apparent. 
 =20 =20 =20 =20
T= here=E2=80=99s one more thing to consider - the special variables aliases= defined in =60English=60. Those are considered de facto built-in (and ar= e actually built-in in some implementations like JRuby; will probably be = available out-of-the-box in MRI 3 as well), so I=E2=80=99d suggest treati= ng them the same way as vars like =24=24, etc. 
=20 =20 =20 =20 =20

--532d6076_43f18422_fda4--