Re: Handling extensions of programming languages (Perl)

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

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

>>> For imenu and font-lock, I can't see why not.
>> Nice.
>
> Beware: I might just be blinded by optimism.

Optimism is my second name!  (My first name is "Unwarranted")

>> 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 would prefer this behavior (not being able to disable it) for things
that come with new Perl versions, but not for extensions.  If you run an
older Perl version (which happens all the time because distributions
take time to catch up) it might behave strange, but I think that this is
ok as a reminder that "at some time you will need to change this
anyway".

For extensions it is really difficult to find out whether they might
collide with another extension.  Sometimes new extensions quickly rise
in popularity but need different handling.  A typical example is
exception handling with Try::Tiny which is lightweight and nice and all,
but it comes with the pitfall that the try block, different from all
other extensions for exception handling with try/catch/finally,
_requires_ a semicolon.

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

I've been hoping that this is acceptable.  It brings a lot of
infrastructure and therefore consistency for users.

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

I am leaning towards a completely separate file, but maybe not right
now.  In both cases the adventurous users who're using cperl-mode
directly from the repository will then need to pick two files instead of
one.  If, one day, cperl-mode is made available via ELPA, this should
not necessary require moving perl-mode to elpa as well.

>> [...about discrepancies in syntax highlighting ...]
>
> I think such discrepancies are just misfeatures, so it would be nice to
> fix them (ideally by choosing that one that seems less arbitrary).

Agreed.

> Using type-face for `my` or `local` doesn't seem useful, so we
> should probably change them to keyword.

That was my first thought as well.  But then, the declarators appear in
places where other languages have their types.  And then again, there
are (various, of course) Perl extensions which provide a type system
for Perl, so you can write "my Str $string" or even "my ArrayRef[Int] $ref".

I guess I need to *see* it for some time to find out whether in "my Str"
both parts should have the same color or better shouldn't.

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

I agree.  CPerl mode uses different faces for "overridable" and
"nonoverridable" builtins, but this distinction isn't that valuable
these days (and it also changes between Perl versions).  I've also
received feedback that this distinction should go away.  IIRC the
non-"standard" colors of CPerl mode occasionally annoyed people which
use Emacs with many different programming languages.

> [...]
>>  - 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.
>
>> [...]
>
> 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".  ]

Good point!  For the moment I'll be a coward and avoid that decision by
honing the regular expressions with that differnce in mind :)

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

That's probably an acceptable way forward.

Time to roll up my sleeves ... and grab some more coffee.
-- 
Cheers,
haj