From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: Regarding Emacs, js.el, template-strings and syntax-tables Date: Tue, 5 Sep 2017 11:30:51 +0200 Message-ID: References: <1503557767.41308.1083341824.4A2103C1@webmail.messagingengine.com> <6ca801de-9076-8a7f-6a7e-3b73ce207671@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114583c431267905586de2e4" X-Trace: blaine.gmane.org 1504604781 12203 195.159.176.226 (5 Sep 2017 09:46:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Sep 2017 09:46:21 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 05 11:46:06 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpAQf-0002C1-RZ for ged-emacs-devel@m.gmane.org; Tue, 05 Sep 2017 11:45:58 +0200 Original-Received: from localhost ([::1]:57768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpAQm-0003Wx-Th for ged-emacs-devel@m.gmane.org; Tue, 05 Sep 2017 05:46:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpACH-0000QO-C0 for emacs-devel@gnu.org; Tue, 05 Sep 2017 05:31:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpAC6-0008Gb-9K for emacs-devel@gnu.org; Tue, 05 Sep 2017 05:31:04 -0400 Original-Received: from mail-ua0-x234.google.com ([2607:f8b0:400c:c08::234]:38387) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dpAC6-0008Fu-3e for emacs-devel@gnu.org; Tue, 05 Sep 2017 05:30:54 -0400 Original-Received: by mail-ua0-x234.google.com with SMTP id l24so7065338uaa.5 for ; Tue, 05 Sep 2017 02:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y9oAP0lqfaWnY1hz+zL+xEpQbyiaEpJRIAcpXjsIg/Y=; b=B9tjscWtoW6n9LM20UPzhYwiXbplTH1eJjVWSFWwhB7qispi297cMl3X3tNaYclwaV oL64eIV6fbSPjCx52U9gQ2qIc2O1+o3wCRb+xZgRNTqKNa+vRnl8AcUZxZP0v2p0HxTE CdacPKN61ZcNkxy8l74aDz/0a2ayCHTccY9v3Lmj2FIE/QqK3P1L1S2CG3qjxSB6nBeu YXwu+ss5Jiz/IX0U5YP4xKl5/iOEEY+dqNFUoJRlWSiuOk0L29h1+kMrovy0LrhyQeua 7dT/hwzC6gWV1EiC47pnRbL0uREdmFSlkODyYqoKpCV4S+zzHF6YBfHWqTE7R+r9UASr M9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y9oAP0lqfaWnY1hz+zL+xEpQbyiaEpJRIAcpXjsIg/Y=; b=bGV7D/ucUkAaAPkx3OYR0hkG3k0O19j7V4G5EdjMNDaMTUV3KwLRuOsTIF1NLJWXNy 8+cv8fofnT32Dlwl3Uo5yJo/fmZmeDM+GsG8H1WwTC8jJAavzqwxW6s6Q1NOng+z++EW /TSpcQvCeIuqMfxGhn3sR4uX1MPomcXXXyZmrND0xYsWKTb5iVUY19vaaV1s191FeFmf Ms7S7uJhbGkcPqblnU5dBpMmiBfPJ+QviCBtWttCOMILJMyvny95sa7kNEnPgy6iSsGD 2vvBgSJzrjQOydp07HnWNK+sSRfBZJXnCajF8nC8HuLMN9IbcHm2olLAD2TFQma+yWkg HPbg== X-Gm-Message-State: AHPjjUhf73+5zJYZGQMjDbmAS8K2hGWRX61OaGTyWaxFdWmi9ZSmlAtv b5G+JRfCYZBZLV9YXeMjPu5ZrbcSjw== X-Google-Smtp-Source: ADKCNb5VRCmBQa5jPvvfA/ivpUY/bkIBqCMQJGlnQKA7YSLWJbqytpc9Qbfnik1BOmIGP7OULLxvyjoh+4DmF2NCyec= X-Received: by 10.176.20.10 with SMTP id b10mr1924259uae.191.1504603853103; Tue, 05 Sep 2017 02:30:53 -0700 (PDT) Original-Received: by 10.31.171.202 with HTTP; Tue, 5 Sep 2017 02:30:51 -0700 (PDT) In-Reply-To: <6ca801de-9076-8a7f-6a7e-3b73ce207671@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400c:c08::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:217941 Archived-At: --001a114583c431267905586de2e4 Content-Type: text/plain; charset="UTF-8" > > In my experience, I can read code easier if the delimiters aren't >> highlighted the same way the content is. (In other words, the current Ruby >> implementation isn't ideal for me.) >> > > Yes, so in the case of ruby-mode, the delimiters will have some special > face (keyword? IDK), and the content will have the default face. Keyword-face or builtin-face on top of string-face would work well. While we're on the subject. I've been thinking about highlighting >> parameters in functions and blocks in Ruby. >> > > Let's maybe make it an optional mode, so ruby-mode doesn't stand out too > much (or discuss whether all modes should do that if possible, on > emacs-devel). But I've been looking at this too, albeit from a different > standpoint (completion of local variable names). An optional mode would do nicely. It wouldn't be too difficult, and it would make code easier to read. >> Unfortunately, it doesn't include all variables as local variables can be >> created on the fly using a plain assignment in Ruby. >> > > Finding assignments is easy (just a regexp). Tracking variable scopes > (defined by their belonging to methods, or blocks, or even class/module > bodies) looks harder to me. We can do that by parsing expressions with > SMIE, but that's not fast if we have to parse the whole class body (there > are some big classes out there). > > Limiting ourselves to only methods might be fine, though. Methods and do-blocks would be straight forward, and make Ruby code a lot easier to read. As a parallel, my lisp-extra-font-lock package ( >> https://github.com/Lindydancer/lisp-extra-font-lock) do this in Lisp >> modes for function and lambda parameters and local variables introduces >> using `let`, `dolist` et.c. Now that I've been using it for a couple of >> years, I would not dream of going back to the near black-and-white world of >> the default lisp modes. >> > > I like the idea, but seeing the red on the screenshot is a bit > off-putting. red is for errors. > The screenshot demonstrates all features at once, so it might look a bit overwhelming -- in normal code it doesn't highlight that much. I've opted to define new faces and make them inherit from the predefined. This allows the faces to be customized (e.g. if you don't like red), and they work when a custom theme is used. I settled on the warning face for two constructs, as it was the least bad one available. So far, I've never misinterpreted a highlighted variable name for an error, or vise versa. Anyway, I understand your concern. I'll revisit this and see if there is another way to do it. -- Anders --001a114583c431267905586de2e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= In my experience, I can read code easier if the delimiters aren't highl= ighted the same way the content is. (In other words, the current Ruby imple= mentation isn't ideal for me.)

 Yes, so in the case of ruby-mode, the delimiters will have some special fac= e (keyword? IDK), and the content will have the default face.<= div>
Keyword-face or builtin-face on top of string-face would= work well.


While we're on the s= ubject. I've been thinking about highlighting parameters in functions a= nd blocks in Ruby.

 Let's maybe make it an optional mode, so ruby-mode doesn't stand ou= t too much (or discuss whether all modes should do that if possible, on ema= cs-devel). But I've been looking at this too, albeit from a different s= tandpoint (completion of local variable names).

=
An optional mode would do nicely.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
It wouldn't be too difficult, and it would make code easier to read.= Unfortunately, it doesn't include all variables as local variables can= be created on the fly using a plain assignment in Ruby.

 Finding assignments is easy (just a regexp). Tracking variable scopes (defi= ned by their belonging to methods, or blocks, or even class/module bodies) = looks harder to me. We can do that by parsing expressions with SMIE, but th= at's not fast if we have to parse the whole class body (there are some = big classes out there).

Limiting ourselves to only methods might be fine, though.
=
Methods and do-blocks would be straight forward, and make Ru= by code a lot easier to read.


As a p= arallel, my lisp-extra-font-lock package (https:/= /github.com/Lindydancer/lisp-extra-font-lock) do this in Lisp mode= s for function and lambda parameters and local variables introduces using `= let`, `dolist` et.c. Now that I've been using it for a couple of years,= I would not dream of going back to the near black-and-white world of the d= efault lisp modes.

 I like the idea, but seeing the red on the screenshot is a bit off-putting.= red is for errors.

The screenshot demo= nstrates all features at once, so it might look a bit overwhelming -- in no= rmal code it doesn't highlight that much.

I've opted to define new faces = and make them inherit from the predefined. This allows the faces to be cust= omized (e.g. if you don't like red), and they work when a custom theme = is used. I settled on the warning face for two constructs, as it was the le= ast bad one available. So far, I've never misinterpreted a highlighted = variable name for an error, or vise versa.
=
Anyway, I understand your concern. I&#= 39;ll revisit this and see if there is another way to do it.

=C2=A0 =C2=A0 -- And= ers

--001a114583c431267905586de2e4--