Please do not deprecate perl-mode in favour of cperl-mode

Please do not deprecate perl-mode in favour of cperl-mode

[Paul W. Rankin via Emacs development discussions.]

Hello,

I am writing in response to a mention I saw today on Mastodon, which 
appears supported by the EtherPad, that there is plan to deprecate Perl 
Mode in favour of C Perl Mode in Emacs.

If this is true can I please urge a reconsideration?

C Perl Mode has several quirks that make it behave unlike a normal Emacs 
Major mode, including:

- unorthodox code indentation
- behaviour of TAB on region does not perform indent-region
- use of specific faces instead of font-lock-* faces

(Perl Mode, meanwhile, works just fine.)

I don't wish to dampen the enthusiasm of the originator of this Perl->C 
Perl idea, but I would implore you to please first address C Perl Mode's 
shortcoming as a 1:1 replacement for Perl Mode before the 
baby/bathwater? C Perl Mode should at least work as well as Perl Mode 
before deprecation is considered.

Gracious thanks,

-- 
Paul W. Rankin
https://www.paulwrankin.com

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Eli Zaretskii]

> Date: Sun, 03 Dec 2023 16:36:10 +1000
> From:  "Paul W. Rankin" via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> I am writing in response to a mention I saw today on Mastodon, which 
> appears supported by the EtherPad, that there is plan to deprecate Perl 
> Mode in favour of C Perl Mode in Emacs.
> 
> If this is true can I please urge a reconsideration?
> 
> C Perl Mode has several quirks that make it behave unlike a normal Emacs 
> Major mode, including:
> 
> - unorthodox code indentation
> - behaviour of TAB on region does not perform indent-region
> - use of specific faces instead of font-lock-* faces

What if CPerl mode would optionally support the above as well?  Would
it be acceptable then for you to switch?

> I don't wish to dampen the enthusiasm of the originator of this Perl->C 
> Perl idea, but I would implore you to please first address C Perl Mode's 
> shortcoming as a 1:1 replacement for Perl Mode before the 
> baby/bathwater? C Perl Mode should at least work as well as Perl Mode 
> before deprecation is considered.

Deprecation doesn't mean removal.  Even obsolete packages are still
available, and some of them will not be removed.  So if you insist on
using Perl mode, you will be able to do so for the years to come, even
if we deprecate and obsolete it.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Paul W. Rankin via Emacs development discussions.]

On 2023-12-03 17:07, Eli Zaretskii wrote:
>> C Perl Mode has several quirks that make it behave unlike a normal 
>> Emacs
>> Major mode, including:
>> 
>> - unorthodox code indentation
>> - behaviour of TAB on region does not perform indent-region
>> - use of specific faces instead of font-lock-* faces
> 
> What if CPerl mode would optionally support the above as well?  Would
> it be acceptable then for you to switch?

I would love to take advantage of whatever CPerl Mode advantages exist 
if CPerl Mode could do the things that Perl Mode does. And I think it 
should be easy and clear to the user how to set these options.

Here's a minimal example of perl code that indents in a way I find 
unexpected in CPerl Mode (e.g. the trailing paren should line up with 
the start of the statement):

     $r->get(
         '/test'
        );


I also found weird behaviour with Electric Pair Mode; when point is at 
`|' here and `{' is inserted, I get `{|}}', which seems incorrect 
because it unbalances the braces (Perl Mode inserts `{|}'):

     $r->get(
         '/test',
         sub {
             |
         }
     );

One more thing...

CPerl Mode has a feature the applies the `underline' face to leading 
whitespace before point and there doesn't appear to be an option to 
disable this. It's not a huge thing, but Whitespace Mode provides this 
feature and it's just a weird addition to hardcode and not use something 
called `cperl-leading-whitespace-face'.

>> I don't wish to dampen the enthusiasm of the originator of this 
>> Perl->C
>> Perl idea, but I would implore you to please first address C Perl 
>> Mode's
>> shortcoming as a 1:1 replacement for Perl Mode before the
>> baby/bathwater? C Perl Mode should at least work as well as Perl Mode
>> before deprecation is considered.
> 
> Deprecation doesn't mean removal.  Even obsolete packages are still
> available, and some of them will not be removed.  So if you insist on
> using Perl mode, you will be able to do so for the years to come, even
> if we deprecate and obsolete it.

This is cool. My opinion is that CPerl Mode is (currently) too weird and 
idiosyncratic to be Emacs's default mode for perl (e.g. what the heck is 
`cperl-hairy' or `cperl-fontify-m-as-s'?) and will likely lead to more 
confusion than productivity/joy. But maybe if someone wants to take a 
hard look at CPerl Mode from a user friendliness perspective?

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Eli Zaretskii]

> Date: Sun, 03 Dec 2023 18:21:19 +1000
> From: "Paul W. Rankin" <hello@paulwrankin.com>
> Cc: Emacs-devel@gnu.org
> 
> On 2023-12-03 17:07, Eli Zaretskii wrote:
> >> C Perl Mode has several quirks that make it behave unlike a normal 
> >> Emacs
> >> Major mode, including:
> >> 
> >> - unorthodox code indentation
> >> - behaviour of TAB on region does not perform indent-region
> >> - use of specific faces instead of font-lock-* faces
> > 
> > What if CPerl mode would optionally support the above as well?  Would
> > it be acceptable then for you to switch?
> 
> I would love to take advantage of whatever CPerl Mode advantages exist 
> if CPerl Mode could do the things that Perl Mode does. And I think it 
> should be easy and clear to the user how to set these options.
> 
> Here's a minimal example of perl code that indents in a way I find 
> unexpected in CPerl Mode (e.g. the trailing paren should line up with 
> the start of the statement):
> 
>      $r->get(
>          '/test'
>         );
> 
> 
> I also found weird behaviour with Electric Pair Mode; when point is at 
> `|' here and `{' is inserted, I get `{|}}', which seems incorrect 
> because it unbalances the braces (Perl Mode inserts `{|}'):
> 
>      $r->get(
>          '/test',
>          sub {
>              |
>          }
>      );
> 
> One more thing...
> 
> CPerl Mode has a feature the applies the `underline' face to leading 
> whitespace before point and there doesn't appear to be an option to 
> disable this. It's not a huge thing, but Whitespace Mode provides this 
> feature and it's just a weird addition to hardcode and not use something 
> called `cperl-leading-whitespace-face'.

I encourage you to submit bug reports against CPerl mode about these
issues.  This could facilitate their eventual resolution.

> > Deprecation doesn't mean removal.  Even obsolete packages are still
> > available, and some of them will not be removed.  So if you insist on
> > using Perl mode, you will be able to do so for the years to come, even
> > if we deprecate and obsolete it.
> 
> This is cool. My opinion is that CPerl Mode is (currently) too weird and 
> idiosyncratic to be Emacs's default mode for perl (e.g. what the heck is 
> `cperl-hairy' or `cperl-fontify-m-as-s'?) and will likely lead to more 
> confusion than productivity/joy.

My understanding is that many users of Perl are quite happy with CPerl
mode as it is now.

> But maybe if someone wants to take a hard look at CPerl Mode from a
> user friendliness perspective?

I think it is quite possible to provide the behavior you'd like to see
as options, if not as the default.  We don't need everyone to agree on
the "correct" and "friendly" behavior, as long as everyone can get the
behavior they want, given some customization.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Emanuel Berg]

Eli Zaretskii wrote:

>> But maybe if someone wants to take a hard look at CPerl
>> Mode from a user friendliness perspective?
>
> I think it is quite possible to provide the behavior you'd
> like to see as options, if not as the default. We don't need
> everyone to agree on the "correct" and "friendly" behavior,
> as long as everyone can get the behavior they want, given
> some customization.

That's the right approach! Merge as much as possible into the
default, what cannot be merged into that can be made an
option. When no more merging in any way can be done, how much
do they really differ? If they actually do differ at that
point, I'm sure both can still be provided in one way
or another.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Harald Jörg]

Paul W. Rankin writes:

> I am writing in response to a mention I saw today on Mastodon, which
> appears supported by the EtherPad, that there is plan to deprecate
> Perl Mode in favour of C Perl Mode in Emacs.
>
> If this is true can I please urge a reconsideration?

A better description would be: deprecate perl-mode.el in favour of
cperl-mode.el.  It is not intended to make M-x perl-mode go away, but to
implement its look and feel with cperl-mode.el.

The main motivation for this that maintaining two modes to keep up with
changes in Perl syntax is not very efficient.

> C Perl Mode has several quirks that make it behave unlike a normal
> Emacs Major mode, including:
>
> - unorthodox code indentation
> - behaviour of TAB on region does not perform indent-region
> - use of specific faces instead of font-lock-* faces

This is exactly why comments like yours are welcome: I want to know
which of the differences are annoying for users of Perl mode.

In particular:

 - Code indentation: Both Perl mode and CPerl mode offer several user
   options to affect indentation (too many of them in CPerl mode IMHO).
   I am confident that it is possible to mimick Perl mode's default
   indentation by options.  Concrete examples are very welcome (like
   those you provided with your next reply).  They will make it into the
   test suite.

 - TAB for indenting region: That's also something that should be
   doable.  CPerl mode's behaviour for indent-region is indeed very
   idiosyncratic (and underdocumented).

 - use of specific faces: This will be fixed in CPerl mode anyway,
   independent of the deprecation.  This doesn't mean that the rich
   coloration which some people like will go away, but that all faces
   will default to font-lock-* faces if cperl-mode.el starts in Perl
   mode style.

> (Perl Mode, meanwhile, works just fine.)

Perl Mode works fine for many applications - but it also has a list of
deficiencies (and a list of open bugs, some of them pretty old).

> I don't wish to dampen the enthusiasm of the originator of this
> Perl->C Perl idea, but I would implore you to please first address C
> Perl Mode's shortcoming as a 1:1 replacement for Perl Mode before the 
> baby/bathwater? C Perl Mode should at least work as well as Perl Mode
> before deprecation is considered.

That's exactly what I'm trying to do these days.  It will take some
time, since it isn't the only project Im working on :/
-- 
Cheers,
haj

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Harald Jörg]

"Paul W. Rankin" via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> On 2023-12-03 17:07, Eli Zaretskii wrote:
>>> C Perl Mode has several quirks that make it behave unlike a normal
>>> Emacs
>>> Major mode, including:
>>> - unorthodox code indentation
>>> - behaviour of TAB on region does not perform indent-region
>>> - use of specific faces instead of font-lock-* faces
>> What if CPerl mode would optionally support the above as well?
>> Would
>> it be acceptable then for you to switch?
>
> I would love to take advantage of whatever CPerl Mode advantages exist
> if CPerl Mode could do the things that Perl Mode does. And I think it 
> should be easy and clear to the user how to set these options.
>
> Here's a minimal example of perl code that indents in a way I find
> unexpected in CPerl Mode (e.g. the trailing paren should line up with 
> the start of the statement):
>
>     $r->get(
>         '/test'
>        );

This is how Perl mode indents it, isn't it?

CPerl mode has several predefined indentation styles, a recent addition
is to indent according to Damian Conway's "Perl Best Practices".  This
can be activated with (cperl-set-style "PBP").  It _should_ be the
default these days, but it isn't for compatibility reasons.  in PBP
style, indentation is like this:

    $r->get(
        '/test'
    );

> I also found weird behaviour with Electric Pair Mode; when point is at
> `|' here and `{' is inserted, I get `{|}}', which seems incorrect 
> because it unbalances the braces (Perl Mode inserts `{|}'):
>
>     $r->get(
>         '/test',
>         sub {
>             |
>         }
>     );

This would indeed be a bug.  Unfortunately, I can not reproduce it.  If
you have a recipe to demonstrate the bug, then a bug report would be
welcome!

> One more thing...
>
> CPerl Mode has a feature the applies the `underline' face to leading
> whitespace before point and there doesn't appear to be an option to
> disable this. It's not a huge thing, but Whitespace Mode provides this
> feature and it's just a weird addition to hardcode and not use
> something called `cperl-leading-whitespace-face'.

This seems to have been fixed already by Stefan Kangas.  It used to be
the customizable face `cperl-invalid-face' but is gone now, in favor of
the option `show-trailing-whitespace'.

>>> I don't wish to dampen the enthusiasm of the originator of this
>>> Perl->C
>>> Perl idea, but I would implore you to please first address C Perl
>>> Mode's
>>> shortcoming as a 1:1 replacement for Perl Mode before the
>>> baby/bathwater? C Perl Mode should at least work as well as Perl Mode
>>> before deprecation is considered.
>> Deprecation doesn't mean removal.  Even obsolete packages are still
>> available, and some of them will not be removed.  So if you insist on
>> using Perl mode, you will be able to do so for the years to come, even
>> if we deprecate and obsolete it.
>
> This is cool. My opinion is that CPerl Mode is (currently) too weird
> and idiosyncratic to be Emacs's default mode for perl (e.g. what the
> heck is `cperl-hairy' or `cperl-fontify-m-as-s'?) and will likely lead
> to more confusion than productivity/joy. But maybe if someone wants to
> take a hard look at CPerl Mode from a user friendliness perspective?

I find the documentation of `cperl-hairy' and its customization
interface not too bad - but I am the wrong person to ask.

Anyways: CPerl mode has accumulated lots of options over the years.
Many of them, for example `cperl-fontify-m-as-s', can be safely ignored
and left at their defaults.

We will have more options to allow CPerl mode to look like Perl mode.
`cperl-fontify-trailer' is the first of the new options, to account for
the different treatment of text after __END__ or __DATA__ tokens.
-- 
Cheers,
haj

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Paul W. Rankin via Emacs development discussions.]

Hello and very sorry for the lateness of my reply! I will respond 
inline...

On 2023-12-03 23:20, Harald Jörg wrote:
> This is how Perl mode indents it, isn't it?
> 
> CPerl mode has several predefined indentation styles, a recent addition
> is to indent according to Damian Conway's "Perl Best Practices".  This
> can be activated with (cperl-set-style "PBP").  It _should_ be the
> default these days, but it isn't for compatibility reasons.  in PBP
> style, indentation is like this:
> 
>     $r->get(
>         '/test'
>     );

Ah this is excellent. "PBP" is indeed how I assume Perl should be 
indented. But how do I set this as a user option, i.e. M-x 
customize-option? I think M-x cperl-set-style is not easily discoverable 
(i.e. I didn't find it). For my own packages I encourage user discovery 
through M-x customize-group, but I think here cperl-set-style would 
remain elusive...

Still on indentation, the main way CPerl Mode bumps me out of things is 
that it doesn't indent the current region (like other programming 
modes), only the current line. If CPerl Mode would indent the region on 
TAB with "PBP" that would go a long way to making it feel more 
approachable.

>> I also found weird behaviour with Electric Pair Mode; when point is at
>> `|' here and `{' is inserted, I get `{|}}', which seems incorrect
>> because it unbalances the braces (Perl Mode inserts `{|}'):
>> 
>>     $r->get(
>>         '/test',
>>         sub {
>>             |
>>         }
>>     );
> 
> This would indeed be a bug.  Unfortunately, I can not reproduce it.  If
> you have a recipe to demonstrate the bug, then a bug report would be
> welcome!

I narrowed this down to having electric-pair-inhibit-predicate set to 
electric-pair-conservative-inhibit. I can't remember the reason I set 
this. I guess it's only a bug if this is not as intended with that 
option set.

>> One more thing...
>> 
>> something called `cperl-leading-whitespace-face'.
> 
> This seems to have been fixed already by Stefan Kangas.  It used to be
> the customizable face `cperl-invalid-face' but is gone now, in favor of
> the option `show-trailing-whitespace'.

Cool. In general where CPerl mode departs from convention I think it 
would be greatly appreciated to have an option to reign it back in ;)

> I find the documentation of `cperl-hairy' and its customization
> interface not too bad - but I am the wrong person to ask.
> 
> Anyways: CPerl mode has accumulated lots of options over the years.
> Many of them, for example `cperl-fontify-m-as-s', can be safely ignored
> and left at their defaults.
> 
> We will have more options to allow CPerl mode to look like Perl mode.
> `cperl-fontify-trailer' is the first of the new options, to account for
> the different treatment of text after __END__ or __DATA__ tokens.

Brilliant.

Something that may warrant a separate bug report is CPerl Mode's 
departure from the use of font-lock-* faces in a few key faces. The big 
advantage of sticking with the font-lock-* faces is that a user can more 
or less define their own theme just by customizing these faces. The 
faces in question are:

cperl-array-face
cperl-hash-face
cperl-nonoverridable-face

Each of which I think could benefit from instead inheriting from a 
font-lock-* face by default, to make things look a little more 
aesthetically pleasing. That said, I don't know which font-lock-* face 
is most appropriate, maybe combinations e.g. 
font-lock-variable-name-face plus bold plus underline.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Paul W. Rankin via Emacs development discussions.]

Very sorry I seem to have lost track of the thread and some issues I 
raised you've already addressed here.

On 2023-12-03 20:10, Harald Jörg wrote:
> A better description would be: deprecate perl-mode.el in favour of
> cperl-mode.el.  It is not intended to make M-x perl-mode go away, but 
> to
> implement its look and feel with cperl-mode.el.
> 
> The main motivation for this that maintaining two modes to keep up with
> changes in Perl syntax is not very efficient.

Awesome.

> This is exactly why comments like yours are welcome: I want to know
> which of the differences are annoying for users of Perl mode.
> 
> In particular:
> 
>  - Code indentation: Both Perl mode and CPerl mode offer several user
>    options to affect indentation (too many of them in CPerl mode IMHO).
>    I am confident that it is possible to mimick Perl mode's default
>    indentation by options.  Concrete examples are very welcome (like
>    those you provided with your next reply).  They will make it into 
> the
>    test suite.
> 
>  - TAB for indenting region: That's also something that should be
>    doable.  CPerl mode's behaviour for indent-region is indeed very
>    idiosyncratic (and underdocumented).
> 
>  - use of specific faces: This will be fixed in CPerl mode anyway,
>    independent of the deprecation.  This doesn't mean that the rich
>    coloration which some people like will go away, but that all faces
>    will default to font-lock-* faces if cperl-mode.el starts in Perl
>    mode style.

Sounds wonderful :) I can't wait to discover the additions of CPerl 
Mode.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Stefan Kangas]

"Paul W. Rankin" via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> On 2023-12-03 23:20, Harald Jörg wrote:
>
>> CPerl mode has several predefined indentation styles, a recent addition
>> is to indent according to Damian Conway's "Perl Best Practices".  This
>> can be activated with (cperl-set-style "PBP").  It _should_ be the
>> default these days, but it isn't for compatibility reasons.  in PBP
>> style, indentation is like this:
>>
>>     $r->get(
>>         '/test'
>>     );

BTW, how bad are the above mentioned compatibility concerns?  If they
are minor, perhaps we could change to the modern PBP style?

AFAIK, the PBP book was released around 20 years ago, and it's style was
pretty widely adopted by the Perl community from what I could tell at
the time.  It's been a long time since I last coded Perl seriously
though, so I'm very much out of the loop.

> Ah this is excellent. "PBP" is indeed how I assume Perl should be
> indented. But how do I set this as a user option, i.e. M-x
> customize-option? I think M-x cperl-set-style is not easily discoverable
> (i.e. I didn't find it). For my own packages I encourage user discovery
> through M-x customize-group, but I think here cperl-set-style would
> remain elusive...

I think this is one example of CPerl mode being different from typical
Emacs conventions.  I think we should introduce a new defcustom with the
same name so that this can be set from `M-x customize`.

> Still on indentation, the main way CPerl Mode bumps me out of things is
> that it doesn't indent the current region (like other programming
> modes), only the current line. If CPerl Mode would indent the region on
> TAB with "PBP" that would go a long way to making it feel more
> approachable.

Yet another case of CPerl mode being weird, and this one sounds a lot to
me like a plain bug.  Note that CPerl mode has several commands,
including a separate one to indent the region, for some reason.

Could you report this one as a bug so that we can discuss in more detail
what, if anything, could be done about this?

> Cool. In general where CPerl mode departs from convention I think it
> would be greatly appreciated to have an option to reign it back in ;)

I think we need to consider every case of that individually, so please
do report bugs.

> Something that may warrant a separate bug report is CPerl Mode's
> departure from the use of font-lock-* faces in a few key faces. The big
> advantage of sticking with the font-lock-* faces is that a user can more
> or less define their own theme just by customizing these faces. The
> faces in question are:
>
> cperl-array-face
> cperl-hash-face
> cperl-nonoverridable-face
>
> Each of which I think could benefit from instead inheriting from a
> font-lock-* face by default, to make things look a little more
> aesthetically pleasing. That said, I don't know which font-lock-* face
> is most appropriate, maybe combinations e.g.
> font-lock-variable-name-face plus bold plus underline.

This one warrants a bug report too, yes.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Harald Jörg]

Stefan Kangas writes:

> "Paul W. Rankin" via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>> On 2023-12-03 23:20, Harald Jörg wrote:
>>
>>> CPerl mode has several predefined indentation styles, a recent addition
>>> is to indent according to Damian Conway's "Perl Best Practices".  This
>>> can be activated with (cperl-set-style "PBP").  It _should_ be the
>>> default these days, but it isn't for compatibility reasons.  in PBP
>>> style, indentation is like this:
>>>
>>>     $r->get(
>>>         '/test'
>>>     );
>
> BTW, how bad are the above mentioned compatibility concerns?  If they
> are minor, perhaps we could change to the modern PBP style?
>
> AFAIK, the PBP book was released around 20 years ago, and it's style was
> pretty widely adopted by the Perl community from what I could tell at
> the time.  It's been a long time since I last coded Perl seriously
> though, so I'm very much out of the loop.

>> Ah this is excellent. "PBP" is indeed how I assume Perl should be
>> indented. But how do I set this as a user option, i.e. M-x
>> customize-option? I think M-x cperl-set-style is not easily discoverable
>> (i.e. I didn't find it). For my own packages I encourage user discovery
>> through M-x customize-group, but I think here cperl-set-style would
>> remain elusive...

I guess the reason why cperl-set-style was implemented as a command is
the fact that it sets a bulk of independent variables (11 for PBP) at
once.

> I think this is one example of CPerl mode being different from typical
> Emacs conventions.  I think we should introduce a new defcustom with the
> same name so that this can be set from `M-x customize`.

The option you are looking for would be cperl-file-style (which is
rather new, Lars Ingebrigtsen implemented it for Emacs 29 as a response
to Bug#17948).

I can fix the discoverability: The option does not have a :group tag
defined, therefore it ends up in the stray customization group "Cperl
Help System".  Instead, it _should_ be the first option in "Cperl
Indentation Details".  Patch coming soon!

>> Still on indentation, the main way CPerl Mode bumps me out of things is
>> that it doesn't indent the current region (like other programming
>> modes), only the current line. If CPerl Mode would indent the region on
>> TAB with "PBP" that would go a long way to making it feel more
>> approachable.
>
> Yet another case of CPerl mode being weird, and this one sounds a lot to
> me like a plain bug.  Note that CPerl mode has several commands,
> including a separate one to indent the region, for some reason.
>
> Could you report this one as a bug so that we can discuss in more detail
> what, if anything, could be done about this?

Stefan Monnier suggested that we try to map TAB to
indent-for-tab-command.  This seems to be the most generic way to bind
TAB to either indent-line, or indent-region, or insert a literal TAB
character.  I have not yet looked into that (and I admit that I'm not
really familiar with the indentation code of cperl-mode.el).

>> Cool. In general where CPerl mode departs from convention I think it
>> would be greatly appreciated to have an option to reign it back in ;)
>
> I think we need to consider every case of that individually, so please
> do report bugs.
>
>> Something that may warrant a separate bug report is CPerl Mode's
>> departure from the use of font-lock-* faces in a few key faces. The big
>> advantage of sticking with the font-lock-* faces is that a user can more
>> or less define their own theme just by customizing these faces. The
>> faces in question are:
>>
>> cperl-array-face
>> cperl-hash-face
>> cperl-nonoverridable-face
>>
>> Each of which I think could benefit from instead inheriting from a
>> font-lock-* face by default, to make things look a little more
>> aesthetically pleasing. That said, I don't know which font-lock-* face
>> is most appropriate, maybe combinations e.g.
>> font-lock-variable-name-face plus bold plus underline.
>
> This one warrants a bug report too, yes.

...and it is on my agenda.  I had hoped to get it done quickly, but
underestimated the font-lock stuff cperl-mode does within regular
expressions (which are a language of their own).

-- 
Cheers,
haj

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Stefan Kangas]

Harald Jörg <haj@posteo.de> writes:

>>> Ah this is excellent. "PBP" is indeed how I assume Perl should be
>>> indented. But how do I set this as a user option, i.e. M-x
>>> customize-option? I think M-x cperl-set-style is not easily discoverable
>>> (i.e. I didn't find it). For my own packages I encourage user discovery
>>> through M-x customize-group, but I think here cperl-set-style would
>>> remain elusive...
>
> I guess the reason why cperl-set-style was implemented as a command is
> the fact that it sets a bulk of independent variables (11 for PBP) at
> once.

I think you could use the defcustom :set keyword for that.

Users would need to use `setopt` to set it though (or the :set won't
take effect), but I think we want to encourage people to use that
instead of `setq` in any case.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Harald Jörg]

Stefan Kangas <stefankangas@gmail.com> writes:

> Harald Jörg <haj@posteo.de> writes:
>
>>>> Ah this is excellent. "PBP" is indeed how I assume Perl should be
>>>> indented. But how do I set this as a user option, i.e. M-x
>>>> customize-option? I think M-x cperl-set-style is not easily discoverable
>>>> (i.e. I didn't find it). For my own packages I encourage user discovery
>>>> through M-x customize-group, but I think here cperl-set-style would
>>>> remain elusive...

It is now (in the master branch) available in the customization group
cperl-indentation-details.

>> I guess the reason why cperl-set-style was implemented as a command is
>> the fact that it sets a bulk of independent variables (11 for PBP) at
>> once.
>
> I think you could use the defcustom :set keyword for that.
>
> Users would need to use `setopt` to set it though (or the :set won't
> take effect), but I think we want to encourage people to use that
> instead of `setq` in any case.

That looks fine!

I'd like to postpone that, though: I try to keep cperl-mode.el
compatible with Emacs 27 (currently Emacs 26, but I'll probably push
because of the new font-lock-faces in Emacs 27), and eventually make it
dual-life via GNU ELPA - and setopt is not available before Emacs 29.
-- 
Cheers,
haj

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Stefan Kangas]

Harald Jörg <haj@posteo.de> writes:

> I'd like to postpone that, though: I try to keep cperl-mode.el
> compatible with Emacs 27 (currently Emacs 26, but I'll probably push
> because of the new font-lock-faces in Emacs 27), and eventually make it
> dual-life via GNU ELPA - and setopt is not available before Emacs 29.

I don't think we need to wait until you bump the version to Emacs 29 to
introduce this, as it doesn't specifically depend on `setopt'.

In older versions, this will just have the same general limitations that
defcustom :set had for aeons before Lars fixed this in Emacs 29: it
won't fire unless you set the user option from `M-x customize' or use
`customize-set-variable'.

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Harald Jörg]

Stefan Kangas writes:

> Harald Jörg <haj@posteo.de> writes:
>
>> I'd like to postpone that, though: I try to keep cperl-mode.el
>> compatible with Emacs 27 (currently Emacs 26, but I'll probably push
>> because of the new font-lock-faces in Emacs 27), and eventually make it
>> dual-life via GNU ELPA - and setopt is not available before Emacs 29.
>
> I don't think we need to wait until you bump the version to Emacs 29 to
> introduce this, as it doesn't specifically depend on `setopt'.
>
> In older versions, this will just have the same general limitations that
> defcustom :set had for aeons before Lars fixed this in Emacs 29: it
> won't fire unless you set the user option from `M-x customize' or use
> `customize-set-variable'.

Oh, I see.  I misunderstood.  That makes sense then.

The current implementation might need some reconsideration, though... I
have been playing around with it and am a bit confused.

As far as I understand it, `cperl-file-style' is supposed to be set in
.dir-locals.el.  If I define it there as "PBP", then that style going to
be local in buffers visiting files from the same directory.  Fine so
far.

However, the individual settings like `cperl-indent-level' are not
buffer-local, nor made buffer-local by cperl-set-style.  Therefore, if I
run `cperl-set-style' in any buffer (or from a customize :set function
or from another .dir-locals.el), then it will override the value ... in
all buffers, regardless of their local style settings.

The C modes (which are the example after which cperl-file-style was
built) solve this with a special value 'set-from-style - I guess
cperl-mode needs something in the same spirit.
-- 
Cheers,
haj

Re: Please do not deprecate perl-mode in favour of cperl-mode

[Stefan Kangas]

Harald Jörg <haj@posteo.de> writes:

> The current implementation might need some reconsideration, though... I
> have been playing around with it and am a bit confused.
>
> As far as I understand it, `cperl-file-style' is supposed to be set in
> .dir-locals.el.  If I define it there as "PBP", then that style going to
> be local in buffers visiting files from the same directory.  Fine so
> far.
>
> However, the individual settings like `cperl-indent-level' are not
> buffer-local, nor made buffer-local by cperl-set-style.  Therefore, if I
> run `cperl-set-style' in any buffer (or from a customize :set function
> or from another .dir-locals.el), then it will override the value ... in
> all buffers, regardless of their local style settings.
>
> The C modes (which are the example after which cperl-file-style was
> built) solve this with a special value 'set-from-style - I guess
> cperl-mode needs something in the same spirit.

Yeah, I noticed that discrepancy too.  So I don't think the feature is
working in its current form.

I've reopened Bug#17948 to track this work.