BUG: In Perl, NPP doesn't find some subroutines in function list.

C Bacca

Notepad++ v8.7 (64-bit)
Build time : Sep 17 2024 - 17:06:31
Path : C:\Users\chuck\Apps\Notepad++\notepad++.exe
Command Line : “C:\Users\chuck\Apps\Notepad++\change.log”
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
Periodic Backup : ON
OS Name : Windows Server 2012 R2 Standard (64-bit)
OS Build : 9600.21620
Current ANSI codepage : 1252
Plugins :
AutoSave (2)
mimeTools (3.1)
NppConverter (4.6)
NppExport (0.4)

I just updated NPP to v8.7 on Windows Server 2012 R2. (No we cannot update the OS.)

I have had this problem on an older version of NPP from March 2024 as well.

I edit Perl programs and use the Function List docked on the right side of the NPP window. NPP does not list all functions. Here’s one function it is not finding or showing in the function list.

####################################################################
sub isprice
# Return 1 if a cell is a price, or 0 if not.
# Take string, remove macros, dollar signs, and numbers. If len > 0 then
# it's not a price.
{my($s)=@_; # isprice()
my($t,$l);

The file has a .pl extension. Here’s a function that is listed in the Function List.

####################################################################
# Save pid in "allhaworth" sdbm file.
sub logpid
{my($npid)=@_;
my(@a,@b,$i,$j,$s,$t,$z,$timestr);

When I show all characters in the file I don’t see any odd hidden characters that might mess up finding the function name. There are just normal CRLF here and there.

Is there something I might be able to fix on my end? I’m not familiar with NPP config files or anything advanced like that.

Thank you.

PeterJones

@C-Bacca ,

The short answer is: the regex that Notepad++ uses by default for parsing Perl code does not expect there to be comments between the sub name and sub body.

####################################################################
sub isprice
# Return 1 if a cell is a price, or 0 if not.
# Take string, remove macros, dollar signs, and numbers. If len > 0 then
# it's not a price.
{my($s)=@_; # isprice()
my($t,$l);
}

sub oneliner { 1; }

sub nope		# not this one
{
	return 0;
}

sub stillnope()		# nor this one
{
	return 0;
}

sub alasno()
{	# alas
	return 0;
}

sub finally
{	
	# comments can go here
	return 1;
}

=>

let me go experiment … I think that should be solvable, but it will take me a bit. (Though I’m a bit worried about how the parser’s comment rule might interact with the normal function parser… but I’ll give it a shot.)

(As a reminder, “only perl can parse Perl”… so with Notepad++ using a fairly “simplistic” regex by default, it’s doing a reasonably good job of kindof-parsing Perl.)

Michael Vincent

@PeterJones said in BUG: In Perl, NPP doesn't find some subroutines in function list.:

The short answer is: the regex that Notepad++ uses by default for parsing Perl code does not expect there to be comments between the sub name and sub body.

Not just Perl, many function parsers have this limitation, following “Shell” language example:

#!/bin/bash
# Experimenting with variable scope
var_change () {
    local var1='local 1'
    echo Inside function: var1 is $var1 : var2 is $var2
    var1='changed again'
    var2='2 changed again'
}
var1='global 1'
var2='global 2'
echo Before function call: var1 is $var1 : var2 is $var2
var_change
echo After function call: var1 is $var1 : var2 is $var2

#!/bin/bash
# Experimenting with variable scope
var_change () {
    # And now a breaking comment
    local var1='local 1'
    echo Inside function: var1 is $var1 : var2 is $var2
    var1='changed again'
    var2='2 changed again'
}
var1='global 1'
var2='global 2'
echo Before function call: var1 is $var1 : var2 is $var2
var_change
echo After function call: var1 is $var1 : var2 is $var2

Cheers.

PeterJones

@PeterJones said in BUG: In Perl, NPP doesn't find some subroutines in function list.:

I think that should be solvable,

Sorry, I always forget, this is due to this reported bug – more in our FAQ.

My alasno subroutine would have worked if I’d used two whitespace between { and # alas instead of a single tab (so it could have been two tabs, two spaces, or one of each). But the others not working are due to note3 in the FAQ.

Sorry, I cannot fix that for you.

As a workaround, you could “change your coding style”, so the comments for a function either go before the sub line or after the { start of body (with at least two whitespace) – but “change your coding style” is a rather annoying suggestion to receive, I understand. As an alternative, if you aren’t commenting out subroutines often (ie, you don’t use # sub blah {...} to turn off specific functions), then you could edit your c:\program files\notepad++\functionList\perl.xml and change it so it has the following:

		<parser
			displayName="PERL"
			id         ="perl_function"
			xcommentExpr="(?x)                                               # Utilize inline comments (see `RegEx - Pattern Modifiers`)
							(?m-s:\x23.*$)                                  # Single Line Comment
						"
		>
			<function
				mainExpr="(?x-s)                                             # Utilize inline comments (see `RegEx - Pattern Modifiers`)
						sub 				# start of sub
						\s+ 				# must have spaces between sub and name
						[A-Za-z_]\w* 		# name must start with alpha or underscore, and then be more word characters
						(\s*\([^()]*\))? 	# prototype or signature
						(\s*\:\s*[^{]+)? 	# attributes
						(\s*\x23.*$\s*)*		# optional comment
						\s*\{				# start of body is any number of spaces followed by the opening brace
						(\s*\x23.*$\s*)*		# optional comment
					"
			>

You will have to save the XML, exit Notepad++, and restart the app for the changes to take effect.

(Instead of editing the one in the installation directory hierarchy, you could also copy c:\program files\notepad++\functionList\perl.xml to %AppData%\Notepad++\functionList\perl.xml, and edit the AppData copy as described above – the AppData copy will take precedence over the install-directory copy after you restart.)

This will get all of my examples from above to show up in the function list … at the expense that # sub hideme() { ... } might show up in your functionList as well.

It’s up to you whether that’s a reasonable workaround for your needs or not.

Alan Kilborn

Bottom line: Comments cause problems with function list parsing.
And thus it is practically impossible, given the free-form-put-most-anywhere nature of comments, to “get it right” all the time.
It would be better if there was an algorithm that (virtually) converted all comments to space characters before parsing for function list purposes.