Better Function List for Java ?

MAPJe71

The default Java Function List shipped with Notepad++ is the one I created.
At that time the parsers were still in one file. I haven’t found the time yet to update my Languages repository to have each parser in their own file.

w3 mbox2

Although I like Notepad++ speed, I don’t see this problem with Geany nor CudaText (both create a very detailed and complete tree of all classes and methods for the same Java file right out of the box without plugins or add-ons). Surprised that a popular editor like Notepad++ is so deficient in this aspect.

PeterJones

@w3-mbox2 said in Better Function List for Java ?:

Although I like Notepad++ speed, I don’t see this problem with Geany nor CudaText (both create a very detailed and complete tree of all classes and methods for the same Java file right out of the box without plugins or add-ons). Surprised that a popular editor like Notepad++ is so deficient in this aspect.

Notepad++ does Function List parsing it “without any plugins or add-ons” – but it allows customization , which you are allowed to choose to make use of or not, if you feel that the default parsing isn’t sufficient.

Getting 100% coverage for real languages is a pipe dream (and it “working” for you for Geany or CudaText probably just means you haven’t happened to find the edge cases they they miss), but Notepad++'s coverage has been quite good since @MAPJe71 created the Java Function List definition based on this conversation – good enough that in the intervening 7 years, I can only find record of one request for an improvement to the parser logic (in 2017, which was promptly fixed).

Since it’s completely customizable, you can choose to improve it yourself. Or if you’d like help, you could share example text that doesn’t parse correctly for you. If you are unwilling to do either, then all the complaining in the world won’t make it better. The ball is in your court.

w3 mbox2

Lets start with this: save the following to a text file “Test,java”:

public class Test {

	public static void main ( String[] args) {
		System.out.println( "test");
	}
}

And then open with Notepad++.

In the Function List there is only “Test.java” and no classes nor methods are listed. Clicking “Reload” doesn’t help.

Version 8.5.8 64 bit (npp.8.5.8.portable.x64).

Michael Vincent

@w3-mbox2

You mean like this?

Cheers.

w3 mbox2

Here is what I get on Windows 7 (also confirmed with a clean installation with default settings):

PeterJones

@w3-mbox2 said in Better Function List for Java ?:

Here is what I get on Windows 7 (also confirmed with a clean installation with default settings):

You have re-found a known limitation in the parser, which requires at least one blank character (space or newline) at the end of a block. Hit ENTER at the end of line 6, and it will work. This was the core of issue #2910 and many others before and after

In general, most filetypes work better throughout the compute-space if they end in a newline – such newlines are included by on text editors on linux-type systems, and it really should happen by default on Windows as well, but it doesn’t. I use the EditorConfig plugin and set insert_final_newline = true in its configuration so that whenever I save a file, the final newline will be included – but you don’t have to do that if you remember to always hit ENTER at the end of your file.

Michael Vincent

@PeterJones said in Better Function List for Java ?:

hit ENTER at the end of your file

There are those that DON’T do this ?!?!?!

;-)

Cheers.

PeterJones

@w3-mbox2 said in Better Function List for Java ?:

without any plugins or add-ons required.

BTW: the implementation philosophy of the Developer of Notepad++: unless he really likes a feature and is interested in implementing it himself, if there’s already a plugin that has a particular feature, the Developer will not re-implement it in the base application.

Thus, if there had been a plugin that solved your problem, the Developer would have said “then use that plugin”.

As a result of this philosophy, if you want the automatic-ENTER-at-end-of-file that I mentioned, the plugin is the best way to get it, because the Developer is not likely to implement it natively in Notepad++.

PeterJones

@Michael-Vincent said in Better Function List for Java ?:

There are those that DON’T do this ?!?!?!

Since I installed EditorConfig, I don’t do it manually. ;-)

And apparently, there are a subset of users (which include @w3-mbox2 , as is obvious from the screenshot provided) that do not manually do so or find a way to automatically do so.

w3 mbox2

Lets try this now:

public class Test {

	public static void main ( String[] args) {
		System.out.println( "test");
	}
	// { hello
}

PeterJones

@w3-mbox2 ,

You changed your data compared to the data above. If I use the data you originally showed, it works just fine to add the newline. If I use the data you posted now, I can replicate your problem.

I think @MAPJe71 will have to chime in again, but I vaguely remember something about certain comments confusing the parser as well.

update: quick experiment showed that if I close the brace in the comment, then it will parse correctly again.

w3 mbox2

@PeterJones I have the strong feeling that I would continue finding bugs in the Java parser and Function List if I wanted to …

Alan Kilborn

@w3-mbox2

I have the strong feeling that I would continue finding bugs

I think you already know the answer if you are unhappy with Notepad++ – use something else.

The way function list parsing is done, via regex, likely means (I haven’t proved it) that there are always going to be ways to mess up the parsing.

w3 mbox2

@Alan-Kilborn said in Better Function List for Java ?:

@w3-mbox2

I think you found your answer if you are unhappy with Notepad++ – use something else.

You bet.

w3 mbox2

@Alan-Kilborn said in Better Function List for Java ?:

The way function list parsing is done, via regex, likely means (I haven’t proved it) that there are always going to be ways to mess up the parsing.

It is also my belief.

Alan Kilborn

@Michael-Vincent said in Better Function List for Java ?:

hit ENTER at the end of your file

There are those that DON’T do this ?!?!?!

How do we get the author of Notepad++ ( @donho ) to see the wisdom of adding a configuration setting for forcing saved files to end with a line-ending if the user hasn’t manually put one there?

Here we have 3 confirmed expert users of Notepad++ (Peter / Michael /myself) pretty much saying this is a needed thing (if I’m reading the others correctly), and yet the author has not seen the importance. Sure, there hasn’t been a recent official feature request, but as was pointed out, this was declined in the past.

Sure, there’s the editorconfig plugin, but some features absolutely need to be “core”, and this is one of them.

For some reason, new features endorsed by the expert users are often declined by the author, with the response of “let’s wait for more users to request this”.

Michael Vincent

@Alan-Kilborn said in Better Function List for Java ?:

Sure, there’s the editorconfig plugin, but some features absolutely need to be “core”, and this is one of them.

I do it with PythonScript. But see your point - the latest is a real push to make all the features of BetterMultiSelection “built-in”. Happy for that, but a checkbox for adding EOL to EOF would be pretty simple (PythonScript example):

    def _on_before_save(self, args):
        len = editor.getLength()
        if len == 0:
            return

        c = editor.getCharAt(len-1)
        if c == 13 or c == 10:
            return

        eol = editor.getEOLMode()
        if eol == ENDOFLINE.CRLF:
            ret = "\r\n"
        elif eol == ENDOFLINE.CR:
            ret = "\r"
        elif eol == ENDOFLINE.LF:
            ret = "\n"
        editor.insertText(len, ret)

Cheers.

PeterJones

@Alan-Kilborn said in Better Function List for Java ?:

The way function list parsing is done, via regex, likely means (I haven’t proved it) that there are always going to be ways to mess up the parsing.

As the classic line goes,

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

(Though I think @guy038 would disagree with that sentiment.)

The sad thing is, there could be two great alternatives available to Notepad++:

All the builtin Lexilla lexers are already doing true, high-quality state-machine lexing of the source code to properly syntax highlight. But (unless I’m mistaken) Lexilla doesn’t give the applications that use it (like Notepad++) the ability to hook into that and make other use of it – if Lexilla did, then all Notepad++ would have to do is say "give me a list of all the classes/functions in this file, and then Notepad++ could display them. But I doubt Lexilla would add that functionality this late in the game.
With most of the “big” languages having LSP servers available, the text editors that have builtin LSP clients (or at least have an already-developed plugin for LSP) can also easily do function-extraction, and so much more. It was requested as a core feature years ago, but it never gained traction… and unfortunately, neither of the plugins that have tried to implement it have gotten to the point where it’s publishable.

rdipardo

@PeterJones said in Better Function List for Java ?:

All the builtin Lexilla lexers are already doing true, high-quality state-machine lexing of the source code to properly syntax highlight. But (unless I’m mistaken) Lexilla doesn’t give the applications that use it (like Notepad++) the ability to hook into that and make other use of it – if Lexilla did, then all Notepad++ would have to do is say "give me a list of all the classes/functions in this file, and then Notepad++ could display them.

If it can save someone from opening a hopeless feature request, let me try to explain why this grossly overstates Lexilla’s capabilities.

A lexer is in fact surprisingly like a regex engine. Think of how VS Code provides easily extensible syntax highlighting thanks to Textmate grammars, which map textual patterns to semantic elements.

Also like a regex engine, Lexilla has no context awareness, with the exception of the most accomplished lexers, for example C++ (preprocessor macro tracking) or Python (f-strings nested to almost arbitrary depth). Nifty accessories, yes, but implemented ad hoc in non-extensible C++ code.

Simply put, a lexer is not a compiler service. It doesn’t do much more than segment a byte steam into meaningful chunks that get assigned to styles. Painting by numbers, one byte at a time. And Lexilla can only see bytes. Not words or functions or classes, let alone the hierarchy of modules that make up a project.