Re: Handling extensions of programming languages (Perl)

[haj@posteo.de (Harald Jörg)]

[I've added "Perl" to the subject since this is going specific]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [...]

>> 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.

Nice.  How would the set of shared functions be distributed?  In a new,
separate file which both modes `require'?  That file would then also be
part of a CPerl distribution on ELPA, I guess?  In my opinion, it would
make sense in any case to use the "perl" prefix for shared stuff.

>> 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 ;-).

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.  CPerl mode abuses type-face for builtin functions, I
   wonder how much stir it makes if this is changed.

 - 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).

 - In cperl-mode, ':' is a symbol, but a punctuation character in
   perl-mode.  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.

>> 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`).

Ah, yes, of course.  I didn't think of that (nor read the docs).

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.

>> 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.

Thanks!
-- 
Cheers,
haj