From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Small improvements to ruby-mode Date: Thu, 11 Jul 2013 14:23:21 +0300 Message-ID: References: <2A6700DEDCA640EF92B326002717596D@gmail.com> <51D1F98D.3060900@yandex.ru> <51D31E12.7060002@yandex.ru> <51D4476A.40107@yandex.ru> <51D6A02C.2020207@yandex.ru> <51D6D500.7080306@yandex.ru> <51DB6516.1090708@yandex.ru> <51DC43CE.3090206@yandex.ru> <51DDA366.9020700@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2a6322d262c04e13a9f7b X-Trace: ger.gmane.org 1373541818 20901 80.91.229.3 (11 Jul 2013 11:23:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Jul 2013 11:23:38 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 11 13:23:36 2013 Return-path: Envelope-to: ged-emacs-devel@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 1UxEyG-0003za-BR for ged-emacs-devel@m.gmane.org; Thu, 11 Jul 2013 13:23:36 +0200 Original-Received: from localhost ([::1]:59618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxEyF-0003w1-Rr for ged-emacs-devel@m.gmane.org; Thu, 11 Jul 2013 07:23:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxEy7-0003vs-LY for emacs-devel@gnu.org; Thu, 11 Jul 2013 07:23:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxEy2-000367-Mq for emacs-devel@gnu.org; Thu, 11 Jul 2013 07:23:27 -0400 Original-Received: from mail-qe0-x232.google.com ([2607:f8b0:400d:c02::232]:64490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxEy2-00035w-HV for emacs-devel@gnu.org; Thu, 11 Jul 2013 07:23:22 -0400 Original-Received: by mail-qe0-f50.google.com with SMTP id f6so4305147qej.37 for ; Thu, 11 Jul 2013 04:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fHzzhEuVGqcGi93ewHRfKwe7cmbOusVbNZnliet9yCI=; b=0aS4c9iJuwnVY929cz684USuqcdDA5SBgve9LCJXe3f2fnwu12YR6y5yKUoUIqpK0b RHHnaW+VpTN5dMc+mFfYQLyTP2wZch9DJAS3SWldrVku+5LCEBUu89UcNx/9/QHHaXEC JrvWe+mjzya8o46+L4fLVPaAvTYsAKXaiCWrxNfdyhJPN5T4LPyOlEmfR8lvipbRdJ3N 1mI5wDPqjCvWhcXEO8JDMIbg2RXRs36anXWns/x1kafKX/N5vz/7P/Y9LbMgUz0R1LLe AWIOW92CjpKIzyO6tyJWBaBS6pcOuXI3XYaVRn+xHP2aH+OlRSne1DBOsJQajTUWd6gi Vjaw== X-Received: by 10.224.173.2 with SMTP id n2mr31688839qaz.75.1373541801730; Thu, 11 Jul 2013 04:23:21 -0700 (PDT) Original-Received: by 10.49.59.13 with HTTP; Thu, 11 Jul 2013 04:23:21 -0700 (PDT) In-Reply-To: <51DDA366.9020700@yandex.ru> X-Google-Sender-Auth: Epdx-GCbXTcHsj9BYnAXax4Tpgg X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c02::232 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:161823 Archived-At: --001a11c2a6322d262c04e13a9f7b Content-Type: text/plain; charset=UTF-8 On 10 July 2013 21:09, Dmitry Gutov wrote: > On 10.07.2013 10:09, Bozhidar Batsov wrote: > >> Normally I'd have been doing that from the start, but I'm not extremely >> fond of Emacs's "issue tracker". >> > > Me neither. It's better that no tracker at all, though. > > > > While class names are actually constants, the reverse is obviously > > not the same - therefore my desire to separate them. > > Still, that's likely the original reason why they're highlighted with the > same face. Class names are closer to constants than constants are to > symbols. > > > > Since in a typical Ruby program class and module names are used much > > more than "regular" constants I don't think the change would be > > particularly disruptive. > > classes and modules continue to use the type face, constants start > > using the constant face, symbols continue to use the constant face > > (and optionally there is the ability to customize it). In the long > > run such a change would surely be beneficial. > > I meant that we would preserve the equality between module name and > constants' faces. So, if they both switch to font-lock-constant-face, this > will be noticeable, as, like you said, module names are used a lot. > > Symbols can then use type-face, or preprocessor-face, the latter would be > a smidgen less inappropriate. > > If you do want class names and constants to have different faces, there is > an obvious question of ambiguity. Is "C" a class or a constant? I don't > like the idea of it changing color after I type the second letter. > Still, we should consider functions with names like Float. Currently they are not highlighted correctly - Something(test) is highlighted as a constant, when obviously it's not. I guess classes, constants and functions like this could be font-locked after the first character that's not part of the identifier name appears, to avoid the changing of the face after the initial character. > ST2 doesn't seem to highlight either, at all. RubyMine, from what I can > tell from a Youtube video, either doesn't highlight them, or, depending on > the context, highlights them with the same color (and symbols, too): > http://www.youtube.com/watch?**v=LnN-JIxDRCg#t=1464s > --001a11c2a6322d262c04e13a9f7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 10 July 2013 21:09, Dmitry Gutov <dgutov@yandex.ru> wrote:
On 10.07.2013 10:09, Bozhi= dar Batsov wrote:
Normally I'd have been doing that from the start, but I'm not extre= mely
fond of Emacs's "issue tracker".

Me neither. It's better that no tracker at all, though.


> While class names are actually constants, the reverse is obviously
> not the same - therefore my desire to separate them.

Still, that's likely the original reason why they're highlighted wi= th the same face. Class names are closer to constants than constants are to= symbols.


> Since in a typical Ruby program class and module names are used much > more than "regular" constants I don't think the change w= ould be
> particularly disruptive.
> classes and modules continue to use the type face, constants start
> using the constant face, symbols continue to use the constant face
> (and optionally there is the ability to customize it). In the long
> run such a change would surely be beneficial.

I meant that we would preserve the equality between module name and constan= ts' faces. So, if they both switch to font-lock-constant-face, this wil= l be noticeable, as, like you said, module names are used a lot.

Symbols can then use type-face, or preprocessor-face, the latter would be a= smidgen less inappropriate.

If you do want class names and constants to have different faces, there is = an obvious question of ambiguity. Is "C" a class or a constant? I= don't like the idea of it changing color after I type the second lette= r.

Still, we should consider functions = with names like Float. Currently they are not highlighted correctly - Somet= hing(test) is highlighted as a constant, when obviously it's not. I gue= ss classes, constants and functions like this could be font-locked after th= e first character that's not part of the identifier name appears, to av= oid the changing of the face after the initial character.


ST2 doesn't seem to highlight either, at all. RubyMine, from what I can= tell from a Youtube video, either doesn't highlight them, or, dependin= g on the context, highlights them with the same color (and symbols, too): <= a href=3D"http://www.youtube.com/watch?v=3DLnN-JIxDRCg#t=3D1464s" target=3D= "_blank">http://www.youtube.com/watch?v=3DLnN-JIxDRCg#t=3D1464s<= br>

--001a11c2a6322d262c04e13a9f7b--