Emacs comes with two different major modes to edit Perl code: perl-mode and cperl-mode.

perl-mode is somewhat stuck with the Perl syntax of 5.14, has less features, but a cleaner implementation. cperl-mode is up to date with Perl 5.38 and has deeper understanding of Perl syntax, but a somewhat arcane implementation, most of it written in the previous century.

With all due respect to TIMTOWTDI, maintaining two major modes turns out to be not enough fun in the long run, and last week Stefan Kangas opened a wishlist item to Making perl-mode.el obsolete.

The mail thread shows that some people prefer perl-mode because it is less "colorful" and intrusive than cperl-mode. Therefore, the idea is to enable cperl-mode to (optionally) look like and behave like perl-mode. That way, perl-mode.el can be obsoleted without making those users uncomfortable: perl-mode would continue to exist as a custom theme of cperl-mode.

Users of perl-mode are now encouraged to try cperl-mode, and to report bugs against cperl-mode where they prefer the behavior of perl-mode. This has already started. The "current" cperl-mode.el is available from the repository: cperl-mode.el and is supposed to work with Emacs 26 and newer.

Keep the reports going!

This article also appears on blogs.perl.org.

Edited: Fixed the link to blogs.perl.org. Thanks to hippo for noticing!

I very much appreciate the thorough answers I receive here: they have helped me get reacquainted with Perl. The hardest part I still encounter is to understand what the symbols mean, not so much the concepts.

I'm simply asking for a "better" way to accomplish a task I already can do.

An example: I want to know if there's a way to send just one key & value per array/hash - preferably by reference - to a subroutine. In the example code below, I want to send all and only the {Sub_Name}s and their respective values. The code below works and I've come up with two ways to list the Sub_Name. I'm simply wanting to know if there's a better way to do it, so I don't have to make an array or send the entire array of hashes to the subroutine.

#!/usr/bin/env perl

#use 5.36.1;
use strict;
use warnings;

use Data::Dumper;
use autodie;
use File::Find;
use File::Copy;
use File::Rename;
use feature 'fc';
use File::Path qw( make_path );

my $Wait_Time = 10;    # Implement Time Delay

# Subscription DATA sets
my @Subscription = ( 
     {
     Sub_Name               => "Morph",
     Archive_File           => "Morph Archive.txt",
     },
     {
     Sub_Name               => "Analogue",
     Archive_File           => "Analogue Archive.txt",
     },
     {
     Sub_Name               => "Cat",
     Archive_File           => "Cat Archive.txt",
     },
     {
     Sub_Name               => "Zoonotic",
     Archive_File           => "Zoonotic Archive.txt",
     },
     {
     Sub_Name               => "Hydro",
     Archive_File           => "Hydro Archive.txt",
     },
);

#Subscription of Names
my @Subscription_Names_List;
for (@Subscription) {push @Subscription_Names_List, $_->{Sub_Name};}
List_Subscriptions(\@Subscription_Names_List);


for (@Subscription) {
    Display_Subs(\%$_);
}

sub Display_Subs { 
    my ($my_Sub) = @_;
    print "Testing Subscription to: $my_Sub->{Sub_Name}\n";
    return $my_Sub;
}

sub List_Subscriptions {
    my (@Sub_ARRAY) = @{$_[0]};
#    my (@Sub_ARRAY) = @_;

    print "The Current Subscription List:\n\n";
    for (@Sub_ARRAY) { print " \t$_ \n"; }
    print "\n\n";
}
[download]

Is it better to use a "packaged" easily installable version of Perl such as Strawberry on a Windows OS or to compile a version or there is no practical difference, etc...?

I primarily ask for two reasons: stability and speed. An underlying assumption to both reasons is that compiling code will always be faster, because it will compile based on specific chipsets and its respective native math libraries.

1. Stability. My systems run both AMD CPUs and GPUs. I have wondered if instability in GAMES are sometimes caused by various issues of the binaries being compiled for Intel CPUs and NVidia GPUs. By extension, is there an inherent stability benefit of compiling Perl on a Windows system?

2. Speed. This likely has no real practical value unless one is running a "large" server on Windows; but, I wanted to ask anyway. So, by a similar analogy to GAMES stability, since there is a real benefit to GAMES which have been optimized for either AMD or Intel/NVidia and sometimes specifically a chipset, is there a speed benefit to compiling Perl on Windows?

thanks

# IMPORTANT MODULES FOR THIS CODE...
use CGI qw(-utf8); 
use File::Spec::Functions qw( catfile );

sub send_file {
    my ($cgi, $dir, $file) = @_;

    # $dir = '/var/www/download/';
    # $file = 'MyLaTeXDocument.pdf';

    my $path = catfile($dir, $file);
        
    open my $fh, '<:raw', $path or die "Cannot open '$path': $!\n";

    $cgi->charset(''); #REMOVES PRIOR UTF-8 SETTING, AS THIS IS BINARY
+ FILE
    print $cgi->header(
        -type => 'application/octet-stream',
        -attachment => $file,
    );

    binmode STDOUT, ':raw';
    print while <$fh>;    
    close $fh or die "Cannot close '$path': $!";

    return;
}
[download]

The browser console sees a string of characters returning in the response, but no download dialogue is opened.

Response headers

Connection
    Keep-Alive
Content-Disposition
    attachment; filename="MyLaTeXDocument.pdf"
Content-Type
    application/octet-stream
Date
    Fri, 22 Sep 2023 11:13:27 GMT
Keep-Alive
    timeout=5, max=100
Server
    Apache/2.4.52 (Ubuntu)
Transfer-Encoding
    chunked
[download]

Response Payload

JVBERi0xLjUKJeTw7fg... [truncated...too lazy to type more]
[download]

my $one_string = "hello world";
say length $one_string;    # 11
 
my @many_strings = ("abc", "cd", "e", "fg", "hi", "hello world");
say length @many_strings;  # 1
say scalar @many_strings;  # 6
[download]

I want to know what it would take for the next one:

say __?__ @many_strings;  # 21
[download]

<tag>many characters ends abruptly here in the middl</tag>
[download]

I save the line in a scalar array element, then print the entire array. The result has the begin and end tag, but the line in the middle is truncated. In the last fail, it truncated at 23,052 characters which didn't seem like a particularly significant number. In other cases the line greatly exceeds that length, without truncation.

Ideas of why this happens on some lines and not others, or better ways to save these long lines with are appreciated. Maybe more than one tag? I studied MAX XML tag-contents restrictions, as well as Perl scalar length limits, and I don't see any specific limits.

There's a fun little bug in the debugger, which you can see like this. Create a dumb little script. Anything will do.

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

print "we";
print "just";
print "need";
print "something";
print "to";
print "list";
[download]

Now let's start up the debugger.

perl -d zz.pl

Loading DB routines from perl5db.pl version 1.77
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(zz.pl:5):    say "we";
  DB<1>
[download]

All as expected, but now:

  DB<1> l 1.2
1.2     use strict;
  DB<2> l
2.2     use warnings;
3.2     use feature 'say';
4.2     
5.2:    say "we";
6.2:    say "just";
7.2:    say "need";
8.2:    say "something";
9.2:    say "to";
[download]

That's kind of unexpected, but it gets better!

  DB<2> l 1.1.3.5
1.1.3.5     use strict;
  DB<3> l
2.1     use warnings;
3.1     use feature 'say';
4.1     
5.1:    say "we";
6.1:    say "just";
7.1:    say "need";
8.1:    say "something";
9.1:    say "to";
[download]

Why does this happen? well it goes back to commit a687059cbaf, which is the one that moves the debugger into lib in Perl 3. The pattern used to capture the line number specification is (\d\$\.)+, which matches all kinds of things, including floating-point numbers, IPv4 addresses, and other junk. The overall pattern used to parse the l command arguments changes over time, but that basic match to extract a "line number" never does.

You may be thinking, "yeah, okay, I see that, but why does the debugger show the floating-point line number?" The reason is that the line number spec is captured as a string. THe debugger stores the source code of the current file in an array whose name is not a valid Perl variable name, and uses the line number spec captured by the l command to index it.

When Perl indexes an array, the index value is converted to an integer if possible, because array indexes have to be integers. The line spec we have is captured and stored as a string, so when we try to index the source array with it, "1.22" becomes the integer 1, and we find line 1. The command uses the value of the index variable (remember, that's still a string!) to print the line number, and so we end up with a floating-point line number.

Now, when we run the bare l command, the string "1.22" is still in the list command's "last line listed" variable, and Perl simply takes that variable and adds 1 to its contents to look for the next line. Since the contents are a string that looks like a floating point number, Perl converts it to a float, adds 1.0 (so we don't downgrade it from a float), and assigns that back to the current line number,so we get lines 2.22, 3.22, and so on.

I've submitted a patch to fix this for 5.40, but it's pretty surprising that we've had this bug for 32 years!