emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Harald Jörg
Subject: Re: Please do not deprecate perl-mode in favour of cperl-mode
Date: Fri, 29 Dec 2023 15:07:11 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]