Emacs Is Not Enough

> Well, alright, I don't see no CSV-mode to arrange everything into a pretty table and then let me filter/sort/edit the damn thing.

`csv-mode` is right there on ELPA, the default package source for Emacs. You went to MELPA, which only has packages from people who don’t want to license their code the same way as Emacs. Install `csv-mode`, then type `C-c C-a` to format it into columns, `C-c C-s` to sort by a field, and `C-c C-n` to sort numerically by a field.

> A table editor within emacs will be janky, it will be a slow heap of cowdung, outspreading and dispersing, channeling the fumes.

This is completely wrong. There are half a dozen Emacs packages that give you variations on the theme of a table, and none of them are slow or janky in my experience.

> Well, scrolling that thing was not fun, I will tell you that. Neither was getting spammed with:

All the errors you report look like they were caused by packages you have installed, not Emacs itself.

> Timed out waiting for property-notify event

This one is actually caused by your clipboard manager rather than an Emacs package.

Etc.

Existing solutions don't integrate within an environment, and not within each other.

> XML

I go into much trouble to explain my position on general data structures in the article I have linked previously. You can't, in general, really optimize general data structures for specialized use-cases. That's why they are called general!

You wouldn't use a map where you could use a vector, right? But a map would still do the trick, no?

If you start doing all that, you are then trying to fit logs through a meatgrinder. You then have bloat, inefficiency, and all that other good stuff. I mean, you see, this is exactly why we have so many problems right now: people trying to use a general solution for everything. But all those solutions aren't good enough for one reason: they can't specialize. And you can't make them so. (That's the whole point of the topic article, too, just applied to strings.) And they can't interoperate.

> even 99.99% of relevant cases of your domain

Currently, that's more like 50% and the rest is unattainable without access and the knowledge of structure. And the first 50% doesn't even work that well either. I list a few applications on the website, so, don't take this as a bunch of empty claims: those can't be done efficiently (or practically) via the general means.

> Normal editing today is: you press a key, something happens, that's all. Sometimes you add a modifier, but that's mostly it. Vim on the other side, you have modes, you have parameters for key presses, you compose commands to create new commands on the fly. That all is several steps more complex than just a simple key press. Vi-Input is a whole language in itself, highly complex on a cryptic level, all just to macro-manage micro-tasks.

It may be complex in comparison to notepad, sure, but, I mean I haven't seen what's so cryptic about it, not really.

On the one hand, this is a UI problem, so that's just how I would prefer it. When you have a lot of output (like thousands of lines in a batch), you really don't want to go looking for where that thing begins.

On the other hand, you can't easily access the latest execution run programmatically. So, then, the input part shouldn't be there as well.

That doesn't mean you couldn't select a run of input-output dialogue, though. Visually, the run of UI input-outputs could be the same, it's just that how you work with all that stuff that has to be structured.

https://gtoolkit.com/