I'm not so sure anymore. The parsing problems disappear as soon as I start emacs with -q

so something in my init-files seems to trigger the problem.

Tested with

• emacs 24.3 on Win and Ubuntu
• emacs 27.1 on Win.

PS: In respect to cperl-under-as-char

   This variable is obsolete since 24.4;
   use ‘superword-mode’ instead.
[download]

Well, there is a bug in CPerl mode. It is a bit evasive and not that easy to trigger. choroba has filed a bug report and there's a patch which you should be able to use at least in Emacs 27.1. It also contains a test case with a sequence of commands which triggers the bug in Emacs 26.1 to Emacs 28.

I am well aware of the deprecation of cperl-under-as-char and provided it only as a possible workaround. By the way: There be dragons. Superword mode treats all symbol characters as word characters, and in CPerl mode the colon : is also a symbol character.

In general, the fontification of CPerl mode should not depend on the setting of this variable nor on the setting of superword mode, and in most (but not all, as we see here) cases the underscore is explicitly included when parsing Perl identifiers.

Hi

You are right! Now that I was able to automate the testing I'm seeing clearer.

The bug is not present with emacs-24 -q but with emacs-27 -q

For the unwary, -q means that I don't load my personal config so that I can test vanilla emacs and not my own fixes, patches and cperl-modes.

What I forgot tho was explicitly switching to Ilya's cperl-mode, gnu-emacs is favorizing it's own perl-mode, which is much simpler and probably doesn't even try to handle y

Now running this (windows version)

c:\nonBKU\emacs-27.1-i686\bin>runemacs.exe -Q D:\tmp\pm\tst.pl -eval "
+(progn (cperl-mode)(goto-line 4)(newline))"

c:\nonBKU\emacs-27.1-i686\bin>
[download]

will show the bug and an error message

End of ‘y_ ... _’ string/RE not found: (scan-error Unbalanced parentheses 49 80)

That's the content of tst.pl:

#!/usr/bin/perl
use strict;
use warnings;

sub y_max {
    1
}

print "Done";
[download]

Automated tests are cool! xD

update

> there's a patch which you should be able to use at least in Emacs 27.1.

it worked in 24.3 so something must have introduced the bug later.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

When I open a file with sub y_max {}, it displays correctly, but if I insert a newline before it, it goes back to the wrong highlighting even with -q.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Ok, I'll publish a test-script based on Testing syntax parsing in editors (especially emacs) soon.

So we'll be able to run regression tests. =)

update

to be clear, I can insert as many newlines like I want, w/o messing up the result.

update

you were right, I might have forgotten to switch to cperl-mode while testing 27.1

Here an automated test Re^8: IDE for Perl programming? ( *cperl-mode* bug)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

tried this, but unfortunately no avail. :(

> Yes, it is a bug in the parser. In that monstrosity which analyses POD, Here-docs, regexes, and quote-like constructs, because in all of these things characters may change their meaning.

I still think the only viable way is to have an expandable set of tests with Perl snippets to parse.

An external Perl script should run them thru different emacs installations in batch mode.

I started working on this some years ago, have to dig this out again ...

... unfortunately I am a bit too exhausted at the moment to do it right away.