bug#66050: Making perl-mode.el obsolete

["Harald Jörg" <haj@posteo.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I was wrong (as explained in my reply to Mauro).  Sorry for the
confusion!

> [...]
>> 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`.

Thanks for this suggestion!  This would be an improvement to cperl-mode
in general.  I didn't know about the help-echo property!

-- 
Cheers,
haj