Stefan Kangas <stefan@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 15219) by debbugs.gnu.org; 30 Oct 2019 13:30:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 30 09:30:28 2019 Received: from localhost ([127.0.0.1]:49516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iPo3Q-0003BB-GL for submit <at> debbugs.gnu.org; Wed, 30 Oct 2019 09:30:28 -0400 Received: from quimby.gnus.org ([80.91.231.51]:56436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1iPo3J-0003Av-K7 for 15219 <at> debbugs.gnu.org; Wed, 30 Oct 2019 09:30:24 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <larsi@HIDDEN>) id 1iPo3E-0006en-1t; Wed, 30 Oct 2019 14:30:18 +0100 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Bozhidar Batsov <bozhidar.batsov@HIDDEN> Subject: Re: bug#15219: Emacs Lisp mode and Lisp mode font-locking References: <FA68F294BF5F4BF598190F14B70E82DC@HIDDEN> <jwv1u5bwe10.fsf-monnier+emacs@HIDDEN> <0103F5523929438C99A2AF40E0ADA510@HIDDEN> Date: Wed, 30 Oct 2019 14:30:15 +0100 In-Reply-To: <0103F5523929438C99A2AF40E0ADA510@HIDDEN> (Bozhidar Batsov's message of "Fri, 30 Aug 2013 16:23:37 +0300") Message-ID: <87eeyuuzrs.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Bozhidar Batsov <bozhidar.batsov@HIDDEN> writes: > Anyways, I'd be happy to get just a fix for the keywords and &optional (and > related) faces, since those are definitely off. The complaint is that :foobar below uses font-lock-builtin-face and &optional uses font-lock-type-face in emacs-lisp-mode. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15219 Cc: Stefan Monnier <monnier@HIDDEN>, 15219 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Bozhidar Batsov <bozhidar.batsov@HIDDEN> writes: > Anyways, I'd be happy to get just a fix for the keywords and &optional (and > related) faces, since those are definitely off. The complaint is that :foobar below uses font-lock-builtin-face and &optional uses font-lock-type-face in emacs-lisp-mode. (defun foo (bar &optional zot) (list :foobar bar)) This is defined in lisp-cl-font-lock-keywords in lisp-mode.el, and I agree that separate faces should probably be used for those -- keywords aren't builtins and &optional isn't a type. :keywords are constants, I guess, but we use font-lock-constant-face for catch/throw and the like, and I don't think we have anything that vaguely makes sense for &optional. Would adding new faces for these make sense? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug-gnu-emacs@HIDDEN:bug#15219; Package emacs.
Full text available.
Received: (at 15219) by debbugs.gnu.org; 30 Aug 2013 13:23:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 30 09:23:43 2013
Received: from localhost ([127.0.0.1]:58892 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFOfu-0002GA-MQ
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 09:23:43 -0400
Received: from mail-ee0-f50.google.com ([74.125.83.50]:65000)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFOfs-0002Fu-05
for 15219 <at> debbugs.gnu.org; Fri, 30 Aug 2013 09:23:40 -0400
Received: by mail-ee0-f50.google.com with SMTP id d51so901705eek.23
for <15219 <at> debbugs.gnu.org>; Fri, 30 Aug 2013 06:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:from:to:cc:message-id:in-reply-to:references:subject
:mime-version:content-type;
bh=15U9fgx8U+LCxowR/fh8NVm4G8l3S/jGXxkMYj5jXKQ=;
b=sljQwA2zxM34SuDr5/k+AwoYTFgYK2PzH+mB4T4NanIHo17GIjFknf4M+XuXAoORgo
ORHjXMs4SzkLMyfZ4gOB8r6LO2CPNT0VLwfcqDtrMKR9jovMSoUGDOpS0+dfNhsii+yH
4jv9fKCW6iQDmxTHqwkQ6MN+3Zxf8MlSpf5C7ocnJwRZrS6b/xcT5Y0zxqVRx8i/z9eY
cFz5pshuo3fz4oXsjc77CLeAwZBGZit/jD7S37dBp3gezSddV3GqF5Iq7FgnJl5U4Nby
xwc4OxCXoabhXJcNqOFcS5PP+GfDIklQFumDK5TAZysE+KB3MEYtkwvpXWI8wxnK9B9K
AQNg==
X-Received: by 10.14.183.130 with SMTP id q2mr12893773eem.5.1377869014011;
Fri, 30 Aug 2013 06:23:34 -0700 (PDT)
Received: from [192.168.1.28] ([95.87.231.111])
by mx.google.com with ESMTPSA id m54sm54709956eex.2.1969.12.31.16.00.00
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Fri, 30 Aug 2013 06:23:32 -0700 (PDT)
Date: Fri, 30 Aug 2013 16:23:37 +0300
From: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Message-ID: <0103F5523929438C99A2AF40E0ADA510@HIDDEN>
In-Reply-To: <jwv1u5bwe10.fsf-monnier+emacs@HIDDEN>
References: <FA68F294BF5F4BF598190F14B70E82DC@HIDDEN>
<jwv1u5bwe10.fsf-monnier+emacs@HIDDEN>
Subject: Re: bug#15219: Emacs Lisp mode and Lisp mode font-locking
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="52209cd9_4d32ab86_99"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 15219
Cc: 15219 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
--52209cd9_4d32ab86_99
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Friday, August 30, 2013 at 3:45 PM, Stefan Monnier wrote:
> > I've noticed something odd about the font-locking in Emacs Lisp mode and
> > Lisp mode - keyword args are highlighted using the font-lock-builtin-face
> > and constructs like &optional are highlighted using
> > font-lock-type-face. I guess this was was done way back and hasn't been
> > updated in a while, but I think it might a good idea to revise this. Pretty
> > sure those font faces are intended for different usage. I think it would be
> > great if all Emacs programming modes used the built-in font-lock faces
> > consistently, so that the meaning of certain faces doesn't change from mode
> > to mode. I guess that the two modes might also start using the
> > font-lock-built-in face to highlight their core functions (like car, cdr,
> > mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of
> > the keyword face for things that are not special forms (like the when macro)
> > should be replaced with uses of the built-in face.
> >
>
>
> Which things are special forms and which things are macros is
> somewhat arbitrary. The important thing to know about them is that
> they're not functions, so their arguments may not be evaluated in the
> usual way.
>
>
Fair point. I guess it makes sense to some extend to consider some macros to be "keywords".
> Also macros are used to introduce new syntactic constructs: in normal
> programming languages, something like `when' would be highlighted as
> a `keyword', not as a `builtin'.
>
> I'm not completely sure what the `builtin' is used for, usually.
> What information is it meant to provide?
>
>
Generally the idea behind fontifying built-ins (AFAIK) is to remind programmers that something is part of the core of the language and it'd be unwise to redefine or shadow it. For instance in Clojure mode all methods from the clojure.core namespace are font-locked with the built-in face.
> I mean, do you consider
> `mapcar' "builtin" because it's fast? Because it's implemented in C?
> Because it's predefined (no need for any kind of autoloading/require)?
> Is `car' builtin because "if you didn't have it, you'd have to invent
> it" (IOW can't be implemented in Elisp)?
>
Normally built-in functions would be those that came with the standard library of the language and are pretty generic in nature. I guess in Emacs Lisp that would be functions like mapcar, mapc, vector, car, cdr - the building blocks on which everything else rests upon. I guess there are not that much of those and they haven't changed much in a long while. And as the Emacs manual itself states "font-lock-builtin-face is for the names of built-in functions".
>
>
> Stefan
Anyways, I'd be happy to get just a fix for the keywords and &optional (and related) faces, since those are definitely off.
--52209cd9_4d32ab86_99
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div><span style=3D=22color: rgb(160, 160, 168); =22>On =46=
riday, August 30, 2013 at 3:45 PM, Stefan Monnier wrote:</span></div>
<blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
<span><div><div><blockquote type=3D=22cite=22><div><d=
iv>I've noticed something odd about the font-locking in Emacs Lisp mode a=
nd</div><div>Lisp mode - keyword args are highlighted using the font-lock=
-builtin-face</div><div>and constructs like &optional are highlighted=
using</div><div>font-lock-type-face. I guess this was was done way back =
and hasn't been</div><div>updated in a while, but I think it might a good=
idea to revise this. Pretty</div><div>sure those font faces are intended=
for different usage. I think it would be</div><div>great if all Emacs pr=
ogramming modes used the built-in font-lock faces</div><div>consistently,=
so that the meaning of certain faces doesn't change from mode</div><div>=
to mode. I guess that the two modes might also start using the</div><div>=
font-lock-built-in face to highlight their core functions (like car, cdr,=
</div><div>mapcar, mapc, etc) - as Clojure mode does. Personally I feel t=
hat uses of</div><div>the keyword face for things that are not special fo=
rms (like the when macro)</div><div>should be replaced with uses of the b=
uilt-in face.</div></div></blockquote><div><br></div><div>Which things ar=
e special forms and which things are macros is</div><div>somewhat arbitra=
ry. The important thing to know about them is that</div><div>they're not=
functions, so their arguments may not be evaluated in the</div><div>usua=
l way.</div></div></div></span></blockquote><div><font face=3D=22Trebuche=
t MS=22>=46air point. I guess it makes sense to some extend to consider s=
ome macros to be =22keywords=22.</font> </div><blockquote type=3D=22=
cite=22 style=3D=22border-left-style:solid;border-width:1px;margin-left:0=
px;padding-left:10px;=22><div><div><div>Also macros are used to introduce=
new syntactic constructs: in normal</div><div>programming languages, som=
ething like =60when' would be highlighted as</div><div>a =60keyword', not=
as a =60builtin'.</div><div><br></div><div>I'm not completely sure what =
the =60builtin' is used for, usually.</div><div>What information is it me=
ant to provide=3F </div></div></div></blockquote><div><font face=3D=22Tre=
buchet MS=22>Generally the idea behind fontifying built-ins (A=46AIK) is =
to remind programmers that something is part of the core of the language =
and it'd be unwise to redefine or shadow it. =46or instance in Clojure mo=
de all methods from the clojure.core namespace are font-locked with the b=
uilt-in face.</font></div><blockquote type=3D=22cite=22 style=3D=22border=
-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>=
<div><div><div> I mean, do you consider</div><div>=60mapcar' =22builtin=22=
because it's fast=3F Because it's implemented in C=3F</div><div>Because=
it's predefined (no need for any kind of autoloading/require)=3F</div><d=
iv>Is =60car' builtin because =22if you didn't have it, you'd have to inv=
ent</div><div>it=22 (IOW can't be implemented in Elisp)=3F</div><div><br>=
</div></div></div></blockquote><div><font face=3D=22Trebuchet MS=22>Norma=
lly built-in functions would be those that came with the standard library=
of the language and are pretty generic in nature. </font> I gu=
ess in Emacs Lisp that would be functions like mapcar, mapc, vector, car,=
cdr - the building blocks on which everything else rests upon. I guess t=
here are not that much of those and they haven't changed much in a long w=
hile. And as the Emacs manual itself states =22<span style=3D=22font-styl=
e: inherit; line-height: 13px; color: rgb(53, 56, 42); font-family: sans-=
serif; =22>font-lock-builtin-face is </span><span style=3D=22color: =
rgb(53, 56, 42); font-family: sans-serif; =22>for the names of built-in f=
unctions=22.</span><span style=3D=22color: rgb(53, 56, 42); font-family: =
sans-serif; =22> </span></div><blockquote type=3D=22cite=22 style=3D=
=22border-left-style:solid;border-width:1px;margin-left:0px;padding-left:=
10px;=22><div><div><div></div><div><br></div><div> Stefan</div></d=
iv></div></blockquote><div>Anyways, I'd be happy to get just a fix for th=
e keywords and &optional (and related) faces, since those are definit=
ely off.</div>
=20
<div>
<br>
</div>
--52209cd9_4d32ab86_99--
bug-gnu-emacs@HIDDEN:bug#15219; Package emacs.
Full text available.
Received: (at 15219) by debbugs.gnu.org; 30 Aug 2013 12:45:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 30 08:45:29 2013
Received: from localhost ([127.0.0.1]:58834 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFO4u-0001Fh-Di
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 08:45:28 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.182]:44738)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <monnier@HIDDEN>) id 1VFO4n-0001FI-0K
for 15219 <at> debbugs.gnu.org; Fri, 30 Aug 2013 08:45:25 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KK6/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM
X-IPAS-Result: Av4EABK/CFHO+KK6/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM
X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="26039485"
Received: from 206-248-162-186.dsl.teksavvy.com (HELO pastel.home)
([206.248.162.186])
by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
30 Aug 2013 08:42:31 -0400
Received: by pastel.home (Postfix, from userid 20848)
id 102E262E73; Fri, 30 Aug 2013 08:45:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
Subject: Re: bug#15219: Emacs Lisp mode and Lisp mode font-locking
Message-ID: <jwv1u5bwe10.fsf-monnier+emacs@HIDDEN>
References: <FA68F294BF5F4BF598190F14B70E82DC@HIDDEN>
Date: Fri, 30 Aug 2013 08:45:15 -0400
In-Reply-To: <FA68F294BF5F4BF598190F14B70E82DC@HIDDEN> (Bozhidar Batsov's
message of "Fri, 30 Aug 2013 12:32:05 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 15219
Cc: 15219 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
> I've noticed something odd about the font-locking in Emacs Lisp mode and
> Lisp mode - keyword args are highlighted using the font-lock-builtin-face
> and constructs like &optional are highlighted using
> font-lock-type-face. I guess this was was done way back and hasn't been
> updated in a while, but I think it might a good idea to revise this. Pretty
> sure those font faces are intended for different usage. I think it would be
> great if all Emacs programming modes used the built-in font-lock faces
> consistently, so that the meaning of certain faces doesn't change from mode
> to mode. I guess that the two modes might also start using the
> font-lock-built-in face to highlight their core functions (like car, cdr,
> mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of
> the keyword face for things that are not special forms (like the when macro)
> should be replaced with uses of the built-in face.
Which things are special forms and which things are macros is
somewhat arbitrary. The important thing to know about them is that
they're not functions, so their arguments may not be evaluated in the
usual way.
Also macros are used to introduce new syntactic constructs: in normal
programming languages, something like `when' would be highlighted as
a `keyword', not as a `builtin'.
I'm not completely sure what the `builtin' is used for, usually.
What information is it meant to provide? I mean, do you consider
`mapcar' "builtin" because it's fast? Because it's implemented in C?
Because it's predefined (no need for any kind of autoloading/require)?
Is `car' builtin because "if you didn't have it, you'd have to invent
it" (IOW can't be implemented in Elisp)?
Stefan
bug-gnu-emacs@HIDDEN:bug#15219; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 30 Aug 2013 09:32:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 30 05:32:31 2013
Received: from localhost ([127.0.0.1]:58510 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFL4A-0003ZG-Tg
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 05:32:31 -0400
Received: from eggs.gnu.org ([208.118.235.92]:52948)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL48-0003Z0-0g
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 05:32:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL3x-00061c-Da
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 05:32:22 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:39865)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL3x-00061Y-AL
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 05:32:17 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54638)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL3r-0006Td-Oz
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 05:32:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL3m-0005zL-D5
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 05:32:11 -0400
Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:58455)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1VFL3m-0005zD-5N
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 05:32:06 -0400
Received: by mail-ea0-f169.google.com with SMTP id k11so791455eaj.0
for <bug-gnu-emacs@HIDDEN>; Fri, 30 Aug 2013 02:32:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:from:to:message-id:subject:mime-version:content-type;
bh=am35Ux4k0XmwhNDwqU6blLKAGftuLUtscXQIYx7TQm8=;
b=wh9pqAy/sUuGimzcZMLE93Qbf4GjeyUDNXcHXfhe1KvYNvwJCJBFi5lXO2Pxi4oQZc
c+7wW8Eal0cqcGnmMsm/rJPJmcSQv3Fhj27CCKl3ACTZu7KyPHpCMBf+lhzgf5TEiG9J
OXOQMtOP12cq0lSlVEoz56e+cCFLfEcaImewyXQD/efKgF5xcvNjG7oPCJ4EoKVvoef8
xpHtassWGJ9K87jYOBDJMTc0wug1xPhloSNuAVYEY6YDrrduKi7mTHUMhOex+YQJUtFz
L6NGcrZoVBZ8Zh6FAsxBeaTGe4fWZyrCCfpDLhIPAlMc1YNJeouHellN8cjRrT8qvpBK
uvbw==
X-Received: by 10.15.100.198 with SMTP id bn46mr11095793eeb.11.1377855125336;
Fri, 30 Aug 2013 02:32:05 -0700 (PDT)
Received: from [192.168.1.28] ([95.87.231.111])
by mx.google.com with ESMTPSA id b45sm53094573eef.4.1969.12.31.16.00.00
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Fri, 30 Aug 2013 02:32:04 -0700 (PDT)
Date: Fri, 30 Aug 2013 12:32:05 +0300
From: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Message-ID: <FA68F294BF5F4BF598190F14B70E82DC@HIDDEN>
Subject: Emacs Lisp mode and Lisp mode font-locking
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="52206695_7c58fd05_99"
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -2.4 (--)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
--52206695_7c58fd05_99
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I've noticed something odd about the font-locking in Emacs Lisp mode and Lisp mode - keyword args are highlighted using the font-lock-builtin-face and constructs like &optional are highlighted using font-lock-type-face. I guess this was was done way back and hasn't been updated in a while, but I think it might a good idea to revise this. Pretty sure those font faces are intended for different usage. I think it would be great if all Emacs programming modes used the built-in font-lock faces consistently, so that the meaning of certain faces doesn't change from mode to mode. I guess that the two modes might also start using the font-lock-built-in face to highlight their core functions (like car, cdr, mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of the keyword face for things that are not special forms (like the when macro) should be replaced with uses of the built-in face.
I've posted this to devel a while back (http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00592.html) and Michael Heerdegen suggested reporting it as a bug as well.
--
Cheers,
Bozhidar
--52206695_7c58fd05_99
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div>
<pre><font face=3D=22Trebuchet MS=22>I've noticed som=
ething odd about the font-locking in Emacs Lisp mode and
Lisp mode - keyword args are highlighted using the
font-lock-builtin-face and constructs like &optional are highlighted
using font-lock-type-face. =20
I guess this was was done way back and hasn't been updated in a
while, but I think it might a good idea to revise this. Pretty sure
those font faces are intended for different usage. I think it would
be great if all Emacs programming modes used the built-in font-lock faces=
consistently,
so that the meaning of certain faces doesn't change from mode to
mode.
I guess that the two modes might also start using the
font-lock-built-in face to highlight their core functions (like car,
cdr, mapcar, mapc, etc) - as Clojure mode does. Personally I feel that us=
es of the keyword face for things that are not special forms (like the wh=
en macro) should be replaced with uses of the built-in face.</font></pre>=
<pre><font face=3D=22Trebuchet MS=22>I've posted this to devel a while ba=
ck (<a href=3D=22http://lists.gnu.org/archive/html/emacs-devel/2013-07/ms=
g00592.html=22>http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg0=
0592.html</a>) and <span style=3D=22font-size: 13px; text-align: -webkit-=
left; =22>Michael Heerdegen suggested reporting it as a bug as well.</spa=
n></font></pre></div><div><div><br></div><div>-- </div><div>Cheers,<=
/div><div>Bozhidar</div><div><br></div></div>
--52206695_7c58fd05_99--
Bozhidar Batsov <bozhidar.batsov@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#15219; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.