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

Previous Next

Full log

Message #91 received at 66050 <at> debbugs.gnu.org (full text, mbox):

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

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

The behavior looks right to me, tho I haven't checked the code if it's
by accident (i.e. because of a bug in `perl-mode`) or not.

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

Agreed in the sense that `indent-according-to-mode` (and
`indent-region`) should not touch this line.
But TAB should, using this part of `indent-line-function`:

    indent-line-function is a variable defined in ‘indent.el’.
    [...]
    If it is called somewhere where it cannot auto-indent, the function
    should return ‘noindent’ to signal that it didn’t.
    [...]

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

I think the way we usually solve these tensions is to replace those
error messages with some kind of highlighting (and if necessary
`help-echo` properties to help the user figure out what this
highlighting is for).

E.g. in ELisp mode, a non-terminated string results in a string-highlight
that bleeds into the subsequent code.  And an argument wrongly placed on
the same line as something already indented within a subexpression as
in:

      (foo arg1
           (some sub
                 expression) badarg2)

gets a `font-lock-warning-face` together with a `help-echo`.


        Stefan

Previous Next

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