I have so many ideas I want to build that require a text editor. I often feel that if the editing sucks, the whole project just won’t feel nice. But recreating a decent text editor (by this typically mean for code) is always a reasonably big undertaking. What I’ve started working on is a headless editor. There are some that exist like xi, but I’m aiming for something a bit simpler. Right now I’m dealing with proper cursor and multi-cursor support. I’m going to be working on a few implementations for textbuffers. Going to add treestyle undo and redo. Going to get syntax highlighting working. What features would you want in a library like this?

Hooks. Hooks everywhere. • first class ingress into any smart tools; expose parsed syntax in some way . Flat file of tree structure? Edit history? • Configurable anythings. Make a giant config file in whatever you want to use and make all cool decisions there. Local process endpoints, formatting choices, etc • if headless, the output could have preformat mode or raw “markup” mode. The former gives you pretty printable text, the latter spits out the formatting scheme you use to do your highlighting/ tree info, etc. • If you do any LSP integration of any kind, expose the high-level query results in the same way to act as a smart intermediate.

smart-editor

—`headless -findusage “class User” -dir .*` if you’re lucky, you can use the LSP for even stronger highlighting

When you say "headless" what do you mean? What stuff wouldn't this library do?

Primarily, it wouldn't render or be tied to any particular way of rendering. It wouldn't handle any direct IO. So no "if i press this key or click this mouse button". I also wouldn't want to tie it to any particular way of thinking about open files, buffers, tabs, whatever. Think of it like a backend for any code text editor you could want. That's the goal

But the backend would still do, like, glyph positioning? (You'd need that if you're going to handle wrapping and cursor positioning, I'd think)

Are you building on the Web? If so, I'm curious why not start with CodeMirror. CodeMirror 6's extension system is sophisticated and capable, and if it doesn't accommodate your needs you can mess with the source. If not the Web: I'm less familiar with options, but would be surprised if there weren't an analogous project to start with. Basically: Making a nice-feeling & featureful text editor is hard, and I wonder why not start with something that already works, if your goal is to experiment with an idea where the text-editor itself is not the focus.

It would handle things in text space, but not in screen space. So if I say move-right and there is a unicode character, the cursor should move N bytes in the text-buffer where it is now at the end of the unicode character, not split it. But it wouldn't tell you the pixel to render at. Wrapping could be out of scope? I don't know. Maybe the renderer can cooperate? Not sure whose responsibility that should be. But I'm fine with that following on the "not my job side"

Hi Jimmy. I had this exact problem, so went away and built a Vim & Notepad-like editor for my own use. While not headless (and perhaps I should have made that split more obvious), it does separate the buffer management from the rendering (which can be either ImGui or Qt). I wrote lots of little unit tests, which I found invaluable when things got complicated and I didn't want to break stuff. It's a big undertaking, and I'd do things different if I started again, but it has been useful. There is a video overview on the page.... https://github.com/Rezonality/zep

@Chris Maughan That looks awesome! Definitely going to look into this 🙂

FWIW, My focus was: • Enable VIM use wherever I built something / enable other users to switch to non-modal editing. • Enable editing inside a 3D/graphics environment. There were other motivations, as you can see from the project page; but those are the top-2. The hardest parts: • Key mapping/supporting various editing modes/features.. • syntax highlighting • Intellisense (I haven't done any of that) • Unicode/international rendering.

Super helpful resource and information. Mine will definitely have a bit of a different focus. Sense it is primarily for me and I’m anti-modes, definitely won’t be worrying about those :) For my goals, this is one part of many projects I want to make. Playing with making my own debugger for my day job work. There I at the very least need to be able to display code with color syntax. But for scripting/interactive programming I want an editor. I also have a mega project in my head for making a truly integrated development environment. A place for my computation to live and grow. Where I can extend my own editor in the process of coding.

If you want something more basic/non modal, you could also look at: https://github.com/BalazsJako/ImGuiColorTextEdit This is another ImGui based editor; it is in a single file; although it has a UI, there is much in there to do with handling standard editing modes & syntax highlight; you might find it useful. FWIW: in my day job I work on source editors & some UI parts of debuggers too. But we use Scintilla under the covers (https://www.scintilla.org/). It is a pain to integrate, but it has a lot of features. We use another layer on top of it, since our tools are Qt based.

I just want to say, having tried both: a text editor is a much more fertile trailhead for FoC experiments than a programming language. This realization has been building slowly, but seeing so many others take this path adds weight to it. --- @Jimmy Miller Do you have an idea of the API a headed editor will use to interact with this headless backend? Hmm, I haven't looked at all at Neovim's API..

Right now, I’m less interested in the remote setup and more interested in a headless editor library. Both Xi and neovim focus on process model, I would be down with layering that on, but not my primary usage. I’m not sure exactly the shape it will take, but I want it to be fairly lightweight yet customizable. Customization though would come from using the parts differently, not configuring things. I think Casey Muratori has some really good advice on api design So the plan is to start with small bits of functionality and make them nice and compositional.

I'm not sure what you mean by "remote setup". I think I'm basically asking how you will try out the headless editor library as you build it. I was assuming it would be by creating throwaway editors using it. Are you imagining some other approach?

Part of the motivation for the project was because I keep procrastinating on building things because I can’t find a gui setup I like. So I’m probably going to ignore building anything graphical. Maybe I’d do a command line one? But I feel like that is a potential distraction. The goal is to have a good testing setup. To evaluate things on performance and correctness. Once I get my work debugger stuff going, maybe I’ll integrate it there? Maybe I’ll backport it to my last experiment? In general, I’m down with not making something graphical. Though I am considering like animated gifs of test failure or something. Not sure.

Simple, headless text editor? Sam's a classic and my dad's still using it http://sam.cat-v.org/.

My tests boil down to a tonne of macros like this: The strings are: 'name', 'start text', 'commands to the editor', 'expected result'. COMMAND_TEST(paste_p_linewise, "(one)\ntwo\n", "Vyjp", "(one)\ntwo\n(one)\n"); This one tests that you can select the whole line, yank it, move down a line, paste it below I think a set of tests like this are essential, since as soon as you tweak the guts of the editor, it's really easy to break a small feature somewhere and not notice for a while.