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 =)
I also use VSCode and derivatives. Also mostly without mousing. But I don’t HAVE to, because I know how to use CLI tooling to not only edit files as needed but also handle things like version control — which I’ve noticed a disappointing percentage of my colleagues, even those with a decade in the field, are mystified by. I haven’t touched VSCode’s git integrations, but the astonishment at being introduced to CLI rebasing — followed by interactive rebasing — was eye-opening.
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..
> 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.
> The Chemical Brothers (a), The Dust Brothers (b)
I had a couple of Dust Brothers (a) cassettes before they changed their name after getting a call from the other Dust Brothers (b).
Still can't believe they knowingly copied another band's name "because it sounded cool". Isn't coming up with a shit name half the fun? "I need a handle man".
> 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.
Yes! I am aware of that functionality, and I've tried it, but this just substitutes the Godot code editor with an external one while keeping the rest of the Godot editor.
In short terms, Godot development workflow has three pieces at least: editor interface(nodes, viewport, etc) + code editor(can be external through LSP) + game/app running.
What I'm trying to say is that app development doesn't strictly need the editor interface at all. For instance, when I'm developing an app with web technology I usually just have a text editor on the left, with my language of choice server side rendering html, and the browser on the right with the "app running".
It would be lovely to spawn the Godot editor and drag around interface components experimenting with them(like the inspector tool on browsers), but usually I just want the peace of mind of having the code and the app running.
So what I'm envisioning is that it would be possible to call Godot in my language of choice just like I would call a normal framework(PyGame in python, Love2D in Lua). With the difference of the powerhouse of functionalities that Godot carries, and the possibility of launching the full editor if desired.
Yes very C-like.. One immediate difference is that in these C-like scripting languages there’s a split between definitions and executable commands. In Cicada there are only executable commands: definitions are done using a define operator. (That’s because everything is on the heap; Cicada functions don’t have access to the stack). I personally think the latter method makes more sense for command-line interactivity, but that’s a matter of taste.
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 =)
I want to do the opposite: Give curly braces to all the indentation based languages. Explicit is better than implicit, auto format is better than guessing why some block of code was executed outside my if statement.
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 =)
reply