Hello,
Second attempt of sending this, first one stranded in "not authorized to send mail".
> Regarding 'Eclipse editor forgets everything when you don't have a syntactically correct file': Do you mean that if you save you lose things you entered? Or something else? I'm not yet sure
I understand what you mean here. If indeed you lose what you typed then that would be a serious bug!
This was in context of auto-completion. I have disabled the "add matching closing curly brace when you type an open curly brace" option, since I like to explicitly decide that myself.
This means that in any code that I am editing, I have a syntactically broken Java file most of the time.
Obviously the compilation happening in the background detects this and starts throwing errors. That is fine, I just ignore them.
However, as auto-completion also depends on the compiler, I at least then also don't have auto-completion for anything further down the file, even if the compiler saw that part before while
I had a valid Java file (that happens when I finish a method or an inner block by typing matching closing curly braces). In other words, the compiler deletes all its knowledge and rebuilds the information from scratch it seems rather than updating parts and
keeping untouched parts until a full pass can be run again.
Not sure I am missing other auto-completion parts, I never bothered to verify exactly what part is dying there.
I know about existence of the configuration options of auto-completion, but didn't try changing them to what I like. It looks like it can only change the order of recommendations instead of
having different recommendations that better match what we need.
Fairly reasonable cases are missing I think:
- You have a 'final' variable. I would say a reasonable option is to have a constructor that takes that value as a parameter. It isn't offered afaik.
- You have 5 object variables (not final). Again a reasonable alternative would be to offer autocompletion to take these variables as parameter, but fair enough maybe that is not always desired. I copy/paste the type + name into the parameters part
of the constructor. I do get auto-completion of assigning a parameter to the field, but 1 at a time, and the name of the parameter isn't matched with the name of the class variable (auto-completion thinks alphabetic order is "most relevant" apparently).
Likely there are many more if you start looking for them.
Insertion of proposals isn't bug-free either. An empty generated constructor gets a "// TODO: write code here" comment. The first parameter copy statement to its field gets inserted above that comment line, the second parameter copy statement gets inserted
below the comment line.
Template instantiation isn't quite right either. We have a standard blurb with the constructors, and I inserted that blurb in the javadoc list to save typing. I type "/**" and then ENTER above the constructor, and I end up with an additional " * " line
in the inserted template, since it first inserts the template, and then still processes my ENTER leading to an additional line.
In whole, the entire editor seems very inadequate in handling things. One reason that I use it is because it's faster at autocompleting class-names, and methods than I can type. Another reason
is that trying to use something else is mostly impossible.
I am very weary of sending bugs to JDT. The things I notice seem so blatantly obvious that you cannot miss them, yet it's not there. We can't be the only people that write java and initialize
object variables from the constructor. I also had the experience to report a problem in switch statements where the wrong deduction was made, only to get the issue closed automatically a few years later without addressing the problem.
This claiming of success even though it barely works is another thing that happens more often. Did you try a dark theme? Eclipse says it works, but if you try it you'll spot lots of problems
immediately, and many more if you actually use it.
> Regarding Eclipse configuration and documentation not being clear ...
It's the entire eco system indeed. It's accepted policy by Eclipse that useful documentation isn't relevant. I can file issues but that doesn't solve my problem of wanting to do something
and only getting frustratedly stuck in the swamp of useless HTML reference documents, errors that say nothing, explanations that say nothing, and third-party web sites that only cover the trivial good weather case and claim problem solved (if they even take
a good solution instead of a bad one).
Again this is everywhere, people must be together spending eons finding out how to do simple things in Eclipse due to not having adequate documentation.
I am very stuck with Eclipse. I can't get "in", since it assumes this unknown large amount of knowledge that is not written down in an accessible way. I have no idea where to start reading
or how to look for things, every attempt just ends in the swamp without getting wiser. I can't get "out", since we're very much glued to this Eclipse thing and there isn't a viable alternative.
I'd write a code editor and ditch everything eclipse if I'd have the time to make it.
I still prefer plain "javac" and "jar" over anything else, since the latter are much harder to understand and get running, throws errors I don't know how to fix and give no major improvements
in what I need to do.
> Regarding Checkstyle warnings: Is it about the style that we use to highlight Checkstyle warnings ...
The style is quite overboard, but it's more the timing. I use code as a srcatch board to understand the problem at hand, and work out where the gaps and fundamental problems arise. I just
want to write "will this have a fair chance of flying" code then, lots of stubs and half-finished functions, different classes that should work together but aren't connected yet, etc.
I am focussed on the problem that needs to be solved looking at the core steps that must be done, fleshing out the global structure. I don't want distractions because I inserted an additional
empty line somewhere, broke a curly brace rule, a max length line rule, or a code formatting rule, didn't write javadoc for a trivial function, did a static import "*", or have 10 imports that I copy/pasted and currently don't need all of them.
It's a scratch implementation for finding out that the approach will work at all. It's not production code that fulfills all rules of the house. I can't write the latter without knowing the
former will give me a positive answer. You may work differently, I don't know.
The warnings in themselves are somewhat useful in pointing out omissions at some point. There seems to exist a distinction between things where I knowingly break the rules to allow for focussed
working (pasting 20 imports at the very start as I likely need at least 15 of them in the future, including a few non-standard "*" static imports as I will need those functions in the solution, not fully handling all cases in a switch, not handling all control
flow for returning a value from the function call), rules that don't serve a purpose at the time (white space and strict formatting rules for example), and rules that help me in spotting things I missed. Type errors in expressions, for example.