From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Regarding Emacs, js.el, template-strings and syntax-tables Date: Thu, 24 Aug 2017 10:04:55 -0400 Message-ID: References: <1503557767.41308.1083341824.4A2103C1@webmail.messagingengine.com> <1503576818.100758.1083575560.7079FD9A@webmail.messagingengine.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1503583529 2964 195.159.176.226 (24 Aug 2017 14:05:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 14:05:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: jostein@kjonigsen.net, emacs-devel@gnu.org To: Jostein =?windows-1252?Q?Kj=F8nigsen?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 16:05:21 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 1dkskn-00089m-D8 for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 16:05:01 +0200 Original-Received: from localhost ([::1]:48794 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dksku-00057P-4m for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 10:05:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkskn-00057I-N7 for emacs-devel@gnu.org; Thu, 24 Aug 2017 10:05:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkskj-00077i-LE for emacs-devel@gnu.org; Thu, 24 Aug 2017 10:05:01 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:42838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkskj-00077Q-Ff for emacs-devel@gnu.org; Thu, 24 Aug 2017 10:04:57 -0400 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7OE4t1p017166; Thu, 24 Aug 2017 10:04:56 -0400 Original-Received: by lechazo.home (Postfix, from userid 20848) id 98619689E2; Thu, 24 Aug 2017 10:04:55 -0400 (EDT) In-Reply-To: <1503576818.100758.1083575560.7079FD9A@webmail.messagingengine.com> ("Jostein =?windows-1252?Q?Kj=F8nigsen=22's?= message of "Thu, 24 Aug 2017 14:13:38 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6101=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6101> : inlines <6037> : streams <1759985> : uri <2489059> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:217763 Archived-At: > I'd vote for "plain" face, and name being styled as it would have been > outside the string-context. If a mode-author wants to fancy it up, we > should definitely have a way to easily accommodate that though. > Having a separate expression-in-string-or-comment face is probably the > best approach in that regard. If we want to handle nesting, the easiest solution is either "color everything like a string" or "color `name` as if it weren't in a string". Anything in between will tend ask "how do I distinguish a string-within-a-string from a string-not-within-a-string, and what about a string-within-a-string-within-a-string?". So I tend to agree with you here. But Anders Lindgren seems to disagree. >> - how should we handle nestings of such constructs. > That's a good question, but I think a even better question would be to > ask what that would look like, and *if* we should strive to support it > in the first place. For sh-script we definitely need to support it, because it's often used for things equivalent to nesting function calls as in (f1 (f2 z (f3 x) y)). E.g.: x = "blabla $(echo "$foo" | bar $(find . -print))" > If we were to support these kind of endless constructs (which I'm sure > someone will find a way to make), we would need to consider this a level > of nesting, just like we do with parens and curly braces and what not. Yes, at the level of syntax-tables (and parse-partial-sexp) we'll definitely want to handle arbitrary nestings. W.r.t how to display it, we will probably prefer to disregard the nesting level and only pay attention to the top-level or the bottom-level (or both). > How about instead extending (syntax-ppss) to keep all existing > behaviour for all existing properties, but include some new ones > with more information? Yes, of course, that's what we'd do. I think we'd add yet-another element which would work a bit like the (nth 9 ppss) but would keep a stack of states (POS . PPSS) rather than a stack of buffer positions. > It would be really nice if we could have our cake and eat it too. I love cake, Stefan