28 Small & Simple IDE Changes

Hi, this is my first post on the forums here.

I've been using Arduino for a short time, and I've put together the following list of suggestions for changes to the IDE. I've made a concerted effort to keep the changes on this list small, simple, and (hopefully) easy to implement.

Please let me know what you think, both in terms of the changes themselves, and in terms of their feasibility.

-Dan

1. Add recognition of angle-bracket strings (eg. <avr/sleep.h>, <SdFat.h>, etc.)

  • Currently double quoted (") and single quoted (') strings are recognized as LITERAL1 (editor.literal1.style)
  • Additionally, unmatched quotes are recognized as invalid (editor.invalid.style)
  • Fix: Add < and > as starting and ending (respectively) string delimiters for these two styles

2. Change quoted string literals style type to differentiate them from constants

  • The current list of keyword definitions makes most built-in constants type LITERAL1
  • Quoted strings are currently styled with the same settings (editor.literal1.style)
  • Constants and literal strings should be able to be styled differently without changes to the keyword defaults
  • Fix: Create a new style for these strings, eg. "editor.string.style"
  • Alternate: Style strings as type LITERAL2, since it currently has no default keyword definitions

3. Add syntax coloring for numeric constants (eg. 10, -5, 59.3, 0x0F, 125000L, etc.)

  • Currently numeric constants are not highlighted, whereas quoted strings are
  • Fix: Recognize numeric constants of all forms and create a new style, eg. "editor.number.style"
  • Alternate: Style numbers using the existing and underused LITERAL2 style type

4. Add syntax coloring for operators (eg. +, <<, !=, ~, etc.)

  • Operators are currently defined in the keywords file but not associated with a style type
  • The theme settings specify a style (editor.operator.style), however it has no effect (broken)
  • Fix: Create a definition for operators (eg. OPERATOR) and enable highlighting of them with the existing style

5. Add syntax coloring for punctuation (eg. (), {}, [], ;, etc.)

  • There is currently no way to style punctuation marks differently from other code elements
  • Fix: Recognize these marks internally and make a new style for them, eg. "editor.punctuation.style"
  • Bonus: Style unmatched braces/brackets using the existing invalid style (editor.invalid.style)

6. Add syntax coloring for all function calls (eg. "myFunction" in "myFunction(int argument)" code)

  • Currently only keyword-defined functions are matched and highlighted, not user-defined function calls
  • Fix: Recognize function calls (and definitions) internally and make a style for them, eg. "editor.function.style"

7. Add an optional gutter with line numbering

  • Current cursor line number is displayed at the bottom of the window, in the status bar
  • Fix: Add a gutter with line numbers, and two new styles, eg. "editor.gutter.fgcolor" and "editor.gutter.bgcolor"

8. Add a View menu to the menu bar

  • This would allow for easy toggling of various view options including:
  • Line numbering in gutter on/off (see above)
  • Syntax highlighting on/off
  • Console display on/off
  • Button bar on/off (see below)
  • Status bar on/off
  • etc.

9. Add ability to hide/show the top row of buttons in the main window

  • These buttons all currently have keyboard shortcuts or menu bar access
  • Allow hiding of this top bar to save precious vertical screen real-estate, as an option

10. Add current line highlighting

  • The default theme has two entries named "editor.linehighlight" and "editor.linehighlight.color"
  • However, these entries seem to have no effect, and the current line is never highlighted
  • Fix: Enable this feature by changing the background color of the current line (if editor.linehighlight is true)
  • Note: At present, these entries can safely be removed from the theme file

11. Change scrolling method to be smoother (or at least make wheel-based scrolling 1 line at a time)

  • Modern text/code editors usually scroll their contents smoothly (eg. TextMate, Sublime Text, etc.)
  • The Arduino IDE only scrolls on line-by-line increments, and wheel (or trackpad) scrolling jumps multiple lines
  • Fix: Change scrolling behavior to be pixel-based instead of line-based

12. Hide the editor's horizontal scrollbar when it's inactive/unneeded

  • The editor (at least on Mac) displays the empty horizontal scrollbar at the bottom even if it's unnecessary
  • Fix: Hide this bar if there isn't a need to scroll horizontally, saving vertical screen space

13. Change horizontal and vertical scrollbars to smaller modern style (on Mac)

  • The scrollbars are currently styled using the bulky, bubbly widgets typical of older OS X apps
  • Fix: Change the scrollbars to be the newer, more minimal style (and obey hidden/shown setting in System Preferences)

14. Fix button on-click states for New, Open, Save, and Serial Monitor buttons

  • These buttons on the top-most button bar fail to display their "active" state on a mouse-click
  • Also, these buttons register their actions upon mouse-click as opposed to typical mouse-click-release
  • Fix: Change all buttons to activate on release instead of click, which is normal behavior for nearly all interfaces
  • Fix: Change buttons to active (orange) highlighted state on appropriate action, eg.:
  • New: While mouse button is down
  • Open: While button is down and drop-down menu is active
  • Save: While button is down and while saving
  • Serial Monitor: While button is down and while monitor is open
  • Bonus: Disable buttons when they shouldn't be pressed, eg. disable Verify during Upload, and vice-versa, etc.
  • Bonus: Add fourth and fifth states to the buttons for "Running" (aka compiling/uploading) and "Unavailable" (aka grayed-out)

15. Fix mouse-over (rollover) state for the down-arrow menu button

  • The Tab Dropdown (down arrow) button fails to register a mouse-over state
  • It also fails to register an active state, nor does it have art specified for one (unlike the other buttons)
  • Fix: Add proper mouse-over and mouse-click states (and art) to be consistent with the other buttons

16. Fix support for tab-based indentation (as opposed to spaces)

  • The preferences file currently contains a setting called editor.tabs.expand
  • Changing editor.tabs.expand to false causes very strange (broken) behavior
  • Fix: Allow tab characters to be used instead of spaces in the editor & source code files

17. Allow the reordering of tabs within a project, and have this order reflect concatenation

  • Tab order currently seems to be alphabetical, but is important in terms of compiling
  • Fix: Allow tabs to be reordered with drag-and-drop, and have them concatenated in this order

18. Add an option for auto-opening of Serial Monitor upon successful upload

  • If serial monitor communication is needed, the window needs to be manually opened a lot
  • Fix: Have an option for the serial monitor to open automatically once a sketch has been uploaded and verified

19. Add ability to export (save) compiled hex files and upload them without recompiling

  • The hex files are currently stored in a temp directory with a crazy random name
  • Also, even though they're relatively small, sketches need to be recompiled to be uploaded
  • Fix: Simple menu option to export compiled hex, and option to upload a hex from a chosen file
  • Alternate: Hex file could be output to project directory with project name at compile time

20. Add support for keywords.txt file located in Sketchbook folder or individual sketch folders

  • Current keyword modifications are library-based or located as defaults within the .app bundle (Mac)
  • This means that those changes are destroyed when the app is updated
  • For general-purpose custom-additions, user must create a dummy library with keywords file in it
  • Fix: Add sketchbook root folder and project folder as search paths for keywords files

21. Add support for an interface theme directory located in Sketchbook folder

  • Current theme changes have to be made inside the .app bundle (Mac)
  • These changes need to be backed up externally and reapplied when the app is updated
  • Fix: Look for a "theme" folder in the user's root sketchbook folder and use that instead, if it exists
  • Bonus: Support a properly-structured "theme.zip" file instead, for incredibly easy distribution

22. Add #define, #include, typedef, struct, pow, bool (and many others) to keywords list

  • The default keyword list is woefully incomplete, missing many core functions and constants
  • Fix: Audit the core language and libraries thoroughly to generate an accurate and robust keywords database
  • Note: There's no reason to not include "behind the scenes" keywords, because someone may need to use them
  • Bonus: Auto-generate keyword databases for libraries (functions, global constants, defines)

23. Allow the program to remain open with no windows/files open (Mac)

  • The application pops-up an annoying dialog box when the final editor window is closed
  • It has been typical behavior on Mac systems (for a long time) to allow an app to remain open with no windows
  • Fix: Simply leave the program running when the last window is closed, and disable appropriate menu items

24. Allow the separation of the editor and the console into individual windows

  • The console occupies valuable vertical screen real-estate
  • It may be nice to have the console located next to the editor instead of below it
  • Fix: Simplest change might be two separate windows by default, which can then "stick" to each other

25. Allow for realtime theme changes without restart of the application

  • The program must be closed and re-opened to reflect any theme changes, which is clunky
  • Even if changes can't be updated instantly, a "Reload Theme" menu option / shortcut could accomplish this

26. Export the preferences file with its entries sorted alphabetically

  • Manual editing of the preferences file is extremely difficult due to the random order of entries
  • Fix: Because of the hierarchal scopes of settings, simply sorting the entries makes it much, much more accessible
  • Note: Since the preferences file is rewritten on every close, this can't be done manually by the user

27. Address non-functioning entries in the preferences file (eg. editor.font.macosx)

  • There are some preferences that have no effect, or non-functioning effects
  • Fix: Audit the preferences and remove unused entries, and fix non-functioning ones
  • Note: The macosx platform-specific entries seem to have no effect (and I'm using a Mac)

28. Add option to find/replace to search through all tabs

  • Replace All functions only for the currently active tab
  • Fix: Add an option to extend Replace All to apply to all tabs within a project

precious vertical screen real-estate

Damn HD-defined short screens!

for (17), the order of concatenation of .ino is not SUPPOSED to be "important." Note that .cpp and .c files are not concatenated...

all good
obvious
and practical changes

some I have seen in other posts,

great ideas

its never going to happen though....

Ever considered using an external editor? I often use notepad++ works quite well has several points you mention....

westfw:
for (17), the order of concatenation of .ino is not SUPPOSED to be "important."

Am I detecting some sarcasm?

westfw:
Note that .cpp and .c files are not concatenated...

Ah, good to know. Thanks!

drjiohnsmith:
great ideas

Thank you!

drjiohnsmith:
its never going to happen though....

Why do you say that?

Re: 17.

Personally I wouldn't have such a big sketch that I have to split it into multiple files and hope the concatenation works. Make separate .cpp files is my recommendation. Having an IDE concatenate files into one compilation unit goes against expectations, IMHO.

robtillaart:
Ever considered using an external editor? I often use notepad++ works quite well has several points you mention....

I have. I'm using a Mac and Notepad++ is Windows-only, but I'm looking into TextMate and Sublime Text.

The reason I posted this list isn't necessarily because I need a particular software solution for myself. Rather, I think the Arduino project as a whole and (especially) its primary piece of software deserve to be scrutinized and improved upon; not because they're unsatisfactory as they are, but because they're going to continue to gain (deserved) popularity and exposure.

The idea of making Arduino programming "beginner friendly" is excellent, and there's no reason the IDE should attempt to compete with the likes of Eclipse, AVR Studio, or the other editors mentioned above. However, I don't think any of the items on this list contradict that philosophy. There's no reason that this "beginner friendly" tool shouldn't aim for the highest quality, nor should it be desirable for those who have moved past the beginner stage to abandon it. I think "beginner friendly" is just another way of saying "thoughtfully designed."

I can walk into any RadioShack and buy an Uno, or any number of official Arduino shields. The packaging is beautiful, and the presentation and execution of the hardware displays a careful attention to detail.

There's no reason the software shouldn't live up to the same standard.

If I may suggest, post your suggestions to the code project page as a suggestion:

http://code.google.com/p/arduino/issues/list

Why do you say that [it will probably never happen]?

The main reason is that most of Arduino "development" consists of putting together pieces of technology that originate from elsewhere, with relatively minor amounts of "glue" and modification. So the core (originally) came from "Wiring", the compiler from gcc/etc, and the IDE comes from "Processing." Many of the changes you've suggested are in pieces of the code that purely "Processing", and there seems to be resistance to changing those because it would make upgrading to new versions of Processing more difficult.

(That's putting a good "spin" on things. The shorter answer is along the lines of "The Arduino Team has shown little inclination to implement suggestions for IDE improvements.")

loglow:

robtillaart:
Ever considered using an external editor? I often use notepad++ works quite well has several points you mention....

The reason I posted this list isn't necessarily because I need a particular software solution for myself. Rather, I think the Arduino project as a whole and (especially) its primary piece of software deserve to be scrutinized and improved upon; not because they're unsatisfactory as they are, but because they're going to continue to gain (deserved) popularity and exposure.

The idea of making Arduino programming "beginner friendly" is excellent, and there's no reason the IDE should attempt to compete with the likes of Eclipse, AVR Studio, or the other editors mentioned above. However, I don't think any of the items on this list contradict that philosophy. There's no reason that this "beginner friendly" tool shouldn't aim for the highest quality, nor should it be desirable for those who have moved past the beginner stage to abandon it. I think "beginner friendly" is just another way of saying "thoughtfully designed."

I can walk into any RadioShack and buy an Uno, or any number of official Arduino shields. The packaging is beautiful, and the presentation and execution of the hardware displays a careful attention to detail.

There's no reason the software shouldn't live up to the same standard.

I completely agree. After digging into the code I gave up trying to improve the official Arduino IDE. Instead I started my own. It's still immature but already looks a lot better than the standard IDE.

You can try out the latest build here:

http://hudson.joshy.org:9001/job/ArduinoX/lastSuccessfulBuild/artifact/dist/

[quote author=Josh Marinacci link=topic=133928.msg1008669#msg1008669 date=1353825697]
After digging into the code I gave up trying to improve the official Arduino IDE. Instead I started my own.[/quote]

This looks very promising! Quite an undertaking. Good luck; I'll be watching.

westfw:
The main reason is that most of Arduino "development" consists of putting together pieces of technology that originate from elsewhere, with relatively minor amounts of "glue" and modification.

I see. Not very good news for the likelihood of these sorts of changes. This explanation does make some sense though, even if it's not necessarily how I'd approach the development and maintenance of such software. "Glue" (in this context) will never replace solid engineering and design.

solid engineering and design.

Oh, I dunno. "Glue" is "engineering." I'd put about half your requests in the "eye candy" category; nice to look at and elegant from some technical point of view, but not really very useful (I have an especially dim view of "smooth scrolling", ever since it slowed down the VT100...) Yeah, the syntax coloring ought to be based on a complete parser with the capability of separately coloring any lexical element, but actually using that many colors would be silly...

I also find your willingness to spend cpu cycles, while attempting to preserve "vertical real estate" a bit inconsistent.

But the only one I think is a really bad idea is "9. Add ability to hide/show the top row of buttons..." All the documentation is based on those buttons, and they're fundamental to the IDE's "Ease of Use." Setting things up so that beginners might accidentally delete them is a terrible idea.

16: tab are the evil ]:slight_smile:

If anything has to be said about indentation capabilities of the Arduino IDE, I think CTRL+T is quite good, but an on-the-fly auto indentation feature like e.g. in MS Visual Studio would be awesome.
Especially because we'd see much more readable code in the forums :stuck_out_tongue:
But hey, I won't be comparing VS with Arduino IDE..

17: relying on concatenation order of source files is total madness IMHO no, wait concatenation of source files is total madness; #include directives and #define guards were invented for a purpose... if I had the power, I'd take that feature away from the IDE ]:slight_smile:
OTOH, having more than a handful of tabs open makes switching between them a PITA... But again, it's an editor for "sketches", not for "projects". That must tell us something :wink:

18: serial monitor auto-opening would be most welcome.

19: direct hex upload from the IDE ("Upload compiled sketch" maybe ?) is totally useless IMHO given the target audience of Arduino.

20: the main problem I see with keywords.txt files is they add up regardless of the libraries actually used by the sketch.

Can't find the link right now, but there's at least one very popular ide mod around here. One of its marketing points, IIRC, was serial monitor auto-opening...