GNU bug report logs - #76868
29.4; cperl-mode __END__ is incorrectly handled

Previous Next

Full log

View this message in rfc822 format

From: John Ciolfi <ciolfi <at> mathworks.com>
To: haj <at> posteo.de, 76868 <at> debbugs.gnu.org
Cc: maurooaranda <at> gmail.com
Subject: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
Date: Sun, 9 Mar 2025 16:41:00 +0000

[Message part 1 (text/plain, inline)]

Thanks for the detailed response. I learned something new. To me it seems that perl isn't supplying enough information for cperl-mode to get the trailers correct. Ideally, we could definitively tell the type of content below the __END__ or __DATA__ keywords.  I suppose one could set file local variables to configure cperl-fontify-trailer. However, one needs to know about this option. I wonder if there's a way to make the option more obvious?

A small suggestion is to update the help text or cperl-fontify-trailer to indicate it also changes the indent behavior.  I think the name cperl-trailer-type is a good name too, though updating the help text may be sufficient.

Thanks
John

________________________________
From: Harald Jörg <haj <at> posteo.de>
Sent: Sunday, March 9, 2025 8:28 PM
To: John Ciolfi via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org>
Cc: Mauro Aranda <maurooaranda <at> gmail.com>; 76868 <at> debbugs.gnu.org <76868 <at> debbugs.gnu.org>; John Ciolfi <ciolfi <at> mathworks.com>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled

John Ciolfi via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Yes, setting cperl-fontify-trailer to comment fixes the bug. In my
> case, the lines after the __END__ are more than just comments and get
> corrupted when they are indented. There is also the __DATA__ keyword
> and the default setting of cperl-fontify-trailier causes the data to
> be indented which alters the behavior of the program (corrupts the
> result). Consider:
>
> while (my $line = <DATA>) { print $line; }
> close DATA;
> __DATA__
> This is not
> perl code
>
> If you indent, C-x h followed by C-M-\, the results change. Indenting
> shouldn't change results.

Indeed, setting the option cperl-fontify-trailer to 'comment' is
supposed to prevent this sort of thing from happening.

> Could you consider changing the default value of cperl-fontify-trailer
> to comment so that cperl-mode doesn't indent them? Also, the name is a
> little misleading because the more important piece is whether to
> semantically treat the lines after these keywords as perl code. ...

I agree that the name of the option is misleading. Maybe we should add
an alias like cperl-trailer-type? The possible values of "perl-code"
and "comment" still work with that name. However, changing the default
is, in my opinion, not the correct way, because there are valid use
cases for the current default behavior.

> ... The Perl interpreter never treats these as perl code, so it's odd
> cperl-mode treats them as perl code. ...

That's not the whole truth. Programs which use AutoSplit or SelfLoader
work by intentionally having Perl code after the __END__ or __DATA__
tokens. Both AutoSplit and SelfLoader are part of the Perl core.

https://perldoc.perl.org/AutoSplit<https://perldoc.perl.org/AutoSplit>
https://perldoc.perl.org/SelfLoader<https://perldoc.perl.org/SelfLoader>

> The only case I'm aware of where the lines following these keywords is
> perl is to use the trick to put __END__ to comment out the bottom part
> of a perl program, but even in that case, it should be colored as
> comments.

By far more common is the practice to have POD (Perl's documentation
format) after the __END__ token. This is not read by the Perl
interpreter, but by perldoc and other POD viewers. POD is part of the
Perl language. CPerl mode handles POD for fontification, and supports
POD authoring by imenu indexing of POD headings and by ispell checking
for POD sections.

So, different ways to use the space after the tokens are valid. If you
do not use POD or Perl code after __END__ or __DATA__, setting the
option cperl-fontify-trailer to "comment" does the trick. But the
default value is there for a valid purpose, too. User options are not
supposed to change the behavior of Emacs which would be the case if the
default value is flipped.

If you regularly indent a whole buffer which may contain trailers not
understood by CPerl mode, you can set the variable temporarily:

(defun indent-buffer-without-trailer ()
(interactive)
(let ((cperl-fontify-trailer "comment"))
(cperl-indent-region (point-min) (point-max))))

> Thanks
>
> ------------------------------------------------------------------------------------
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Sent: Saturday, March 8, 2025 10:51 AM
> To: John Ciolfi <ciolfi <at> mathworks.com>; 76868 <at> debbugs.gnu.org
> <76868 <at> debbugs.gnu.org>
> Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
>
> On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>
>> Hi
>>
>> Given the following cperl-mode program, test.pl
>>
>> # -*- mode: cperl; -*-
>> print "hello\n";
>> __END__
>> This is not
>> perl code!
>>
>> The lines after the __END__ are treated as perl code. They are
> syntactically colored and indented
>> which is incorrect. In perl, __END__ defines the end of the Perl code
> in the file. Any text that
>> appears after __END__ is ignored by the Perl compiler.
>>
>> All lines after __END__ should be treated as comments.
>>
>
> Any chance that the option cperl-fontify-trailer helps here?
>
> I remember reporting something similar in:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161>

In the comments of that bug report I've also listed CPAN examples for
each of the use cases.
--
Cheers,
haj

[Message part 2 (text/html, inline)]

Previous Next

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