Better Function List for Java ?
-
@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++.
-
@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.
-
Lets try this now:
public class Test { public static void main ( String[] args) { System.out.println( "test"); } // { hello }
-
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.
-
@PeterJones I have the strong feeling that I would continue finding bugs in the Java parser and Function List if I wanted to …
-
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.
-
@Alan-Kilborn said in Better Function List for Java ?:
I think you found your answer if you are unhappy with Notepad++ – use something else.
You bet.
-
@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.
-
@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”.
-
@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.
-
@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.
