Exactly. Before I invest in any fussiness, I want to see what the no-fuss native installed VSCode offers, leaving some fuss-budget for all the stupid key-stroke learning any new editor entails.
Like needing to press return twice after typing import time isn’t helping me!
While my first job out of college was to build a microprocessor software development system (at Hewlett-Packard) that offered context sensitive editing, cross-compile, remote execution with trace and debug, (and even logic analyzer functions as well), I spent 40 years preferring if debug: print("got here"), and to this day do not miss breakpoints, debugger, and variable inspection in the slightest, and have generally used multiple monitors for “context-sensitive help”.
Also remote debug with multi-threaded or multi-processing is an exercise in futility most times.
Give me an editor and a console window and I am very happy. If that editor has context sensitive help that does not obtrusively get in my way then perhaps the whole IDE thing can be tolerated.
Being a Mac user, things like key mappings and setting up remote communications (like in VNC authentication) complicate trying new things. If native VSCode convinces me I can’t live without it, then the next step will be to investigate remote development with VSCode.
Wow - didn’t have to do anything to configure git - VSCode somehow knew about my git repo for Legacy Dave and tracked changes (git status), allowed “staging” (git add), and “commit” (git commit).
I couldn’t figure out how to do the git push so did that in a term window…(Found push under … more actions)
Possible Memory Leak?
Seems like the native VSCode might have a memory leak (or two…), as evidenced by the available memory starting out around 280MB and ending around 60MB with a dip to 44MB at one point.
Before VSCode (fresh boot): 681MB
VSCode initialized with Editor and Terminal panel: 285MB
VSCode running program in one Terminal, Editor and 2nd Terminal panel: 260-240MB
VSCode running program, plus editor and 2nd term, repeated changes, reruns: 80-44MB
After VSCode exit: 689MB
Danger lurking
Had an editor and two term windows open, and tried to delete a hidden term window - the processor load went sky high and never recovered. Was not able to gracefully shutdown, but the system and VSCode seemed to unscathed after rebooting.
This kind of problem is exactly the reason I abandoned a native install - I could not trust it for any length of time to not crash or load down my robot unacceptably.
This is because the ext-4 filesystem is a journaling file system. This kind of graceful recovery is NOT guaranteed and I have totally trashed filesystems using VS Code natively.
I would humbly suggest you do the same after completely uninstalling, (ape-get purge), the original installation.
I would also suggest forcing a boot-time e2fsck by using tune2fs and setting the current mount-count to a value larger than the maximum mount count and then reboot the 'bot.
P.S.
I would strongly suggest that tune2fs be used to set a maximum interval AND a maximum mount count to prevent inadvertent corruption of your robot’s filesystems. The man page for tune2fs goes into some detail as to why this is an excellent idea.