unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: haj@posteo.de (Harald Jörg)
Cc: emacs-devel@gnu.org
Subject: Re: Handling extensions of programming languages
Date: Sun, 21 Mar 2021 13:59:29 -0400	[thread overview]
Message-ID: <jwvh7l4wgad.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87blbc33tm.fsf@hajtower> ("Harald Jörg"'s message of "Sun, 21 Mar 2021 16:48:53 +0100")

> 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




  reply	other threads:[~2021-03-21 17:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 18:53 Handling extensions of programming languages Harald Jörg
2021-03-20 17:02 ` Matt Armstrong
2021-03-20 23:40   ` Harald Jörg
2021-03-21  2:18     ` Clément Pit-Claudel
2021-03-21 11:41       ` Harald Jörg
2021-03-21 12:39         ` Stefan Monnier
2021-03-21 15:48           ` Harald Jörg
2021-03-21 17:59             ` Stefan Monnier [this message]
2021-03-22 14:08               ` Handling extensions of programming languages (Perl) Harald Jörg
2021-03-22 14:48                 ` Stefan Monnier
2021-03-22 17:32                   ` Harald Jörg
2021-03-22 18:27                     ` Stefan Monnier
2021-03-22 19:31                       ` Harald Jörg
2021-03-22 19:58                         ` [OFFTOPIC] " Stefan Monnier
2021-03-22 22:05                           ` Harald Jörg
2021-03-22 22:24                             ` Stefan Monnier
2021-03-22 23:43                               ` Harald Jörg
2021-03-23  3:49                                 ` [OFFTOPIC] " Stefan Monnier
2021-03-30 18:41             ` Handling extensions of programming languages Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvh7l4wgad.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=haj@posteo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).