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 16:48:53 +0100 Message-ID: <87blbc33tm.fsf@hajtower> References: <87o8ff560t.fsf@hajtower> <87im5lhi6i.fsf@rfc20.org> <87r1k94cnx.fsf@hajtower> <20a4ef1c-beaf-1d63-b984-12be9a856c86@gmail.com> <87h7l43fa1.fsf@hajtower> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24345"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 21 16:52:00 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 1lO0My-0006Be-0D for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 16:52:00 +0100 Original-Received: from localhost ([::1]:50118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO0Mx-0000n2-24 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 11:51:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO0K3-0007El-In for emacs-devel@gnu.org; Sun, 21 Mar 2021 11:49:00 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:46177) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO0K0-0001FU-Hq for emacs-devel@gnu.org; Sun, 21 Mar 2021 11:48:59 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 2F0D82400FC for ; Sun, 21 Mar 2021 16:48:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1616341734; bh=o89EKPvk9WA0SbgHge/MSGY+0l19XEvZ1cWYi+lEbQ8=; h=From:To:Cc:Subject:Date:From; b=PbQBchHlGeoxQYQXIsxfm+i05vsw3GPjkaNtrEC6cFhHEcUAxhFeADw0HG6lG8zxC bg0j5neAcx9nAzdyDFTb9DlDmghhSM7DZB3G/7kkA69dS7g44EWvcKI6nUBj/t2teR 9ty4Y8QoSY3Eh8+9i1wguGF6/8SIuQ06j1nLtiQRlbd9gH3hTZ3Z04yTTSzg+iWCuh 1bFBqsqNLyeq1hNxxbtbldb8pI3mcu499IJQxAm1YXrHNppHiMNUOUKPmDzn+Rr5eU A073VQ+uHgAkV8KI0qpl+qtfIYNRcFx81BHrkvhJs8NliICq8E1kfPogrBfTLJkLS0 VQqHlP+lIKMdA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4F3MVs32V3z9rxB; Sun, 21 Mar 2021 16:48:53 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Sun, 21 Mar 2021 08:39:12 -0400") 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:266712 Archived-At: Stefan Monnier writes: > [...] >> class Coffee::Machine extends Lawn::Mower >> { >> has $grinder :reader :writer(replace_grinder) >> method grind { ...; } >> } > [...] >> - add "Dishwasher" and "clean_up" to the imenu index. > > That seems to require AI (unless you're talking about a slightly > different example than the one quoted above ;-). Ouch. I goofed up when deleting stuff from my test file to make the example shorter :) I wanted to add "grind" instead of "clean_up". But, jokes aside: I actually consider adding entries to the imenu index _which aren't there._ In the example above, Object::Pad will silently create the methods `grinder' and `replace_grinder'. I think these *should* go to imenu because if your code in another source calls $cm->grinder you might otherwise have a hard time finding where that routine is declared. >> - make sure that indentation recognizes that the closing braces end a >> statement after "class" and "method". Perl syntax has various cases >> where it doesn't. I guess this is the part where SMIE would help. > > Actually, the closing brace which also closes a statement is one of the > major pain points in `sm-c-mode`, so it would be one of the parts where > you'd need extra work to make SMIE understand what's going on. Given the effort CPerl mode spends to distinguish these two I guessed so. There are some open bugs regarding indentation in CPerl mode (Bug#8077, Bug#11773, Bug#28640) which I'd like to fix while on the way. Also, a few days ago there was a discussion in the Perlmonks forum where CPerl mode guesses horribly wrong: https://www.perlmonks.org/?node_id=11129870 >> For the latter two tasks, I need to "hook" the logic somehow into >> CPerl's implementations of `imenu-create-index-function' and the various >> indentation functions. The current indentation code in CPerl mode >> is... a bit messy, and some old bugs call for attention anyway. > > AFAIK font-lock and imenu are easy. For font-lock there's > `font-lock-add-keywords` and for imenu, you should be able to make it > work fairly well with just `add-function` to > `imenu-create-index-function`. For certain values of easy :). But yes, that's the plan. The font-lock mechanism is indeed very powerful. For Object::Pad, the keyword declaration takes about 120 lines (in rx notation, which is rather wordy) - mostly due to the effort to avoid false positives. For imenu, adding regexps to the list of `or'ed expressions to search for seems to be an alternative. Or maybe it doesn't, if I want to add entries which can't be easily searched for. > For indentation, it's fundamentally harder (for the same reason that > combining two LALR grammars doesn't necessarily give you an LALR > grammar), so it will have to be done in a somewhat ad-hoc way. Indeed. Indentation needs more "context". > I suspect that if the base mode uses SMIE, it would make it > significantly easier to add extensions (because the structure of SMIE > imposes constraints that expose the "compositional" aspect of the > grammar, in some sense), but that's not what you have to work with > currently, so you're going to have to dig into the indentation code and > try and figure out how to make it work with your extension(s) and then > how to express the changes "from outside" (e.g. by using hooks, > `add-function`, or `advice-add`; we can of course add hooks > to `cperl-mode.el` or `perl-mode.el` to make that easier). Your last parens touch another interesting aspect: Can that stuff be used by cperl-mode.el _and_ perl-mode.el? Well, as it turns out, the font-lock stuff "works" for both. It looks a bit weird with Perl mode because the "new" keywords like `method' have different faces than the "old" ones like `my'. For imenu, things are different: Perl mode uses `imenu-generic-expression', whereas CPerl mode uses a rather complex `imenu-create-index-function ', so that it can prepend the current namespace to the name of functions. And as for indentation... I'd say the code in both modes needs to catch up with current perl before we consider extensions. Maybe they could share functions or regular expressions how to find the beginning of a function, or how to identify closing braces which terminate a statement: The specification for this logic comes from Perl and should be the same for both modes. -- Cheers, haj