bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#66050: Making perl-mode.el obsolete


From: Mauro Aranda
Subject: bug#66050: Making perl-mode.el obsolete
Date: Sun, 24 Sep 2023 19:40:10 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1

On 24/9/23 19:21, Harald Jörg wrote:
> Mauro Aranda <maurooaranda@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 ;-)






reply via email to

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