Re: Handling extensions of programming languages (Perl)

[Stefan Monnier]

>> For imenu and font-lock, I can't see why not.
> Nice.

Beware: I might just be blinded by optimism.

> How would the set of shared functions be distributed?

Good question.  I guess it largely depends on the size, the way you
intend to distribute it, the possible bad interaction with other Perl
extensions, ...

E.g. for an extension which doesn't collide with any other known Perl
extension, you could imagine enabling it by default (and maybe even
forego offering a way to disable it).

I think the most natural/convenient form of an extension that can be
enabled or not would be as a minor mode.

And as for where to put the code, it could be in a completely separate
file, or directly in `perl-mode.el` (which `cperl-mode.el` could
require: it's a mere 50kB compared to `cperl-mode.el`s 300kB).

> Overall they agree, but there are differences in details (some might
> even be unintended).  For new keywords and syntax there's indeed no need
> to use different faces, but they should be somewhat consistent to
> existing highlighting.  Some results from first tests and debugging:
>
>  - Declarators (like "my") are type-face in perl-mode, keyword-face in
>    cperl-mode.  I noticed this because the new "has" is fontified by
>    perl-mode (though it isn't part of Perl) and the additions don't
>    override it.

I think such discrepancies are just misfeatures, so it would be nice to
fix them (ideally by choosing that one that seems less arbitrary).
Using type-face for `my` or `local` doesn't seem useful, so we
should probably change them to keyword.

>    CPerl mode abuses type-face for builtin functions, I
>    wonder how much stir it makes if this is changed.

Try it ;-)
Unsurprisingly, I vote for using the font-lock-builtin-face for them.

>  - Names of packages are not fontified in perl-mode when they are `use'd
>    or `require'd (on closer inspection, this is probably unintended: The
>    first capture group is either an empty string or punctuation/space
>    and should be shy).

Sounds like a bug, indeed.

>  - In cperl-mode, ':' is a symbol, but a punctuation character in perl-mode.

Ah, right, this could make it significantly harder to share code between
the two major modes.  I don't think either choice is clearly superior,
but we should make them agree on the syntax-table.

>    This makes interpretation of "\\_<" different.  Perhaps changing
>    cperl-mode's syntax table to making ':' punctuation would be the
>    way to go - but punctuation also has its deficits for perl-mode, as
>    apparent in "package Foo::Bar", so i would need more work.
>    I haven't investigated further.

I suspect it can also impact other parts of the code (since it impacts
things like `forward-sexp`).  I think my recommendation would be to
change `perl-mode` to agree with `cperl-mode` since `perl-mode.el` is
much smaller so the amount of breakage should be correspondingly smaller.
[ Also, from a user's point of view it's good that `C-M-x` skips over the
  whole of "Foo::bar" instead of stopping after "Foo".  ]

> The two modes have different styles how they present their results,
> though.  Adding new entries needs some "rearrangement" to put it into
> the right place(s) in the index.

Then again, you could focus on making it "work well" for one of the modes
(presumably `cperl-mode`) and content yourself with "works" for the
other ;-)


        Stefan