From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: haj@posteo.de (Harald =?utf-8?Q?J=C3=B6rg?=) Newsgroups: gmane.emacs.devel Subject: Re: Handling extensions of programming languages Date: Sun, 21 Mar 2021 00:40:18 +0100 Message-ID: <87r1k94cnx.fsf@hajtower> References: <87o8ff560t.fsf@hajtower> <87im5lhi6i.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14621"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: Emacs Developer List To: Matt Armstrong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 21 00:41:26 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lNlDi-0003jS-HQ for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 00:41:26 +0100 Original-Received: from localhost ([::1]:46490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNlDh-0001t8-J2 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Mar 2021 19:41:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNlCk-0001NY-IG for emacs-devel@gnu.org; Sat, 20 Mar 2021 19:40:26 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45473) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNlCh-0001D2-5w for emacs-devel@gnu.org; Sat, 20 Mar 2021 19:40:26 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 903CF2400FC for ; Sun, 21 Mar 2021 00:40:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1616283619; bh=zds1++qWDMrhXDLUTat7YRLTyfTNi1JNnEhzUZrofUQ=; h=From:To:Cc:Subject:Date:From; b=rt+19NC/M139czetlOJB2hpb5vN++Xn0cpd0YSXZCxV3XRfBBgmmFZOqdTcjoo2GY ZFNPgTmE6kwskUfh8Q5qQsEHUgQ9hlg2azug0cCTTLo/TRoQzigHS5WcI0zk91ehNa 3vWm5aGMVblEi1dF553MoEUs28DXC8yhOSfc1X/PC/YsS78DU1zFzkXD0SWTHTkXFx wKlmGxjiorvJ2d5rI26xFiFqeEYaUSDzhElGVx8rA2k8ltFFZWkB6/Mxe62jxrW0ss nn/6gKjxEKQU/OnEsPp22OW+YhWRcxJ2TPCMVgiNILIHhMshkAzdFIaER1Iz0+quXa BX/0el9tbgUww== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4F2y1G4q35z6tmN; Sun, 21 Mar 2021 00:40:18 +0100 (CET) In-Reply-To: <87im5lhi6i.fsf@rfc20.org> (Matt Armstrong's message of "Sat, 20 Mar 2021 10:02:45 -0700") Received-SPF: pass client-ip=185.67.36.66; envelope-from=haj@posteo.de; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266680 Archived-At: Matt Armstrong writes: > I'm not an expert in this topic it pertains to Emacs itself, but I've > always editor and development tools interesting and so have paid > attention to these issues over the years. Thanks for sharing your insights! > [...] > Very good Emacs support for languages with flexible syntax, which have a > high level of faithfulness to the language, or even "perfect" > faithfulness, all seem to rely on tools native to the language and > external to Emacs, usually by way of some sort of external server. > [...] The common theme seems to be using the interpreter/compiler > itself to parse, without relying on the editor to understand the code > deeply. This is fine. For Perl, this has some limitations since you actually need to run parts of the code to find out whether it compiles (or, more precise, whether it can be interpreted correctly). This might be undesired, e.g. for security reasons with "unknown" code. > For a different approach, you have examples of complete or nearly > complete parsers written in Emacs Lisp. > [...] > The drawback here is that, by design, any syntax extensions and > local mini-DSLs, etc., must also have parsers written in Emacs Lisp. Exactly! "How hard can that be?" -- Damian Conway, in a presentation which shows, among other tricks, a ~2000-line Perl regular expression which matches (not actually parses) Perl code. I *guess* that Emacs Lisp is well suited for a pragmatic/heuristic approach, and I want to give it a try. > (info "(ccmode)Custom Macros") is an example of how cc-mode supports a > limited form of syntax extension. Many thanks! This is the sort of pointers I'm after. I'll take a look how this is implemented. > I think most modes in Emacs Lisp take a pragmatic approach, using > heuristics that get the job done most of the time without being too > computationally expensive. The SMIE package is a generalization of this > idea, see (info "(elisp)SMIE"). > I am not aware of anything like SMIE that allows for languages > extensions to be "plugged in" in a general way. Well, I have my doubts that Perl is a good candidate for SMIE, and trying to use SMIE in CPerl mode would be a major rewrite anyway. I guess the Emacs Losp basics (font-lock-add-keyword, hooks) will have to do the job. -- Cheers, and again thanks for your time, haj