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:02:10 +0200 Message-ID: References: <87bnwzwqu8.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="532d5fa2_94211f2_fda4" X-Trace: ger.gmane.org 1395482588 31191 80.91.229.3 (22 Mar 2014 10:03:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 10:03:08 +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:03:17 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 1WRIlo-0007L9-S9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Mar 2014 11:03:17 +0100 Original-Received: from localhost ([::1]:56324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIlo-0005Ki-Ej for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Mar 2014 06:03:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIlg-0005Iy-4u for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:03:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRIla-0000dQ-Eb for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:03:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRIla-0000dM-BF for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WRIlZ-0006pB-RV for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2014 06:03:02 -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:03: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.139548253826173 (code B ref 17057); Sat, 22 Mar 2014 10:03:01 +0000 Original-Received: (at 17057) by debbugs.gnu.org; 22 Mar 2014 10:02:18 +0000 Original-Received: from localhost ([127.0.0.1]:44191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WRIkr-0006o4-JW for submit@debbugs.gnu.org; Sat, 22 Mar 2014 06:02:18 -0400 Original-Received: from mail-ee0-f51.google.com ([74.125.83.51]:62697) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WRIkp-0006nv-Au for 17057@debbugs.gnu.org; Sat, 22 Mar 2014 06:02:16 -0400 Original-Received: by mail-ee0-f51.google.com with SMTP id c13so2608455eek.24 for <17057@debbugs.gnu.org>; Sat, 22 Mar 2014 03:02:14 -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=1GEDBoyzBCWhYEmOm6WMv6ioVVEMmjZ4tXAarF5fQ/I=; b=n5VZTMAAw1l40emQcBMY4V7SOJVJ09sCVhhzw02nEn0gC3DjvA76k91+KAllnxeIAj yUeWDt2jDqOwq/CTr4YKPNUPLjLE+9nYrq3gZkG2uYZma6Q9bMThrPGNZATOIKaIEDHG pQta5DkL3mt0GqL94fWZSXB1vw7ol9HWoALvuszj6CD2m+S7YwBZVUs/5GBPukc7MRYs BLtOlvA4IdOtzCOno5J7+XkgVdJJnuJqxYyFCQmfElzGgcpjyOYEBoD8fuonU4Z65l/p oA0tMc21+NXH4jf4O8S3VIQEqe1a+t8UdOPqd0iXJ2hHzSGOyzCp2qpCRS8V/cpbCCoC 7BWg== X-Received: by 10.14.7.65 with SMTP id 41mr876724eeo.100.1395482534437; Sat, 22 Mar 2014 03:02:14 -0700 (PDT) Original-Received: from [192.168.1.28] ([95.87.231.111]) by mx.google.com with ESMTPSA id 48sm17847749eee.2.2014.03.22.03.02.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 22 Mar 2014 03:02:13 -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:87144 Archived-At: --532d5fa2_94211f2_fda4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 > > > 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. > > > =20 > > =20 > > =20 > > Hmmm, maybe. But we also highlight nil, self, true, false, =5F=5FLINE= =5F=5F, > > =5F=5FENCODING=5F=5F and =5F=5F=46ILE=5F=5F with font-lock-variable-n= ame-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 and friends are =20 > 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=E2=80=99d prefer if we used font-locki= ng that makes their special status more apparent. =20 > =20 > =20 There=E2=80=99s one more thing to consider - the special variables aliase= s defined in =60English=60. Those are considered de facto built-in (and a= re 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 treat= ing them the same way as vars like =24=24, etc. =20 --532d5fa2_94211f2_fda4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
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).

There's another thing to consider - do built-in global vars should be<= /div>
font-locked like built-ins or like the other (user-defined) glo= bal
variables=3F Personally I'd font-lock them as built-in to u= nderline their
significance.

<= /div>
Hmmm, maybe. But we also highlight nil, self, true, false, =5F=5F= LINE=5F=5F,
=5F=5FENCODING=5F=5F and =5F=5F=46ILE=5F=5F with fo= nt-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 =20
There=E2=80=99s one = more thing to consider - the special variables aliases defined in =60Engl= ish=60. Those are considered de facto built-in (and are actually built-in= in some implementations like JRuby; will probably be available out-of-th= e-box in MRI 3 as well), so I=E2=80=99d suggest treating them the same wa= y as vars like =24=24, etc. 
--532d5fa2_94211f2_fda4--