dualogy

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.

> Using electron or GTK or whatever

You say that like they're in the same category, but one is an embedded Chromium and the other a native windowing toolkit.

> as practically all so called c++ libs also export a c header as they know how important it is

In the gamedev space, I'd say too few of them do.

> 90s/early 2000s breakbeat songs

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.

AngelScript. Matured & maintained since 2003, is fully typed and with C syntax. https://www.angelcode.com/angelscript/

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..

Gives "Non-Image content-type returned", I guess GH doesn't like hot-linking its hosted user assets.

Might want to link the `.md` that embeds it instead, if any

> 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 =)

Goood stuff!

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 =)

For flow-compatible electronica, let me add specifically:

https://netlabels.org/electronic-music/

https://files.scene.org/browse/music/

https://netlabelarchive.org/

https://freemusicarchive.org/label/all/

Also very neat is DearImgui via either https://github.com/AllenDang/giu (Go-convenient wrapper) or https://github.com/AllenDang/cimgui-go/ (raw bindings)

That is both .NET stuff, Wails is one of various Go options.

> Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach

Speaking of writing JS instead of JSX or your example, I like the vanjs.org approach:

    const Hello = () => div(
      p("Hello"),
      ul(
        li("World"),
        li(a({href: "https://vanjs.org/"}, "VanJS")),
      ),
    )
    van.add(document.body, Hello())

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

Well, lobste.rs has tags and then you can block whatever tags you choose to block, and for HN you'd need a reader that classifies / auto-tags posts and allows blocking out tags, which you'd start doing after verifying the auto-tagging classification works reliably.

Sounds like a bit like a tall order, not sure it's "just a weekend project", would (for my purposes) probably work best as a browser extension for just the listing of posts (auto-tagged and then optionally tag-filtered) to then open them in one's browser, allowing normal native reading+posting+voting+etc.

> the intros really undersell how bad the experience of using SAT solvers directly is, the DIMACS sat file format makes me think of the year 1973

"MiniZinc" is the name of the Pythonic-ish-like syntax targeting (ie on-the-fly translating to) numerous different solvers (somewhere around half-a-dozen to a dozen or so, don't recall exactly =)

> My impression is that it was going to take a few years for things to shake out. Is that wrong?

I had that very impression in early 2020 after some months of Zigging (and being burned by constant breaking changes), and left, deciding "I'll check it out again in a few years."

I had some intuition it might be one of these forever-refactoring eternal-tinker-and-rewrite fests and here I am 5 years later, still lurking for that 1.0 from the sidelines, while staying in Go or C depending on the nature of the thing at hand.

That's not to say it'll never get there, it's a vibrant project prioritizing making the best design decisions rather than mere Shipping Asap. For a C-replacement that's the right spirit, in principle. But whether there's inbuilt immunity to engineers falling prey to their forever-refine-and-resculpt I can't tell. I find it a great project to wait for leisurely (=

Even with JS/TS app code, instead of Electron, you can still also use Tauri afaict: just minimally get the Tauri binding up in your compiles-to-native lang of choice, and then one can still write the overwhelming bulk of the GUI in JS/TS (and perhaps even most/all of app logic, depending on how much of it is expressible via browser web APIs).

Certainly less bloat this way than Electron, for those with a taste for JS/TS.

TextAdept, the most criminally-underhyped high-quality text editor that I know of, has supported LSP for quite some time now IIRC, and has (not just GUI versions but also) a first-class TUI version.

> The tone of the article sounds so breathlessly over-excited that it's bordering on self-parody.

Welcome to every Wired article ever, certainly from its inception well into the mid-2000s at least.

Today it's at best amusing, but those were times just 1-1.5 generations ago when that was truly, genuinely generally enjoyed (by techies & youngsters) as neither Tired nor Expired but (Hot)Wired, and as a needed/welcome breath of air in an ocean of seemingly-immutable last-century whiffs & echoes =)

> We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Would be totally into that! But then as soon as you're developing for a worldwide paying audience (or your employer is), one manager realizes the need for ARIA stuff, another for SEO, another for fully-native input controls (textboxes, checkboxes, radios, buttons etc) for most-fluid&familiar UX on every OS, another for embedding externally loaded markup+scripts (whether that's social media sharing widgets, auth providers, Google Maps / OpenStreetMaps etc), for supporting user-generated `<img>`s and `<video>` in all the various formats the browser natively furnishes, and on and on and on =)

I used i3 for a few years before switching to KDE 1 or 2 years ago. For me choosing a full Desktop Environment over just-a-window-manager is about getting all the basics already co-installed with it: a default file explorer, default calculator, default terminal other than xterm, especially a default network-manager GUI, a sys-tray already populated with volume / screen / power / bluetooth / mounted-devices / clipboard / clock & date, a launcher, a system-wide config GUI ... without a DE, every single one of these is a manual install (plus researching the best choices and verifying & comparing their quality live) and/or numerous configuration files in diverse places, googling their syntax / incantations ... since all this stuff is "side-show stuff" (ie not my code editor, browser, email client, office suite), I nowadays appreciate batteries-included when setting up a new machine, reducing overall time-to-code-editing. But the endless custom-tweaking back then was good fun back in its own right. =)

Wicked, fully FOSS for non-console targets, I had some fun with earlier this year, it's a great very-modern full-featured D3D-or-Vulkan renderer under active development with a lively yet cozy-sized community (including a handful of folks taking care of the Linux side). The API is easily learned and can be operated via your game code from Lua or C++ or a mix, as you see fit, with Lua scripts being executable also in Wicked's editor app (Windows/Linux).

My hunch is that by sticking to just Windows/Linux/consoles and firmly-decidedly-skipping other cross-platform platforms such as Apple's Metal, mobile's OpenGL, WebGL/WebGPU/WebAssembly, it is kept maintainable, unbuggy (not 100s of bug-tagged Open Github Issues) and capable of ongoing rapid feature iteration.

> Nim has fantastic interoperability with C++

Last year I asked around in the Nim community if "the C++ interop" will allow me to easily link-to-and-import in Nim a C++ lib (in this case, a 3D engine called WickedEngine) and thus make a game using its surface API from Nim instead of writing it all in C++.

There seemed to be no straightforward way to do so whatsoever. Sure you can import old-school C APIs. Sure maybe you can have Nim transpile to C++ code. But "fantastic interoperability" didn't have my fantasy here in mind: something like `@importcpp "../libwickedengine/compilecommands.json"` and boom, done, including LSP auto-complete =)

It would be the same for other major C++ libs then: think LLVM, Dear Imgui, Qt, OpenCV, libtorrent, FLTK, wxWidgets, bgfx, assimp, SFML......

Sure, I get it, "unlike C, C++ doesn't have an ABI. These C++ libs should maintain and expose a basic C API". I agree! But still..