From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Donald Ephraim Curtis Newsgroups: gmane.emacs.devel Subject: Re: adding a standard font-lock-number-face Date: Fri, 17 Jun 2011 11:29:58 -0500 Message-ID: <49FB66A8-05CE-4843-BE46-B39F0435BE38@gmail.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1308330545 11066 80.91.229.12 (17 Jun 2011 17:09:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Jun 2011 17:09:05 +0000 (UTC) Cc: Stefan Monnier , Emacs-Devel devel To: Fabian Ezequiel Gallina Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 17 19:08:59 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QXcXS-000393-JM for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2011 19:08:58 +0200 Original-Received: from localhost ([::1]:57843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXcXR-00042n-BE for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2011 13:08:57 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXbvo-0001R8-Ml for emacs-devel@gnu.org; Fri, 17 Jun 2011 12:30:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXbvm-0000bZ-AJ for emacs-devel@gnu.org; Fri, 17 Jun 2011 12:30:04 -0400 Original-Received: from mail-iw0-f169.google.com ([209.85.214.169]:55317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXbvm-0000b7-0n for emacs-devel@gnu.org; Fri, 17 Jun 2011 12:30:02 -0400 Original-Received: by iwg8 with SMTP id 8so2832660iwg.0 for ; Fri, 17 Jun 2011 09:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Efrj1fqZ1/7yOgGwzLnimO8wQisqtFbdU7e4oSoF2fc=; b=st6c67Ki06z+Hct5z2erRMieCf7UtJTE7vF//CPgUmS4y7e+4vp4A1BOPMcuxFkkjr j1tW0K7cjlWpzCwU8rEan2aDb1M07Ld6v8VIiYccn+0cCE/PnTxS5HW00UA/hePMlw7G iKtuEpgOqPm86Mb60jWmBQ2G/nn8tG4eMiX6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qIh5LX8s+uLV6tbiSnKWvpHNWR0dXqxgJvkXsB12uOPAprHuOwzFMX6EeKeWxaUAgk JwIiU7/+aXoJetTecX5M+tQdexrSrdW6DSRODgUins0djxuyZil6Oj6nvhgH+uupgMLv nyysI+dHNpdMR7ZIQXXFXupw9Ub3s8vqe9Sxc= Original-Received: by 10.42.18.200 with SMTP id y8mr2040067ica.452.1308328201114; Fri, 17 Jun 2011 09:30:01 -0700 (PDT) Original-Received: from dhcpw80ffc068.dynamic.uiowa.edu (dhcpw80ffc068.dynamic.uiowa.edu [128.255.192.104]) by mx.google.com with ESMTPS id a9sm2721551icy.18.2011.06.17.09.29.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 09:30:00 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140616 Archived-At: Hi, I was originally the person that brought this to Fabian's attention, and = so it was my "complaint". But he's more-correct in that it's not a = "complaint" as much as something I like. =20 There are numerous posts elsewhere where people have fixed this issue by = adding some elisp to their personal configs; i will not fill this thread = with links to prove the point. I currently do this in my configuration = file. Performance doesn't seem to be an issue. As well, there are = plenty of other editors (whose authors are developers themselves) that = also must find this useful; since they include this highlighting. This = doesn't mean Emacs should go jump off a bridge (because their friends = are doing it). I don't understand why syntax highlighting has to *only* signify = structure. More important is to help me (the user/developer) navigating = the code. I personally find highlighting numbers does help me navigate = code; especially in debugging.=08 Highlighting should be useful over = being "technically consistent". Regardless of opinions, limiting the available faces limits theme = designers and ultimately limits the user. The default can always be to = inherit the default-face. At least then there is a face for this type = of thing that modes and themes can use. =20 This is just an opportunity for Emacs to include some better (i.e., = expected, standard, common, etc.) defaults. Maybe that's not the point, = but everytime it takes me an hour or more =96 because i'm a newb =96 to = do something I think should be really simple, I'm a bit annoyed. So = then I think, maybe I could fix this for future generations. And here = we are. argument against myself: it's easy to add into your personal config so = no big deal. -- Donald Ephraim Curtis dcurtis@milkbox.net On Jun 17, 2011, at 10:14, Fabian Ezequiel Gallina wrote: > 2011/6/17 Stefan Monnier : >>> An argument I can think of for inclusion is that it seems = highlighting >>> those kind of stuff (event operators) is really common on other >>> editors, so it is acceptable that people coming from other places >>> would expect this kind of stuff highlighted out-of-the-box. I know = the >>=20 >> I haven't seen many complaints about it either in emacs-devel or >> gnu-emacs-help, so I don't think it makes much difference. People do >> not expect one editor to behave exactly like another. >>=20 >=20 > Think of it of as a feature request, not a problem. I think it might > be good to have some way to define those kind of *extra* fancy stuff > and standardize them (even if not enabled by default). In my opinion, > that will likely help also to improve things avoiding the creation of > new non standard faces in external packages. >=20 > Even when I'm writing that, I feel we could also define a set standard > faces for package developers to use in their special modes. I guess > this can be the start of more complete font-locking framework that > could lead to help Emacs to be simple to theme, avoiding the need to > define a hundred faces to make themes work OK with your custom > packages. >=20 >=20 > Regards, > --=20 > Fabi=E1n E. Gallina >=20