[catapart]

Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graphics context.

To do all of that and write a text editing library at the same time is a little more than my nights and weekends can handle. If I start on just the text editor, it'll only work in a terminal console, so I won't actually use it for my own projects. If I start on just the GUI, I won't actually use it because it won't actually work. So, even if I'm going to replace the text editing library at the heart of the project with custom code, eventually, it's pretty much a non-starter if I don't have something to use to get started.

To be honest, I'm kind of surprised to have so much trouble finding a solution here. Everything I find is either a self-contained text editor, or a full-on "mission statement" GUI (development can be easier/better by using our editor's features). I've had a very hard time finding something that is just an API that I can feed input and have it return me reasonable state updates about the text content. CRDTs or whatever.

I'm assuming people just figure you're either going to write a toy text editor, in which case simple text editing will work, or you're going to write a full-blown showcase product, in which case your advanced structural design with performance-focused editing, language servers, multi-cursor support, etc, will be your selling point and functional focus. But that seems to leave this surprising hole where a developer who wanted to "rebuild windows' Notepad app, except that it can handle text files with massive lines without slowing way down" would have to actually implement the advanced text editing line management rather than just use a library for this well-solved problem.

[zesterer]

A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI.

You can even use tools like trolley to wrap the entire application up in a ghostty-powered shim that presents the application as a native UI application: https://github.com/weedonandscott/trolley

[catapart]

I appreciate this, but I'm not concerned with the capabilities of the terminal or the GUI. What would be unhelpful, to me, would be to build a TUI because then if I wanted to send the actual app state to - for instance, a web browser which runs the library in WASM - the only way would be to pipe the terminal output across the shared buffer, instead of just blitting the app/editor state into it (or the relevant messages, like CRDTs).

Contrast that with a library: I could capture the inputs from any source - browser, native app, network, etc - work with the data using the single library, and then render the result in whatever client (or as many clients) as I wanted.

[zesterer]

That's fair enough!

[kryptiskt]

Several of the lean GUI text editors are built on Scintilla (https://scintilla.org/), which provides a cross-platform editing component that can be integrated in GTK, Windows or Mac GUI apps. Maybe that has too much bells and whistles for you, since it's both about editing and presentation.

[catapart]

I guess I might be misunderstanding what Scintilla is? Everything I've seen with it has it coupled with native controls, like a winform control or a Qt control. Are you saying that the library can be used, on its own, without a graphical component? If so, that might fit the bill!

[electroly]

Yes, Scintilla is a text editor engine library. It's not tied to any particular UI or technology. Out of the box it's not a text editor yet; you provide the frontend. You get all the "table stakes" right away if you build your editor on this library.

Here's Scintilla driving a TUI text editor: https://github.com/magiblot/turbo

Here's Scintilla driving a custom GUI control (not the system text control): https://github.com/desjarlais/Scintilla.NET

Same engine, different frontends. The engine has a series of hooks that you implement in whichever way you please for your particular interface. It's definitely the presumptive choice here.

[catapart]

Ah, I see! Very cool! Yeah, this is the kind of thing I was looking for, so this should give me what I need to test some proof of concepts. Thanks for the links! I do wish there were something a little more ergonomic, but I'm way too far into the begging to be choosing, here, so I'm quite happy to take what I can get.

In any case, I really do appreciate the dual links. It's so much harder to suss out the boundaries of a library with only one implementation. This was really helpful.

[mizmar]

I would mention stb_textedit.h, but I would not recommend it. It was an interesting thing to study. but the library has many shortcomings and is pain to integrate and use. It is used in ImGui, but somewhat modified. Just to illustrate the flaws - it can't be used with utf-8 bytes easily, there is a large switch on keyboard shortcuts to trigger actions so you have to fake keyboard input to script things, the default word boundary detection is pretty bad, and there is no way to nicely provide double or triple click selection.

The two notable functions are stb_text_locate_coord() and stb_textedit_find_charpos(), which connect the physical x,y coordinates with position in text buffer. They both iterate lines of text - accumulating y position; and the chars of last line - accumulating x position.

For windowing, drawing and OS integration, SDL with SDL_ttf is actually pretty good. SDL3_ttf API got an improvement and no longer requires zero-terminated strings so you don't need to relocate every chunk.

[ivanjermakov]

It's hard to give you a recommendation without knowing the platform details, but if GUI rendering is not the goal, something like raylib might be a great choice to have a cross-platform GUI API, including text rendering.

https://www.raylib.com/

[catapart]

Great recc! Unfortunately, raylib doesn't quite go as far as I would need. raylib does all of the text rendering in a very clean way, so I love it for that. But as far as actual editing, it doesn't have anything for that (last I checked, at least). It can render the text in way more ways than I need it to, but it can't actually do the editing work that prevents the common text-editing traps like line-based editing.

It's kind of an odd thing, I think. There are a bunch of articles on how you can write your own AST and use all kinds of data ranges (instead of heap allocation) to do deep technical performance optimization, but very few libraries that actually do any of that which aren't also bundled into an inseparable implementation of the library as a control/editor. Feels like there has been enough ink spilled over the "how" that someone would have packaged it up together into a referenceable library. Yet nothing I can find quite fits.