Better Function List for Java ?
-
@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.
-
-
@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.
-
@rdipardo said in Better Function List for Java ?:
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.
