From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: A possible way for CC Mode to resolve its sluggishness Date: Sun, 28 Apr 2019 09:32:25 -0800 Message-ID: <86y33u6no6.fsf@stephe-leake.org> References: <20190426193056.GC4720@ACM> <20190427135725.GB4822@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="266084"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 28 20:03:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hKo9Q-0016yq-50 for ged-emacs-devel@m.gmane.org; Sun, 28 Apr 2019 20:03:44 +0200 Original-Received: from localhost ([127.0.0.1]:47029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKo9P-0001WZ-3P for ged-emacs-devel@m.gmane.org; Sun, 28 Apr 2019 14:03:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKo7k-0000uO-5L for emacs-devel@gnu.org; Sun, 28 Apr 2019 14:02:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hKo7i-0008GA-Nk for emacs-devel@gnu.org; Sun, 28 Apr 2019 14:02:00 -0400 Original-Received: from gproxy3-pub.mail.unifiedlayer.com ([69.89.30.42]:59933) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hKo7i-0008FV-FN for emacs-devel@gnu.org; Sun, 28 Apr 2019 14:01:58 -0400 Original-Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id F291640204 for ; Sun, 28 Apr 2019 11:32:28 -0600 (MDT) Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmsmtp with ESMTP id KnfAhHIW3mds9KnfAhvMUO; Sun, 28 Apr 2019 11:32:28 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason Original-Received: from [76.77.182.20] (port=56177 helo=Takver4) by host114.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hKnfA-0012TD-Ir for emacs-devel@gnu.org; Sun, 28 Apr 2019 11:32:28 -0600 In-Reply-To: <20190427135725.GB4822@ACM> (Alan Mackenzie's message of "Sat, 27 Apr 2019 13:57:25 +0000") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host114.hostmonster.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 76.77.182.20 X-Source-L: No X-Exim-ID: 1hKnfA-0012TD-Ir X-Source-Sender: (Takver4) [76.77.182.20]:56177 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 1 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDExNC5ob3N0bW9uc3Rlci5jb20= X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.30.42 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:236007 Archived-At: Alan Mackenzie writes: >> Maybe if we want to speed things up, we should consider a new parsing >> engine (instead of parse-partial-sexp and syntax-tables) based maybe on >> a DFA for the tokenizer and GLR parser on top. That might arguably be >> more generally useful and easier to use (in the sense that one can more >> or less follow the language spec when implementing the major mode). > > That would be a lot of design and a lot of work, and sounds like > something from the distant rather than medium future. ada-mode uses just that approach; the WisiToken parser generator reads a bison-like description of the grammar, and generates a lexer and error-correcting parser. Those run in an Emacs background process, which also runs other code to process the AST and produce font and indent info, which is sent back to Emacs. It works very well for Ada code, and I've got a very preliminary version working with Java. See http://www.nongnu.org/ada-mode/ for the latest release. C++ is definitely more of a challenge; you need to run the preprocessor, at least. In another post Oscar says you would need a full C++ front-end; I can believe that. Still, the approach is similar; run the C++ front-end (maybe the clang one?) in a background process, together with code that computes the info needed by Emacs. One possible problem is that the parser needs to handle huge syntax errors; it will be called to compute indent when the user has entered a partial statement and hit return. I don't know how good clang is with error correction; I spent a lot of time making the WisiToken parser handle such errors well. > The indentation and font-lock routines would have to be rewritten > for each mode using it. Yes; I had to translate the elisp into Ada. Currently, I'm maintaining both (to support people who don't want to or can't compile the background process code), but at some point I'll probably drop the elisp. It is a huge redesign and implementation effort. I started this for Ada in 2013 when it became clear that the earlier ad-hoc approach could not handle Ada 95 and 2012 syntax, and it took several years (with several detours along the way; Java will take much less time). I'm almost at the point where I can delete the old ad-hoc ada-mode code from Emacs core. -- -- Stephe