From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Newsgroups: gmane.emacs.bugs Subject: bug#21898: scss-mode font-lock face for variables Date: Fri, 13 Nov 2015 21:29:45 +0100 Message-ID: <1447446585.9212.2@smtp.gmail.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-soiIomttdZ0F7+T4qBMo" X-Trace: ger.gmane.org 1447446646 20851 80.91.229.3 (13 Nov 2015 20:30:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 20:30:46 +0000 (UTC) Cc: 21898@debbugs.gnu.org, Stefan Monnier To: Jackson Hamilton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 13 21:30:34 2015 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 1ZxKz9-0004A6-Va for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Nov 2015 21:30:16 +0100 Original-Received: from localhost ([::1]:55092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxKz9-0001Ep-8x for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Nov 2015 15:30:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxKz5-0001Cf-4R for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2015 15:30:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxKz0-00085C-4q for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2015 15:30:11 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxKz0-00084w-2Y for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2015 15:30:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZxKyz-00064Q-EH for bug-gnu-emacs@gnu.org; Fri, 13 Nov 2015 15:30:05 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Nov 2015 20:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21898 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 21898-submit@debbugs.gnu.org id=B21898.144744659123294 (code B ref 21898); Fri, 13 Nov 2015 20:30:04 +0000 Original-Received: (at 21898) by debbugs.gnu.org; 13 Nov 2015 20:29:51 +0000 Original-Received: from localhost ([127.0.0.1]:37496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZxKyl-00063d-1f for submit@debbugs.gnu.org; Fri, 13 Nov 2015 15:29:51 -0500 Original-Received: from mail-lb0-f170.google.com ([209.85.217.170]:35733) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZxKyi-00063S-1M for 21898@debbugs.gnu.org; Fri, 13 Nov 2015 15:29:48 -0500 Original-Received: by lbbsy6 with SMTP id sy6so31757850lbb.2 for <21898@debbugs.gnu.org>; Fri, 13 Nov 2015 12:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version:content-type; bh=6vpE4HBxP95Qf0iMiPGPWtyRIp2vur4F8A8kDcoGI2Y=; b=kvJJWT86rg+AMGOP7KYAiqthGOGbkbO2Z118bTl4mmdTn82sahzOOglBo9g+zs97YD gocFVPRCGjWLOtTUoG+IJeDYuTnNZq82E6J8pkXWoimszo2GZQ6PzunBomTPFvdC78mm VKsklSNnElnKOlvlix4RKsmzJ6mxC6PG3jezsA0KNRcHgcSJoF2aNS4FcjBl6gqIr6ae to7neTB1swrquvXqPfhBsdAwJUpbImT1NW0mE2ZuI5HvmQcwrOpfJ8Xys7mjMsmPymB3 zuP6Sj96gpYWXt9X1nKDIv41hJytrIxAO7NXdGOClfKr2U8fwMZtQ+O54nWJZoA2tNdv 2t2g== X-Received: by 10.112.169.97 with SMTP id ad1mr11486438lbc.5.1447446587125; Fri, 13 Nov 2015 12:29:47 -0800 (PST) Original-Received: from [192.168.100.7] (cm-84.210.143.4.getinternet.no. [84.210.143.4]) by smtp.gmail.com with ESMTPSA id v4sm3381339lbo.30.2015.11.13.12.29.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 12:29:46 -0800 (PST) In-Reply-To: X-Mailer: geary/0.10.0 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: 208.118.235.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:108732 Archived-At: --=-soiIomttdZ0F7+T4qBMo Content-Type: text/plain; charset=utf-8; format=flowed Hello, Jackson! Thanks for the report. I never noticed this issue myself, since the theme I'm using (Leuven) styles the css-property face. We should definitely fix it. Like you say, two possible solutions are: 1. Highlight variables with font-lock-constant-face instead of font-lock-variable-name-face. A downside is that this is backwards wrt. the intended meaning of the faces, so users will see variables highlighted in a face that's usually used for constants. An upside is that it will probably look nice with existing themes, since they are likely to already style font-lock-variable-name-face. 2. Change the css-property face. It doesn't mean it has to inherit from another one of the standard Font Lock faces, we could also just change the default foreground color, for instance. A downside of this approach is that users may be startled that the face that they were used to changed, but for themes that already style the css-property, everything will be like before. The upside is that font-lock-variable-name-face remains used for variables, like it's intended to. I'm not sure which solution is best. Either way, we should also add a defface for variables and use it for Sass variables (and also CSS variables later on). -- Simen On Fri, Nov 13, 2015 at 7:37 AM, Jackson Hamilton wrote: > I'd like to propose the following change to the scss-mode on master: > Use font-lock-constant-face for SCSS variables. > > This may not seem intuitive from a naming perspective, but > font-lock-variable-name-face is already used for CSS properties. That > makes it harder to distinguish between properties and variables. > > AFAIK, Sass doesn't even have constants, so I don't see much harm in > using this face. It'd be a less dramatic change for those who have > grown used to variable coloring for CSS properties. > > I guess the alternative would be to inherit the property face from > something else, to free up the face for real variables. But then what > do we use for properties? (Inheriting from nothing doesn't look good > IMO.) > > Attached is the proposed patch. --=-soiIomttdZ0F7+T4qBMo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello, Jackson!

Thanks for the report. I neve= r noticed this issue myself, since the
theme I'm using (Leuven) s= tyles the css-property face. We should
definitely fix it.

Like you say, two possible solutions are:

<= /div>
1. Highlight variables with font-lock-constant-face instead of
   font-lock-variable-name-face. A downside is that this = is backwards
   wrt. the intended meaning of the faces,= so users will see variables
   highlighted in a face t= hat's usually used for constants. An upside is
   that = it will probably look nice with existing themes, since they are
&= nbsp;  likely to already style font-lock-variable-name-face.

2. Change the css-property face. It doesn't mean it has to = inherit from
   another one of the standard Font Lock f= aces, we could also just
   change the default foregrou= nd color, for instance. A downside of this
   approach = is that users may be startled that the face that they were
 =  used to changed, but for themes that already style the css-property,=
   everything will be like before. The upside is that<= /div>
   font-lock-variable-name-face remains used for variab= les, like it's
   intended to.

I'm not sure which solution is best.

Either = way, we should also add a defface for variables and use it for
Sa= ss variables (and also CSS variables later on).

<= div>-- Simen

On Fri, Nov 13, 2015 at 7:37 AM, Jackson H= amilton <jackson@jacksonrayhamilton.com> wrote:
I'd like to propose the followin= g change to the scss-mode on master: Use font-lock-constant-face for SCSS v= ariables.

This may not seem intuitive from a naming pers= pective, but font-lock-variable-name-face is already used for CSS propertie= s. That makes it harder to distinguish between properties and variables.

AFAIK, Sass doesn't even have constants, so I don't = see much harm in using this face. It'd be a less dramatic change for those = who have grown used to variable coloring for CSS properties.

=
I guess the alternative would be to inherit the property face fr= om something else, to free up the face for real variables. But then what do= we use for properties? (Inheriting from nothing doesn't look good IMO.)

Attached is the proposed patch.
= --=-soiIomttdZ0F7+T4qBMo--