[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
- bug#66050: Making perl-mode.el obsolete, (continued)
- bug#66050: Making perl-mode.el obsolete, Mauro Aranda, 2023/09/21
- bug#66050: Making perl-mode.el obsolete, Stefan Monnier, 2023/09/21
- bug#66050: Making perl-mode.el obsolete, Mauro Aranda, 2023/09/21
- bug#66050: Making perl-mode.el obsolete, Stefan Kangas, 2023/09/24
- bug#66050: Making perl-mode.el obsolete, Harald Jörg, 2023/09/24
- bug#66050: Making perl-mode.el obsolete, Mauro Aranda, 2023/09/24
- bug#66050: Making perl-mode.el obsolete, Harald Jörg, 2023/09/25
- bug#66050: Making perl-mode.el obsolete, Stefan Monnier, 2023/09/25
- bug#66050: Making perl-mode.el obsolete,
Stefan Monnier <=
- bug#66050: Making perl-mode.el obsolete, Harald Jörg, 2023/09/25
bug#66050: Making perl-mode.el obsolete, Stefan Monnier, 2023/09/18
bug#66050: Making perl-mode.el obsolete, Harald Jörg, 2023/09/23