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: Stefan Monnier
Subject: bug#66050: Making perl-mode.el obsolete
Date: Sun, 24 Sep 2023 18:54:11 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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






reply via email to

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