let me try to explain why this grossly overstates Lexilla’s capabilities.

Somewhat optimistic, possibly. But I don’t think it’s grossly overstated.

A lexer is in fact surprisingly like a regex engine.

And as such, it should be able to do at least as well as the regex-based approach, with the added benefit that it’s much easier to track state inside the non-extensible C++ code, so being able to track whether or not a function definition is still within a given class or not would be possible to add – though it may be a lot of effort.

But I don’t think that anyone should bother with such a feature request to Lexilla, because I am quite confident that, no matter whether my feasibility estimation is just optimistic or “grossly overstated”, they would reject it out of hand.

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.

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.

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.

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”.

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.

@w3-mbox2

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

You bet.

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.

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.

public class Test {

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

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.

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++.

hit ENTER at the end of your file

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

;-)

Cheers.

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.

You mean like this?

Cheers.

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).

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.

Is there a way to get a more complete Function List for Java ?

The Function List definitions are 100% user-configurable. If you can improve the regex to match the extra class methods, then feel free to update your own (and share it with your fellow Notepad++ users). So that is one way.

Our resident Function List guru, @MAPJe71 , who wrote our FAQ on Function List, has a collection of languages that have Function List definitions and/or autoCompletion definitions for quite a few programming languages – but unfortunately his Java entry only has autoCompletion, not Function List. I think that means he thought the one that shipped with Notepad++ was sufficient for his needs.

Do you have example code that’s showing your class method not showing up correctly? Because if you can share code that doesn’t parse right, he or one of the other regex experts here might be able to help customize the regexes used in the default Java FunctionList definition to work better for your need. (And if it seems globally useful, the tweaked version might be submitted to the Notepad++ repo for future inclusion…)