I think you're on to something here. For a multi-product dev company, they could (if domain still available) brand as 'without.ai' or 'no.ai' or 'sans.ai' and do 'taxware.sans.ai', 'todo-mvc.sans.ai', 'basecampclone.sans.ai' etc..
Well for git stuff or any CLI stuff, I just key-chord into the integrated terminal (or alt-tab into my terminal emulator, depending on task) and do the git commands, having the whole "git integration" thing disabled in `settings.json` in the first place..
Aficionados of modal editing often insinuate that one would require mouse use in non-modal editing. Yet I have always fully keyboard-operated my non-modal editors, whether VSCode in the last 9 years or previously, Sublime and others, all the way back to Turbo Pascal in the late 90s. I don't ever use the mouse in them, whether I'm inside a text buffer or in the Command Palette (or in menus for the pre-Sublime editors back when). For example, F1 is bound to show "hover" doc tips over the symbol that the caret is in. A couple function keys and ctrl/alt/shift-plus-some-mnemonic letter are soo swiftly and easily muscle-memoried, I never felt any need for mousing, or for "modes" and typing just to switch from one to another.
I'm sure once one is used to modal editing, one can be speedy with it. So can I, entirely without modal yet without mousing =)
> VS Code with the Vim extension is largely mouseless
It's also easily mouseless without any Vim or like extension. I never mouse in it, having given intuitive-to-me keychords to all the various moves I need to make beyond the standard stuff.
Can recommend such a mix, too. Gather select works of The Chemical Brothers, The Dust Brothers, Bassbin Twins, Crystal Method, DJ Krush, Dub Pistols, Lunatic Calm, Meat Katie... and you're Somewhen Else during it. Works for commutes/trips, too.
> but for writing a complete application I would want to develop in my language/editor/ecosystem of choice
For well over a year now, you can use an external editor (VSCodium or whatever) and set it in Godot settings (so that clicking a script icon in the scene tree opens that file, and clicking a signal handler in the properties pane jumps to that line), and the LSP for GDScript (which is hosted by your running Godot instance, and which your editor's LSP client connects to) has been excellent back when I last dabbled in it.
Since I found with searchable app menus / start menus that I don't ever navigate through menus but just start typing, I ditched the menu entirely and have KRunner bound to the Win key. Not only is it fine with any desktop app GTK or not (that packagers have ensured will install with its FreeDesktop metadata file or some such), it supports all the enabled KDE Search plugins. So I don't ever open a calc app again, either..
> transparent switching between skins (about as easy as changing the tab sizes)
One of my pet "not today but some day" project ideas. In my case, I wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts), one by one, via VSCode extension that implements a virtual filesystem over the real one which translates back & forth the syntaxes during the load/edit/save cycle. Then the whole live LSP background running for the underlying real source files and resurfacing that in the same extension with line-number matchings etc.
Anyone, please steal this idea and run with it, I'm too short on time for it for now =)
One of my long-standing "would make if I had the time and perseverance" themes has been a terminal text editor that's hugely VSCode-like + compatible, so always glad to hear anyone going anywhere near that, and hence I perked up from these:
> Prioritizes standard keybindings and a minimal learning curve.
> Extensibility: Uses TypeScript (via Deno) for plugins, making it accessible to a large developer base.
Because where you are now with Fresh, you're probably really not far from supporting say `settings.json`, `launch.json`, `tasks.json`, `keybindings.json`, `.tmTheme`s and theme `.json`s, and indeed bringing up a VSCode-API-implementing "extension host" that can load up and run/host most `.vsix`es. Now, being terminal-based you'd skip over certain feature subsets such as webviews, custom (non-text) editors and the like... and might postpone Notebooks and such fancies initially, but:
Consider! 1000s of high-value, capable, tech-specific dev extensions out there, all readily supported by your just-spawned new editor. Doesn't that sound pretty exciting?
After all, there's a huge subset of VSCode fans who'd always switch in a heartbeat to a just-simply-non-Electron version (whether native or terminal) of the very same feature-scape & extensions & UI dev experience if only it was made and to max compatibility (and MS won't ever do so).
All that's missing (from screenshot glance) is the other sidebars & panels in addition to File Explorer =)
Will be putting your Fresh on my Github Watch list, but then again, I never really read the GH feed anyway.. but maybe I'll remember to check back in every quarter or so =)
Yeah that seems like an area for improvement in Godot's GUI system indeed. For my stuff, I never had a need for theming, but good to keep in mind if one ever wanted to do an app shared with others.
Another homegrown personal tool I had once written was in Go with DearImgui, so basically with AllenDang/giu... also really quite rapid dev and lean-enough binary / perf.
But Godot is wysiwyg for GUI stuff, so that's a plus..
Release build of such a Godot-built tool is between 60-70 MB. Other than that, it seems fast enough & RAM-friendly enough for the usual simple use-cases. Game engines tend toward self-optimization over time.
Godot is neat for personal tool-making where I just need a small gui with basic controls and can express the whole proggie in just GdScript (API has sufficient OS interactions for most needs), I just whip it out for those when I otherwise don't really use it anymore, just keeping it around for that. Stuff like that: https://postimg.cc/VJc0pWbB