GNU bug report logs - #66050
Making perl-mode.el obsolete

Previous Next

Full log

View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Harald Jörg <haj <at> posteo.de>
Cc: Corwin Brust <corwin <at> bru.st>, 66050 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, rms <at> gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#66050: Making perl-mode.el obsolete
Date: Sun, 24 Sep 2023 19:40:10 -0300

On 24/9/23 19:21, Harald Jörg wrote:
> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> In addition to what Jens Schmidt said, I can add that:
>>
>> 1. If I have something like:
>> my $some_code = "";
>> $some_code.= q(
>> my $counter = 0;
>> );
>>
>> If I put point at column 0 of the line "my $counter", and hit TAB, I get
>> indentation in perl-mode.  I don't in cperl-mode.  I tried to look into
>> options for making this work but I couldn't find anything.
>
> I consider the behavior of perl-mode to be a bug.
>
> Whatever is within the parens of  q(...) is a string, and will be
> assigned to the variable $some_code.  By "indenting", perl-mode changes
> the value of $some_code by adding spaces.  In my opinion, indenting
> should change the optical layout, but not the code!

I might be completely wrong about this, but I have the feeling that
TAB behaves differently because in perl-mode I see TAB is bound to
indent-for-tab-command (this is not in emacs -Q, just in case it has
something to do with that).

So, TAB is not really indenting (as I said originally, sorry), but
adding a TAB character upon request.  And yes, in this case I want to
change the code, so TAB is not doing anything incorrect here, I think.

>> 2. While I'm typing the above string, I get messages about string/RE not
>> found:
>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>> parentheses 1092 1874)
>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>> parentheses 1092 1918) [2 times]
>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>> parentheses 1092 1962) [2 times]
>>
>> That's annoying.
>
> The message is technically correct, and generally I consider the ability
> of cperl-mode to locate syntax errors useful.  But I understand that it
> can be annoying while you're typing (I myself don't see these messages
> because I use paredit-mode, but I understand that not everyone wants
> this electricity).  I guess that a way to optionally suppress these
> messages can be found.

Sure is correct, but I'm used to see messages like those when I have
really screwed up (typically editing an elisp file and making
forward-sexp fail).  Not while I'm typing.  To me, it feels better to
have kind of a visual indication, like when you are entering a string
and everything fontifies as a string so you are reminded you better
close it.

>> So far, my settings for getting a perl-mode experience in cperl-mode,
>> with emacs -Q: (taken from a custom file):
>> '(cperl-highlight-variables-indiscriminately t)
>> '(cperl-indent-level 4)
>> '(cperl-indent-parens-as-block t)
>> '(cperl-invalid-face 'default)
> ,>
>> '(cperl-array-face ((t (:inherit cperl-hash-face))))
>> '(cperl-hash-face ((t (:underline t :inherit
>> font-lock-variable-name-face))))
>> '(cperl-nonoverridable-face ((t (:inherit default))))
>
> Thanks for collecting this!
>

You're welcome.  I'm still trying to figure out if there are more
settings to tweak.  Together with the settings that need to be added for
a smooth perl-mode -> cperl-mode transition, they could be placed in a
cperl-perl-mode-users-asylum-theme ;-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.