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

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Sun, 17 Sep 2023 12:49:02 UTC

Severity: wishlist

Full log


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

From: Harald Jörg <haj <at> posteo.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Mon, 25 Sep 2023 08:40:24 +0000
Stefan Monnier <monnier <at> 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




This bug report was last modified 1 year and 264 days ago.

Previous Next


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