From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Felipe Ochoa" Newsgroups: gmane.emacs.bugs Subject: bug#24896: JSX prop indentation after fat arrow Date: Mon, 23 Jan 2017 10:26:06 +0100 Message-ID: <004301d2755a$b9f62b30$2de28190$@gmail.com> References: <6d48deda-1d14-2d50-ca86-c89f35bf37db@yandex.ru> <77f1f91d-2f8c-0509-7a16-50bae68f3883@jacksonrayhamilton.com> <447f307f-e226-e6a5-f62a-88bcdcda74df@yandex.ru> <79cc5841-8480-b2fd-eeb7-ff2bf33a0e68@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1485187959 10138 195.159.176.226 (23 Jan 2017 16:12:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2017 16:12:39 +0000 (UTC) Cc: 24896@debbugs.gnu.org, 'Jackson Ray Hamilton' To: "'Dmitry Gutov'" , "'Felipe Ochoa'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 23 17:12:34 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cVhED-0001Co-0o for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jan 2017 17:12:21 +0100 Original-Received: from localhost ([::1]:42919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVhEG-0007ca-IS for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jan 2017 11:12:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVhE0-0007TB-GH for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 11:12:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVhDu-0001X5-ME for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 11:12:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41095) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVhDu-0001Wv-Hp for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 11:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cVhDu-00024q-BW for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 11:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Felipe Ochoa" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2017 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24896 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24896-submit@debbugs.gnu.org id=B24896.14851878667883 (code B ref 24896); Mon, 23 Jan 2017 16:12:02 +0000 Original-Received: (at 24896) by debbugs.gnu.org; 23 Jan 2017 16:11:06 +0000 Original-Received: from localhost ([127.0.0.1]:39290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVhCz-000234-K6 for submit@debbugs.gnu.org; Mon, 23 Jan 2017 11:11:05 -0500 Original-Received: from mail-wm0-f47.google.com ([74.125.82.47]:37703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVatD-0007Q8-UL for 24896@debbugs.gnu.org; Mon, 23 Jan 2017 04:26:16 -0500 Original-Received: by mail-wm0-f47.google.com with SMTP id c206so144365384wme.0 for <24896@debbugs.gnu.org>; Mon, 23 Jan 2017 01:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=AZFO1oHp0RD0WMmjPY9G95cf8HFM9JJFMsEG+bYGHBQ=; b=CsHwhTdCZujyrv9l9NSMarY6Uvhm2a8Vg5JTBoBCr9PlflJewpsDYMw7mussrOQ7Gw BCL4sQ3TiIFsCcEHQ61zJcvWUKjJb4Dm4HjocH+DZedDCEnRV+UnKS9a5AWyON98JLsk E75/8lEAuhBzIcaRgDykuD8k3FwTuc4PcKeCypYgBjehBGMF5Cf/+nHzgBq2/4js1ajG JHn6mmnwUcX3a4myaYarFfghSWi94R1s2PWt7yGgJj7vwj5NKBHmOGqZQXSlinkrDiMO cKX9eo5TEpYhlKbuL+vtDFrTk2IZCM3NKhBjYeDnRT81Zjz65RR4Ezk899ZSNAPzPgzS fEdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=AZFO1oHp0RD0WMmjPY9G95cf8HFM9JJFMsEG+bYGHBQ=; b=JLunhETXVm5nUpALY7g0uTy4K1KtARqCaNd98uG0rlF9L3AjSthuYGaZrJh7buCWx0 qYTJAVoOGQJeE1tjcl6x65Bj+9rLr6/BtNJwBN6rflXioHeDUFEt8TyXtGVarjB1ynmZ 09Kf5KbJ/waCCEebkZAJm5wGDQFI9BrefVzemdaJjvPnxkoQwU7ro+dLmIJdBHHzmKAQ CgGy9/rNLKqPl/5ZlKP7VRYOmfrEV82ruKBHWAg6Ix35ID0FEK/EuKQE8+Oswj3ujEGM nALLK1VwVGBlRwRmlKGTBMZQVAtwJqRm5Y+sOjusoi8G/neUGDlVj4+IsMBdryoe/Uyn lfBQ== X-Gm-Message-State: AIkVDXLAsIkdM7aUXzIvMt9TY6STilj0AsOlIlJSiBOlBa87LEouhIzUPXt0AFdwqnMUDQ== X-Received: by 10.28.62.144 with SMTP id l138mr12141228wma.50.1485163569855; Mon, 23 Jan 2017 01:26:09 -0800 (PST) Original-Received: from DESKTOP0SBUG2I (i32174.upc-i.chello.nl. [62.195.32.174]) by smtp.gmail.com with ESMTPSA id 36sm13547844wrz.8.2017.01.23.01.26.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 01:26:09 -0800 (PST) In-Reply-To: <79cc5841-8480-b2fd-eeb7-ff2bf33a0e68@yandex.ru> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQImPQmOIF2vTGk0Xpwdmvzo8VZGvgK6MS7SArjuQ1ICjxCMUgKiBYpFAak6C6wB5+aSaQFv/gwsoBYcKOA= Content-Language: en-us X-Mailman-Approved-At: Mon, 23 Jan 2017 11:11:05 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128329 Archived-At: >> There are still issues with greater-than and less-than=20 >> as binary operators. > Inside XML literals, you mean? Yes, exactly. > How's your experience so far? It's actually worked very well. I had an issue once where indenting an = entire region took several passes to get right, but now I'm not able to = reproduce it :(=20 > Here's the problem: js-indent-line uses syntax-ppss.=20 > sgml-indent-line doesn't (for now), but js-jsx-indent-line=20 > calls js-indent-line in certain contexts. And this is a problem > because calling syntax-ppss in different contexts with=20 > incompatible (paren-wise) syntax tables will make=20 > syntax-ppss cache broken, and lead to likewise broken > behaviors. I'm not sure I'm grasping this part entirely. I understand conceptually = that using syntax-ppss with incompatible syntax tables could lead to = cache problems. But it seems to me that the js*-mode and sgml-*-mode = syntax tables are already incompatible (namely, "<" and ">", which are = causing all this grief!). Would introducing this additional = incompatibility cause more problems?=20 > So, one thing we could do here is let-bind the variables that=20 > constitute syntax-ppss cache around the call to orig-fun=20 > (i.e. around the context where we modify the syntax table). > ... (the cache is not really a public API) This sounds like a bit of a headache. E.g., indenting a region would = require binding and unbinding the cache carefully as you stepped into = and out of JSX. What if we just scrap the syntax-ppss cache altogether? = Would the performance penalty be too great? > Another, somewhat more difficult approach, would be to try > to apply the "<" and ">" syntax classes in=20 > syntax-propertize-function, only to occurrences of "{" and "}"=20 > inside XML literals. That would require knowing where the said > literals begin and end, but we do know that somehow already, > seeing as we know which indentation function to choose, right? This is based on a rough heuristic that essentially backtracks looking = for "[(,]\n *<" (it also handles comments). This misses any JSX which is = not at the start of the line, and it only tells us the start of the tag, = not the end or where the body ends. In js2 and rjsx there is of course = the full parser to give us this information.=20 > This way we don't depend on syntax-ppss internals, and reindenting > the whole buffer might be faster, because we would keep syntax-ppss=20 > cache around more. Still, not sure how much faster that would be in=20 > practice. I think we could use a regex like the following to identify JSX start = tokens: (rx (seq (or (any "-+*/%=3D>" = that close JSX tags: (rx (seq ">" (* whitespace) ; Should also skip over comments (or (any "-+*/%=3D>