From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jackson Ray Hamilton Newsgroups: gmane.emacs.bugs Subject: bug#24896: JSX prop indentation after fat arrow Date: Mon, 23 Jan 2017 09:07:17 -0800 Message-ID: <5efb9de2-47cb-3843-1521-9252e1a49005@jacksonrayhamilton.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> <004301d2755a$b9f62b30$2de28190$@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1485191295 30362 195.159.176.226 (23 Jan 2017 17:08:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2017 17:08:15 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 Cc: 24896@debbugs.gnu.org To: Felipe Ochoa , 'Dmitry Gutov' , 'Felipe Ochoa' Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 23 18:08:09 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 1cVi6D-0007Qq-0S for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jan 2017 18:08:09 +0100 Original-Received: from localhost ([::1]:43375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVi6I-0008BW-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jan 2017 12:08:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVi6A-00086d-ET for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 12:08:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVi66-0002HM-0P for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 12:08:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41116) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVi65-0002H0-UC for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 12:08:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cVi65-0003P6-MT for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2017 12:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jackson Ray Hamilton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2017 17:08:01 +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.148519125013044 (code B ref 24896); Mon, 23 Jan 2017 17:08:01 +0000 Original-Received: (at 24896) by debbugs.gnu.org; 23 Jan 2017 17:07:30 +0000 Original-Received: from localhost ([127.0.0.1]:39315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVi5a-0003OK-HK for submit@debbugs.gnu.org; Mon, 23 Jan 2017 12:07:30 -0500 Original-Received: from mta-05-3.privateemail.com ([68.65.122.15]:59867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVi5X-0003O3-C0 for 24896@debbugs.gnu.org; Mon, 23 Jan 2017 12:07:28 -0500 Original-Received: from [10.0.0.16] (unknown [10.20.151.244]) by MTA-05.privateemail.com (Postfix) with ESMTPA id 654D860040; Mon, 23 Jan 2017 17:07:18 +0000 (UTC) X-Enigmail-Draft-Status: N1110 In-Reply-To: <004301d2755a$b9f62b30$2de28190$@gmail.com> 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:128330 Archived-At: Hi Felipe, Regarding, > 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. Please note Dmitry's comment: https://github.com/mooz/js2-mode/issues/140#issuecomment-40887172, > As for indentation . . . there's a question how one would determine whether point is inside an XML expression (and expression's bounds) without using the AST (using it was rejected in the past on the grounds of that being slow). And see here for my explanation of that design: https://github.com/mooz/js2-mode/issues/140#issuecomment-145325361 Feel free the improve upon this algorithm, although do take care to benchmark the code before and after your changes, with buffers of various sizes. Large files won't hold up well if using an AST for indentation. Probably better to extend the current heuristic to be more accurate. Jackson On 01/23/2017 01:26 AM, Felipe Ochoa wrote: >>> There are still issues with greater-than and less-than >>> 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 :( > >> Here's the problem: js-indent-line uses syntax-ppss. >> sgml-indent-line doesn't (for now), but js-jsx-indent-line >> calls js-indent-line in certain contexts. And this is a problem >> because calling syntax-ppss in different contexts with >> incompatible (paren-wise) syntax tables will make >> 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? > >> So, one thing we could do here is let-bind the variables that >> constitute syntax-ppss cache around the call to orig-fun >> (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 >> syntax-propertize-function, only to occurrences of "{" and "}" >> 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. > >> This way we don't depend on syntax-ppss internals, and reindenting >> the whole buffer might be faster, because we would keep syntax-ppss >> cache around more. Still, not sure how much faster that would be in >> practice. > > I think we could use a regex like the following to identify JSX start tokens: > > (rx (seq (or (any "-+*/%=> (seq (or "return" "typeof" "delete" "instanceof") whitespace) > (any "([{,;")) > (* whitespace) ; Should also skip over comments > "<")) > > I.e., any "<" after an operator or at the beginning of an expression or statement. We'd have to filter out some false positives (postfix ++ and --, strings, and comments, possibly others), but this would get all the JSX start tags, I think. We could use a similar regex to find the ">" that close JSX tags: > > (rx (seq ">" > (* whitespace) ; Should also skip over comments > (or (any "-+*/%=> (seq (or "return" "typeof" "delete" "instanceof") whitespace) > (any "(}],;")) > > Not sure how to go from there to the "{" and "}" tokens though. Is it possible to run syntax-ppss using different tables for different parts of the buffer? >