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.
TextAdept and its possibilities have intrigued me for a while now; a fast Qt GUI and Lua-based configuration sounds like a sweet spot for me. But I've never fully taken the plunge to configure it for development. I'm open to reading more propaganda for it if you can point me to any :)
> 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. =)
Excellent response, thank you. Ive finally understood the difference between "Desktop Environment" and "Windows Manager".
Calling this stuff "side-show" very much resonates with me. I set this stuff up once when I install i3wm on a new system, and it works well. The problem is when I want to do something that Id never foreseen, there I go into googling for the bash command I need, and that I find annoying.
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.
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..
Mentally I view Nim as a better, safer, easier C++ now. Anything I wanted to do in C/C++ I can do in Nim, but far easier. Not exactly a Carbon competitor but still an alt C++ 2.0 with C++ interopt.
This is a bit controversial, but in my opinion, just manually write bindings for the API surface you care about. There are tools to help automate the process ([c2nim](https://github.com/nim-lang/c2nim), [futhark](https://github.com/PMunch/futhark)), but these tools are mostly for C.
Theoretically if you want to import a large C++ API (e.g. if you were importing Google's C++ codebase*), you could do so with libclang. I was working on an alternative to c2nim that supported Objective-c and C++, which used libclang, but it's currently in my project graveyard. If you're expecting a @cImport from Zig, then the closest you have to that is tools mentioned above to help with the process.
* to be clear, I understand why Google does not want to use Nim instead of creating a new language (Carbon). i.e. readable code output, full control of the compiler and language design, etc.
The amount of manual work to write bindings is minimal, i.e. you can do so simply by declaring a prototype for a procedure and then appending `{.importcpp, header: "<path>".}`, the same for types. And then compile with `nim cpp`.
Compare the way you wrap libraries in Python, Nim requires so much less work - and yet the Python community wraps every C/C++ library you can think of. Again, in my opinion, if you really want a library: wrap it yourself (ideally the subset you need) or rewrite it in Nim.
Also, most of the libraries you have listed have bindings already:
Consider the possibility that without the first 2 problems, the latter 2 examples would be no problems at all. That tells you what to focus on and what to ignore =)
I could be wrong here culturally tho... I've never been in Kathmandu.
On all my Linux setups so far for years now, on German keyboard layouts, AltGr+- and AltGr+Shift+- always worked oob for me for – and —. I easily just got used to using them, things read better than with minuses.
Minimalist fast native (not browser-based) code editor for Windows, Mac, Linux, BSD. Both a terminal TUI and a native-GUI version for each. First-class (ie. by same author) LSP package. Fully Lua-scriptable for needs beyond LSP. Succinct C & Lua code-base. FOSS, and matured & maintained ever since 2007. All the basic table stakes (syntax coloring, multi-select-and-edit etc).
Woulda skipped on Sublime back when, had I known about it then.
OP asked about "SDK Generators for Application APIs". So my guess is like when you want tight Steam integration in your Godot/Unity/Unreal/etc game, or IAP for mobile game, it's not engine-provided, but some engine-external package/plugin/lib that's sometimes called SDK, sometimes not.
I understand these engines have their own full SDK for developing with the engine, but I'm curious about the external ecosystem/integrations/libraries. It isn't a space I'm super familiar with, but I'm interested in it, not only from the standpoint of it being an interesting technology I've never played with before, but also because I'm curious if there are similar issues in the game engine SDK space as there are in the application SDK space.
Or maybe even a whole different host of issues and practices. Not sure, that's what I'm looking into.
