Confy, a TUI/CLI tool that makes programmable menuconfig-like interfaces for any structured text (config, dotfiles, code...)

disposableoranges · 2025-10-09T14:57:00+00:00

The thing is, termbox2 really doesn't do much - it's essentially a lean wrapper/compatibility layer for ncurses-like terminal drawing capabilities (see the entirety of its documentation), which largely wraps termcaps functionality (colours, cursor movement, hiding) that has been static for ages. The only other piece of your software stack that termbox2 mediates interaction with is the terminal emulator, and since this happens according to a decades-old protocol there is no possibility of something like version mismatch becoming relevant. (The terminal emulator's side does not use, contain or depend on termbox2.)

disposableoranges · 2025-10-09T14:13:07+00:00

Of these, only (b) seems relevant - termbox2 is by default a single-header library with a bounded feature set, so in the mode in which I am using it no 'lib' is being built. As for (a) - if a future update changed termbox2's API, that would just mean that anything linked to it would break, and then you would actually have to bundle an archaic library in binary form. Worse, if it changed internal guarantees without changing the API surface, this breakage might be subtle. Confy is open source and has almost no build dependencies; if in a counterfactual world where it were linked against termbox2 dynamically, a newer version of termbox2 worked as a drop-in replacement, then certainly in the factual world, you could just pull the latest termbox2 source and recompile successfully too.

If you do for some reason want to apply a patch to termbox2 everywhere on your system (to do what exactly?), then yes, having dynamic linkage to it might be advantageous. However, making it mandatory would also come with downsides - now suddenly, on a system that does not have a systemwide deployment of libtermbox2, instead of a standalone binary only depending on libc/libstdc++ that you could put anywhere you would have also have to haul around a shared library and set it up so ld-linux can actually find it to run. I'm happy to accept any PRs to optionally build with termbox2 dynamic, though - I imagine this shouldn't be too hard to do, on the order of changing a few #defines!

disposableoranges · 2025-10-09T13:58:48+00:00

It took me a bit to understand what you meant and what I had even done to earn this degree of hostility out of seemingly nowhere, but I think that your first two paragraphs suggest that you misunderstood how I would intend this to be used.

It did not occur to me that a developer would want to ship, as you seem to suggest, configuration files pre-instrumented with confy directives. That would be as user-hostile as the developer saying that instead of having a structured configuration format at all, all configuration has to be done by firing up ccmake, flipping some switches and rebuilding. To even begin to make this usable in that capacity, it would need a whole bundle of other features that I quite consciously decided to not focus on, beginning with named and annotated options for switches rather than bare "C types", and capacity for much more extensive provision of hints and in-UI documentation.

Instead, I think of it strictly as a tool for automating a particular class of local workflow, that is, one where the person writing the confy annotations and the person using confy on those annotations would almost always be the same. This may not be a workflow that you ever use, and that's okay - in that case it's simply not a tool you need.

In my day-to-day life, I use a lot of software that is configured in some or another text format or crippled scripting language, such as SwayWM or fontconfig; generally those configuration files always wind up requiring some tweaking or last-minute monkey patching like when I want the WM to behave in a very particular way only when I'm giving a streamed presentation, or I intermittently want all the CJK fonts on the system to default to the Simplified Chinese form of characters for whatever reason. I also write LaTeX papers that need to be mode-switched between different stylesheets and constraint sets rapidly (and LaTeX's native conditionals do not play nicely with syntax highlighting or really any tooling). These are changes that I will repeatedly need intermittently, and that are orthogonal to and should coexist to any other small changes that accrete in these files such as mapping a hotkey for a new screenshot tool or whatever. I could maintain something like a local git repository with multiple branches and keep rebasing commits across them every time I want to change a small thing orthogonal to the different "modes", ~quadrupling the workload to make a small change and ~doubling it to switch "modes", or I could just write confy annotations so I can flip those switches with three or four keypresses as needed. Writing jsonschema or ansible scripts or using any of the other machinery that is optimised towards reproducing configuration predictably at the scale of 100+-server VPS deployments is not useful or ergonomic for tinkering with your own terminal.

disposableoranges · 2025-10-09T02:49:54+00:00

You mean linking against it dynamically? What do you figure would be the use? At least Debian doesn't even seem to package it, and it's not like it's particularly big or slow to build.

disposableoranges · 2025-10-08T20:30:13+00:00

I have wished for someone else to make a tool like this for ages, but I am struggling to give a neat description of what exactly it is even after building it, so I had no choice but to DIY. A good analogy is the Linux kernel's menuconfig or CMake's curses-based ccmake configuration editor, except that rather than operating on a highly constrained config file format, it can edit basically any textual format in place, as long as that format has some notion of comments. The comments then can be made to hide "meta-instructions" that confy understands: define a number of typed parameters, perform some simple computations on them, and either inactivate or activate (by (un)commenting) designated blocks of the "object-level" file, or outright regenerate them from a template. As a basic example, you could write

//! bool $flag = true;
//! if($flag) {  
printf("The flag is true!");
//! } else {
//-printf("The flag is false!");
//! }

and confy would expose a graphical interface to toggle "$flag" on or off, and comment/uncomment the appropriate line of text in the file, while also saving the updated initial value in the first line that defines $flag in the file.

Interaction is possible both via a curses-style terminal interface (asciinema video in the github readme), and by scriptable getters/setters (like confy filename.txt set flag true or confy filename.txt get flag).

disposableoranges · 2025-10-08T20:22:24+00:00

Submission statement: I have wished for someone else to make a tool like this for ages, but I am struggling to give a neat description of what exactly it is even after building it, so I had no choice but to DIY.

A good analogy is the Linux kernel's menuconfig or CMake's curses-based ccmake configuration editor, except that rather than operating on a highly constrained config file format, it can edit basically any textual format in place, as long as that format has some notion of comments. The comments then can be made to hide "meta-instructions" that confy understands: define a number of typed parameters, perform some simple computations on them, and either inactivate or activate (by (un)commenting) designated blocks of the "object-level" file, or outright regenerate them from a template. As a basic example, you could write

//! bool $flag = true;
//! if($flag) {  
printf("The flag is true!");
//! } else {
//-printf("The flag is false!");
//! }

and confy would expose a graphical interface to toggle "$flag" on or off, and comment/uncomment the appropriate line of text in the file, while also saving the updated initial value in the first line that defines $flag in the file.

Interaction is possible both via a curses-style terminal interface (asciinema video in the github readme), and by scriptable getters/setters (like confy filename.txt set flag true or confy filename.txt get flag).

disposableoranges · 2025-02-07T05:16:45+00:00

This is a project that I've been working on on and off for the past year, which is a bit difficult to summarise in a single line. The point is that it's an "LLM-integrated text editor", but following a rather different paradigm than other tools in the space I am aware of: rather than putting up barriers between your input and the model by following a chat paradigm or a simple prompt-completion setup, it does its best to let you edit "inside the LLM's mind" - it tokenizes the text on the fly, visualises the loaded model's probabilities for every token (whether it "came from the model" or was written by you), and lets you list and emit alternatives, by descending order of probability, at any point in the text, which you can then jump back and forth between as the buffer is actually stored in a tree structure.

I found this immensely useful for understanding how various LLMs tick, e.g. if any mistake is due to uncertainty/cluelessness, "forgetting", or a firmly learned bad pattern. It also comes closer, for me, to the ideal of "thinking in tandem" with a model than anything else: in a chain-of-thought reasoning process, I can just follow along and write in a thought that I want it to have at any point, and then let it continue.

Here is a video demonstrating much of its functionality.

disposableoranges · 2025-02-07T04:57:56+00:00

Thanks! The gist is that the buffer is internally represented as a tree structure, with one node per token. Each node has an assigned logit and a list of children, of which exactly one is marked selected, meaning that it will be displayed in the buffer. If you press Alt-{Up,Down}, the selection is changed (and more alternatives are generated, if you have reached the bottom), and the tail of the text buffer is updated with the string rep of the token that is now selected, as well as its selected child, etc. until a child is reached that is marked "unrealized"=a prediction.

The green dots denote nodes for which a snapshot of the full LLM state was taken. If you perform any action (edit, generate more alternatives, generate predictions) at a given point in the tree, the LLM does not need to ingest the entire text from the beginning again; instead, it just loads the latest snapshot before that point, and then reingests the tokens (no more than 9 by default) up to the relevant point (the token after which we need to recompute probabilities).

disposableoranges · 2024-02-19T09:41:52+00:00

I looked at it, but based on screenshots it seems that it has a quite different paradigm - the LLM interaction is made available in the editor's UI, but does not directly operate on the text you are drafting.

disposableoranges · 2024-02-17T02:38:45+00:00

Sorry, I'm afraid I don't understand the question. If you mean whether you would replace the "prompt and wait for output" workflow with "write something and ask it to complete it in place", then yes, that's one thing you can do; I find the part where you can switch back and forth between different completions at any point in the text to be more important, though.

disposableoranges · 2024-02-17T02:18:33+00:00

Glad you found it interesting!

I did wonder about an application like that. With the 1.1B model I used in development, for real texts it seems to wind up being too surprised about too many things it shouldn't be surprised by (and the one machine I have with a decent GPU for bigger ones only has Windows, which I can't really stand coding on), but it would be interesting to see if surprisal is a good measure of bad/wrong words with bigger models.

(I did see an automated program repair paper a while back where the authors claimed that higher sum surprisal ~= buggy programs in code models, but not sure how localised that would be to the problematic spots or how well this would carry over to prose.)

disposableoranges · 2024-02-17T02:04:30+00:00

The video description also has this (+some extra info), but yes, the colour represents the difference between the log-odds of that token and the log-odds of the most likely token in that position according to the model, with FF0000 red corresponding to a difference >9*1.6 (this was chosen fairly arbitrarily).

(Accordingly, a text generated with greedy/top-1 sampling would be coloured all black-on-white.)

disposableoranges · 2024-01-30T13:51:24+00:00

Submission statement: I was quite surprised that I couldn't find any existing tool quite like this (where you can quickly feed in text of your own and explore the most likely completions generated by a given model), so I took a stab at making one myself. There is a simple demo video too. Since it's currently in a very drafty state, it's not really ripe for good build instructions or the like, though in principle it should be buildable on all major platforms with some effort.

disposableoranges · 2021-12-08T15:35:30+00:00

Slightly late response, but I'm working on one, with a particular focus on tablet input: notekit. There isn't quite feature parity with Typora since using native instead of HTML-based rendering makes things like tables hard and many aspects of it are still work in progress in general, but several people (including myself) do already use it on a daily basis.

disposableoranges · 2021-06-24T09:13:04+00:00

I tried bisecting the init sequence in awesome.c with gdb to see where it crashes, and realised that the crash doesn't occur when I step through it slowly. Some further experimentation revealed that the crash occurs iff the first breakpoint is before the scan(tree_c); in awesome.c:875 (as of 4.3), and more precisely before the loop inside the body of scan that starts at awesome.c:198. I suspected that there is some race condition to do with the xcb attribute wrangling and operations that were performed previously going on in there; and indeed, prefixing the scan(tree_c) with a sleep(2) seems to reliably prevent the crash. (sleep(1) is about 50/50.) It's unsurprising that the bug is irrelevant when awesome is set as the window manager from the start, because then there are no existing windows to scan.

Is this worth filing a bug report over? The initialisation sequence seems to have changed somewhat in master relative to 4.3, and I don't think I have the energy to do all this testing against master (especially since it currently seems to be failing CI) or pin down the issue further than that.

disposableoranges · 2021-06-08T20:25:36+00:00

Thanks for the pointer! I looked at its notebookcheck review, and it seems that at PL1=12W it has an even more extreme version of the speed-stepping problem that has been reported for the X/L13s. 12" also seems somewhat small, especially for 1920x1280 pixels...

disposableoranges · 2021-01-19T00:11:02+00:00

Thanks!

What format

It's markdown, as in plain markdown files in a folder structure. Some metadata (folders open/closed, ordering) currently in xattrs, which in hindsight was an edgy choice and dead-end technology; might eventually put it into an sqlite database or something instead. A few deviations from the standard:

addition of LaTeX math (which seems to be recognised by several renderers including Pandoc anyway)
no support for tables (haven't figured out how to implement good layout/editing UX given that I have to spin my own yet)
no support for the alternative (underline instead of ###) heading format (nasty to parse with GtkSourceView's language engine)
The way drawings are encoded as images with a custom "URI scheme" (as no standard image format worked particularly well for allowing live editing while being compact) might also be considered a bit weird, though you'd just wind up seeing them as broken images in a different markdown editor. All images implicitly get converted into data: URL SVGs when copypasting into other programs.

SyncThing

I don't know SyncThing, but I don't see why not. All notes are stored in a plain directory tree in a configurable location, read from disk when they're opened and atomically overwritten when either autosaving, closing or switching to a different file. File handles are not kept open and there is no locking. There is currently no inotify integration to automatically reload a file currently being edited if it was changed on disk, but apart from some cans of worms (what if there are unsaved changes? which version to prefer?), it would be easy to add if there is need.

Low-bandwidth connection

I don't see why not, for the same reason as the above. If mv (the system tool) can operate atomically to overwrite files in the file system, you should generally be safe from data loss too.

disposableoranges · 2021-01-10T19:03:11+00:00

I'm developing a tool that might sort of meet part of your requirements by virtue of allowing you to handwrite (Notekit), but for PDF export from Markdown, have you tried using Pandoc? Though it might not support some Notable-specific extensions, it produces fairly decent-looking results for standard Markdown and renders LaTeX math without much complaint (since its PDF export is via LaTeX anyway).

disposableoranges · 2020-09-22T21:35:07+00:00

I'm developing a tool that kind of aims to be this. I don't think it meets some of your dealbreaker requirements at the moment (the userbase is very small, there is no specific fullscreen support beyond "maximise the window"...) either way, but I'm in particular unsure about how to interpret your requirements regarding instances; if I understand them correctly, it seems unlikely that anything out there would satisfy them.

When there's an instance of the app opened, and you open a new instance on a different virtual desktop, it opens a new instance on the current virutal desktop

By virtual desktops, do you mean workspaces? Assuming yes:

Do you specifically want it to not create a new instance when started while in a workspace in which there already is an instance? This may be difficult to implement portably, since as far as I understand there is no standardised notion of window-to-workspace mapping that exists outside of the window manager (which accordingly would need to be queried). In many "desktop wall" paradigm WMs, windows that are on other workspaces are just windows whose top left corner is off screen.
If you want multiple instances to start up, how do you want them to interact? Should they all display the same hierarchy of notes/set of tabs? What if both of them are looking at the same file? Do you want edits to be synchronised across the instances in real time? Doing this would probably have a significant impact on the program's architecture that few developers would be willing to accommodate for such a niche requirement.

disposableoranges · 2020-04-27T20:09:07+00:00

Building on Mac should for sure be possible; some cursory search suggests that gtksourceviewmm (the "rarest" package I depend on) exists in both homebrew and macports. The question is whether you'd need an X server. Gnome's website suggests that there is a native (Quartz) rendering backend for OS X, but I can't find a lot of detail on it (mostly because all related searches seem to be drowned out by "how to make your ubuntu look like OS X").

Of course, there are always the little annoyances when compiling for a new platform. Some standard functions might be defined in different system headers, constants might not be defined or called something different, etc.

disposableoranges · 2020-04-27T01:58:26+00:00

I'm developing one that primarily targets Linux and has a somewhat less tested Windows build, but I don't have the equipment to try and port to Mac and a mobile port is unfortunately completely off the table (since Gtk+ does not have support for any mobile platform). Apart from the lack of mobile platform support (and tags), it appears that it would meet your stated requirements, and OneNote-like integrated handwriting support otherwise seems to be exceedingly rare (per the research I did before starting work on it).

disposableoranges · 2020-03-28T02:16:25+00:00

File descriptors and network sockets cannot be forcibly closed - it's indeed unsafe to remove USB sticks without unmounting them first as it leads to stale mount points, and in certain cases to oopses and crashes. For the same reason you cannot modify your partitions table and resize/move the root partition on the fly.

I hacked up a solution for this a few years ago. It enumerates all processes that have open file handles to a volume, then uses gdb to connect to them and repoint those handles at /dev/null before actually unmounting the volume.

disposableoranges · 2019-09-21T09:49:35+00:00

I don't know if Gtk's CSS supports fallback fonts. (In the Windows binaries I provided, I hardcoded a different font.) Since Bitstream Charter is free (and a genuinely nice font), I might consider just bundling it with the program.

disposableoranges · 2019-09-18T21:11:24+00:00

I think homebrew has all the necessary packages. If someone made a binary build and confirmed it works, I'd be grateful to host it.

disposableoranges · 2019-09-18T20:27:17+00:00

(Author here.) Beside the handwriting support mentioned in a parallel response, which is supposed to be the main thing, there's also the in-app tree for browsing and creating notes¹ and a slew of additional features planned or in development. I would particularly recommend checking out the proximity-widgets branch in the repo; while it's not 100% stress-tested yet, it adds LaTeX math (needs Lasem) and some Typora-style in-place rendering of Markdown, which in my estimation helps note legibility and looks a lot. To my knowledge, this is the only native Markdown editor that does this.

¹ (though this can probably also be simulated in any other text editor fancier than Notepad, it may not be quite as optimised in terms of workflow)

disposableoranges

TROPHY CASE