This is a series of small improvements I have been testing on my local IDE over the last week. They are in various states of completion, but this is altogether my working IDE and the snapshots are what my current design. I would be interested in hearing other user's thoughts on any of these in whichever shape or form they might come.
Thank you for your time.
hmm... sorry for the confusion, I was playing with the little message icons and forgot to set this one back to the default.
First of all I want to thank you for working towards improving the Arduino IDE! I actually really like the simplicity of Arduino even though I'm not a beginner. I tried hard to make the switch to using Visual Micro a year ago and after a week I was so grateful to go back to using the Arduino IDE. I feel that the simple interface helps me to be more creative. That said, I'm all for adding more features if they can be done without interfering with what we have now.
Code completion: Personally I've had bad experiences with code completion. I'm fully in support of adding this feature because it will be useful to many and maybe you can win me over but, as with all such features, it must be fully optional. The new editor added in 1.6.5 forced automatic matching brackets on us with no option of turning it off and it's something many don't like. One idea I had and I don't know how feasible it would be is to allow add-ons for this sort of thing. The Arduino developers are very reluctant to add features to the IDE because that will make it more complex for the target Arduino user. If there was an infrastructure to allow 3rd party add-ons then users could pick and choose extra features. Was that your intention with this proposal: Support JavaScript based customization of the Editor · Issue #4074 · arduino/Arduino · GitHub? I think the Arduino developers and most of the community do support adding code completion so you may have an easier time of it than other of your proposals. I see you're aware of the work already done towards this goal and would suggest you consider contributing towards that PR instead of starting from scratch.
key bindings: Yes please! All my favorite programs except Arduino IDE have this. If the developers support adding this feature I'd suggest focusing solely on this feature to begin with.
library reference from code: Sounds good. I think this one has a good chance of being accepted by the developers.
library editing: I'm all for this one but the developers have already stated multiple times that they don't support it. I like that you have the keywords.txt, library.properties, and README.md in there. I have my IDE hacked to do this and it's so much better than switching between 2 different editors or giving up using the Arduino IDE editor which I like.
better multi-tab handling: This is commonly requested and I think has a good chance of being accepted. I don't think you meant to reference #3061 as it doesn't seem related.
Overall I would recommend that you focus on one thing instead of getting split into so many projects at once, especially as you stated you have not much time available. I think the developers would be more receptive if you eased in slowly. Maybe consider submitting a pull request that solves one of the issues tagged as "Help Wanted". This one might be low hanging fruit: IDE should not steal focus for "Update available for some of your libraries" · Issue #3809 · arduino/Arduino · GitHub.
One thought I had regarding the Key Bindings feature: You may find resistance from the developers to adding this feature on the grounds that it unnecessarily complicates the GUI. Another option for the configuration of more "advanced" features such as this is a user editable text file in the Arduino15 folder. This is how the advanced preferences are handled in preferences.txt as well as theme.txt, and formatter.conf. This way the GUI is simple for beginners but more advance customization is also available. That system would also probably make the coding a bit easier.
Thank you very much for taking the time to share some views!!
I also believe that one of the greatest strength of the whole arduino environment is its SIMPLICITY. Arduino is a great way to get projects going quickly, and I have the utmost respect for people who have the skills to make complex things appear simple as they managed to do.
My desire would be to follow in their footsteps, and knock out more objections/entry barriers, linked to the IDE (I do think it is great): I just want to extend its lifespan through the learning curve of users (starting with me), and ensure that simple things remain simple, while allowing more complex things, currently out of reach or judged to complex on the surface, to become possible and hopefully even simple. Users should just use, and hackers should find all the assistance they want to hack. I have more thoughts but the list was long as it is, and my time currently limited.
To put things in perspective, I diverted little over a week from a personal project to make adjust the tool for me. I could not break my code cleanly apart into libraries, but when I looked into the source code there was a very simple way (3h work) to keep everything the way it was (guarantee for me that I was not going to introduce and endless stream of new bugs) while opening the door to solving a number of existing issues: the long list of tabs, the poor navigation between them, the lack of visibility over the dependancies, the fixed structure... so it all hinges on some trivial changes (call it 'cleaning the abstractions') to a handful of existing classes.
Code completion
This is what makes code completion code so simple: integration with the editor is a single line of code regardless of the language being edited (again 100% credit due to the designers of the Editor and the external library used). This makes it equally easy to wrap this line in a config driven IF statement to disable it if a user does not want it. The point is, the current core design is sound (could use more cleanup, but it is sound) and it offers a lot of room for creating a lot of complex looking features at a low implementation cost. I currently have a number of languages, but as you rightly suggest, additional ones can be written without touching my code (discovers .jars externally). And yes, as you pointed out, there is also a connection with my thoughts on scripting the editor.
The negative side effect of my approach is that it is not compatible with the existing code completion PR. As I wrote somewhere, IMHO that PR will do more long term damages to the clean simplify of the editor core than it will do good (visible immediately, others indirect as they will introduce un-necessary complexity for compared to their benefits). I am only referring to the integration layer (the code behind is quite cleverly based on eclipse code - with the performance trade-offs).
Key Binding
Interesting topic... I proposed to start with simply listing all the IDE binding in a single table, leaving the door open to later edit them (or simply load them from a manually edited text file) if need be. My reason for proposing it is simply that I could not find them all.. but.. the deeper reason is that the code that manages menu items is one of these things that people starting an editor sometimes overlook until it has become a tangled mess. My outliner has different popup menu actions for a Library node (or any of its source files) than for Sketch files nodes or even board nodes. Well done, the base class for all these actions should make managing bindings an almost free side-effect of the rest. Many of my proposals are like that: cheap side effects of something that is not really worth talking about.
IMHO, this is what experience brings: we still don't know what code to write but we quickly get a strong feel for what NOT to write, and complex looking features sometimes come as side effects of the internal structures we build.
#3809 Window focus issue/rude popup
This is the perfect illustration of the previous principle. The problem can be addressed as an isolated issue. But IMHO there is a better road ahead that will lead to more features coming as side effects. Again a matter of opinion, this one based on what I did to start #4077, and as if this was not enough, I just noticed #4099 which IMHO should be seen as another facet of the exact same issue. Considering them together as a single issue to be solved in one go will lead to less code that will allow some of the features I have not listed yet.
#4074 is another of these things you get for free by doing something else somewhere else. I am running out of energy for tonight, but will take the time to write more about how it fits.