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: Thu, 24 Aug 2017 14:31:22 +0200 Message-ID: References: <1503557767.41308.1083341824.4A2103C1@webmail.messagingengine.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1145d9da9a787105577f0145" X-Trace: blaine.gmane.org 1503577991 31576 195.159.176.226 (24 Aug 2017 12:33:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 12:33:11 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 14:33:02 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 1dkrJc-0007IE-BF for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 14:32:52 +0200 Original-Received: from localhost ([::1]:48414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkrJi-0006cP-U8 for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 08:32:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkrIJ-0006Yg-M3 for emacs-devel@gnu.org; Thu, 24 Aug 2017 08:31:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkrID-00019j-5n for emacs-devel@gnu.org; Thu, 24 Aug 2017 08:31:31 -0400 Original-Received: from mail-ua0-x22d.google.com ([2607:f8b0:400c:c08::22d]:36754) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkrIC-00015O-VP for emacs-devel@gnu.org; Thu, 24 Aug 2017 08:31:25 -0400 Original-Received: by mail-ua0-x22d.google.com with SMTP id 60so1506896uac.3 for ; Thu, 24 Aug 2017 05:31:23 -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=wLahKiuILl3PWih7ZULNDMRI9GUNq0zAV+hevC3t7is=; b=ZKr5GcENjkiV7Dwi7qKLAafESJmLujOFy15Av5ACEs7YJZNUGNpDMLT1KFS8W7nsot OjFC4TAx6H2JfCBQUa89xt78p2DBrTS+/pNEnXMAmHPLFxbLHUfap390yU/4WSvuMYVm pXQPxmeK1evShTODoLVDXXGCqQCdin1yP7SDMT2MBhzDnr2TLhTvw/0o+qmKe7MUUxyi kP7MKqekodk4QBdRvWxXK6oH7ZEG19U61aTuTx91ewXSnHIMZNchw/abBLc3feviFM3n x8TKlO7XeyMy/GfmMqPZRb7RN/fNG9+xe1VJYoHvauR99UoxuxxkPLHCyTSLARID/42z VNjQ== 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=wLahKiuILl3PWih7ZULNDMRI9GUNq0zAV+hevC3t7is=; b=jgDjSJFT50Eyo6CYuyCxOR5W9u835zjVophvG8yD2l0QSty8UEbeQ4chI3I+C/Iqho ZgokM0WZxezUYhQDdCywCGLgCbatsoFXCF9ENTEC7BVD/g7ZPHuqMs+TBQNR0ETaJnRa iv2WZH2XpthSrdoh0yl9LQ+X+f4YdyiHZfL3C98BIbBA+HkgTjCGjk4/T2A3JG1aNUcv W37q8zYld5/S//qF9jVkw24s54v7iHklyRigHHUv+/j7SfjTD+nzzcBgq3SR/xU6KZZ5 AU2FDca41mhQWJSqG5WpiK5SYNaGp14eUExpO1GIlZo+FbqgPKRhdU5N0oPBqU5QgPI1 QWIA== X-Gm-Message-State: AHYfb5h+eiJeLRaSc0K9yt4kFt5FIRVXXkxkhtMU5vxiUkVauQhtyao0 NYIjRhQ1WlNBnw1iRkiC31fyIk1nOw== X-Received: by 10.159.53.238 with SMTP id u43mr4433576uad.64.1503577882914; Thu, 24 Aug 2017 05:31:22 -0700 (PDT) Original-Received: by 10.31.171.3 with HTTP; Thu, 24 Aug 2017 05:31:22 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400c:c08::22d 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:217759 Archived-At: --001a1145d9da9a787105577f0145 Content-Type: text/plain; charset="UTF-8" Hi! I've been playing around with constructs like that for quite some time, here are some thoughts on the matter: -------- If you use a string face with, say, both a background and a foreground color, it will matter if you *replace* the existing face as opposed to *prepend* a new face on top of it. For example, the default Ruby mode replace the face, which doesn't look good when the string face has a background color: "Hello #{name}" With *prepend* it would have looked like: "Hello #{name}" In other words, the font-lock rule should use "prepend" and not "t" as the override flag. (I've got it on my todo-list to change a lot of "t":s to "prepend" but haven't had time to do it yet.) -------- One question is if the delimiters around the expression should be highlighted as well? In Ruby they are highlighted. In my cmake-font-lock[1] package I have opted not to highlight them, as it makes it easier to read the variable name: "Hello ${name}" Another reason for this is that CMake supports nested such constructs, which look better this way: "Hello ${name${tail}}" [1] https://github.com/Lindydancer/cmake-font-lock -------- > how should font-lock display `name`. Should it have a normal face as if it weren't inside a string? Or should have a kind of combination of string-face and something else? In all cases I've seen, the content is displayed using `font-lock-variable-name-face', even for the cases where the content is more complex than a plain variable. I would say that this is OK, as they stand out and, most of the time, it is a plain variable anyway. As I said above, using *prepend*, the end result will be a mix of font-lock-variable-name-face and font-lock-string-face. -------- > several parts of Emacs like to know if we're inside > code/string/comment (usually using (nth [3|4|8] (syntax-ppss))). > Should these all consider "name" as being inside code? > Or inside string? Or should we revisit all those cases one-by-one? I see this as a pure syntax highlighting thing, so I would say that syntax-ppss should treat them as strings. -------- A side note: I've started to make an inventory of syntax highlighting in various modes in Emacs, as part of a font-lock regression test suite I've accumulated over the years. The suite and the inventory is far from complete, but it might be worth looking into: https://github.com/Lindydancer/font-lock-regression-suite/blob/master/doc/CommentsOnMajorModes.org One mode that stands out in this respect is "bat" mode, it handles "%alpha" but not "%alpha_beta", and doesn't support the construct in strings at all. -- Anders On Thu, Aug 24, 2017 at 12:53 PM, Stefan Monnier wrote: > >> function getGreeting(name) { > >> let greeting = `Hello, ${name}!`; > >> return greeting; > >> } > > Indeed this problem has been with us in sh-script.el for many years. > There are several different aspects at play: > - how should font-lock display `name`. Should it have a normal face as > if it weren't inside a string? Or should have a kind of combination > of string-face and something else? > - how should we handle nestings of such constructs. > - several parts of Emacs like to know if we're inside > code/string/comment (usually using (nth [3|4|8] (syntax-ppss))). > Should these all consider "name" as being inside code? > Or inside string? Or should we revisit all those cases one-by-one? > > In sh-script, we use syntax-propertize to make sure the whole string and > its contents is all considered as a string and nothing else. This was > the simplest solution and probably corresponds to the current behavior > of js.el (and typescript.el) as well. > > > Stefan > > > --001a1145d9da9a787105577f0145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I've been playing around with c= onstructs like that for quite some time, here are some thoughts on the matt= er:

--------

If you u= se a string face with, say, both a background and a foreground color, it wi= ll matter if you *replace* the existing face as opposed to *prepend* a new = face on top of it.

For example, the default Ru= by mode replace the face, which doesn't look good when the string face = has a background color:
"Hello #{name}"
With *prepend* it would have look= ed like:
"Hello #{name}"
In other words= , the font-lock rule should use "prepend" and not "t" a= s the override flag. (I've got it on my todo-list to change a lot of &q= uot;t":s to "prepend" but haven't had time to do it yet.= )

--------

One question is if the delimiters around the expression should be highligh= ted as well? In Ruby they are highlighted. In my cmake-font-lock[1] package= I have opted not to highlight them, as it makes it easier to read the vari= able name:
"Hello ${name}"
Another reason for this is that CMake supports nested such constructs= , which look better this way:
"Hello ${name${tail}}=
"

--------

>= ; how should font-lock display `name`.=C2=A0 Should it have a normal face a= s=C2=A0if it weren't inside a string?=C2=A0 Or should have a kind of co= mbination=C2=A0of string-face and something else?

<= div>In all cases I've seen, the content is displayed using `font-lock-v= ariable-name-face', even for the cases where the content is more comple= x than a plain variable. I would say that this is OK, as they stand out and= , most of the time, it is a plain variable anyway.

As I said above, using *prepend*, the end result will be a mix of font-loc= k-variable-name-face and font-lock-string-face.

--------

> several parts of Emacs = like to know if we're inside
> =C2=A0code/string/comment (usually= using (nth [3|4|8] (syntax-ppss))).
> =C2=A0Should these all conside= r "name" as being inside code?
> =C2=A0Or inside string?=C2= =A0 Or should we revisit all those cases one-by-one?

I see this as a pure syntax highlighting thing, so I would say that = syntax-ppss should treat them as strings.

---= -----

A side note: I've started= to make an inventory of syntax highlighting in various modes in Emacs, as = part of a font-lock regression test suite I've accumulated over the yea= rs. The suite and the inventory is far from complete, but it might be worth= looking into:


One mode that stands out in this respect is "bat&quo= t; mode, it handles "%alpha" but not "%alpha_beta", and= doesn't support the construct in strings at all.

<= div>
=C2=A0 =C2=A0 -- Anders

On Thu, Aug 24, 2017 at 12:53 P= M, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> function getGr= eeting(name) {
>> let greeting =3D `Hello, ${name}!`;
>> return greeting;
>> }

Indeed this problem has been with us in sh-script.el for many years.
There are several different aspects at play:
- how should font-lock display `name`.=C2=A0 Should it have a normal face a= s
=C2=A0 if it weren't inside a string?=C2=A0 Or should have a kind of co= mbination
=C2=A0 of string-face and something else?
- how should we handle nestings of such constructs.
- several parts of Emacs like to know if we're inside
=C2=A0 code/string/comment (usually using (nth [3|4|8] (syntax-ppss))).
=C2=A0 Should these all consider "name" as being inside code?
=C2=A0 Or inside string?=C2=A0 Or should we revisit all those cases one-by-= one?

In sh-script, we use syntax-propertize to make sure the whole string and its contents is all considered as a string and nothing else.=C2=A0 This was=
the simplest solution and probably corresponds to the current behavior
of js.el (and typescript.el) as well.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan



--001a1145d9da9a787105577f0145--