From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Handling extensions of programming languages Date: Sun, 21 Mar 2021 13:59:29 -0400 Message-ID: References: <87o8ff560t.fsf@hajtower> <87im5lhi6i.fsf@rfc20.org> <87r1k94cnx.fsf@hajtower> <20a4ef1c-beaf-1d63-b984-12be9a856c86@gmail.com> <87h7l43fa1.fsf@hajtower> <87blbc33tm.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="28646"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: haj@posteo.de (Harald =?windows-1252?Q?J=F6rg?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 21 19:03:38 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 1lO2QM-0007Jw-1V for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 19:03:38 +0100 Original-Received: from localhost ([::1]:52226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO2QK-0002fR-VU for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 14:03:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO2MS-0001kQ-Eh for emacs-devel@gnu.org; Sun, 21 Mar 2021 13:59:36 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO2MP-0007fN-RE for emacs-devel@gnu.org; Sun, 21 Mar 2021 13:59:35 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DFF6B4402B2; Sun, 21 Mar 2021 13:59:32 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 425AB44062E; Sun, 21 Mar 2021 13:59:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616349571; bh=nXpVD2QotkZJKNsk2J95M55rC7hydSSv8kC7hHguRK4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Wp4CmIXO5wk1azH9fI+ThYi+dV1L82t0QmbAr5kk90Xug0sdCTqByM9nk7+HF1xIE hH+53+vvKA3CV3NRx3s/icZveUTxh7OZkoMYMaq6p6mDISvI6CAkZmbC5eAe5xzySU txB68+06Bm5gYs3rstXuv2Dr6zyqpbfJx1v7Z2calwRh/D2K4n3KsHTw47zNGSaBz/ JI7dcNL0rnGqG/01LaScxPNa+lsVUzOT2NV0Tvt5Y+k3K7LygU7ozaH5c71lfCpWKI B6OePdkj7rJrxJUY5wMgdNrbJf6o7ijShRb1DxshJ5SIs0TCE4eoSw565GUm3jB85w 7BN9bBJuHtsYQ== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C5B8E1203FF; Sun, 21 Mar 2021 13:59:30 -0400 (EDT) In-Reply-To: <87blbc33tm.fsf@hajtower> ("Harald =?windows-1252?Q?J=F6rg=22?= =?windows-1252?Q?'s?= message of "Sun, 21 Mar 2021 16:48:53 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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:266716 Archived-At: > 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. I don't see any problem with that. You could even argue that they *are* there. >>> 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 :). I meant "easy" in the sense that once you've figured out how to match those constructs and how to put the right face on the various parts, adding it modularly (e.g. from a minor mode) should be reasonably easy, because it shouldn't interact in too complex ways with the rest of the font-lock rules. > Your last parens touch another interesting aspect: Can that stuff be > used by cperl-mode.el _and_ perl-mode.el? For imenu and font-lock, I can't see why not. > 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'. I'm not sure why that would be: AFAICT, both `perl-mode` and `cperl-mode` highlight keywords (like `sub`, `if`, `for`, ...) using the `font-lock-keyword-face` (they generally use fairly different faces, but this is a part where they agree ;-). > 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. If you code uses `add-function` on `imenu-create-index-function` it should work in both cases (`perl-mode` simply keeps the default value of `imenu-create-index-function` which is the function that implements `imenu-generic-expression`). > 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. Consolidation between the two modes is progress, so you got my vote. Stefan