Emacs Is Not Enough

Integration is surface, the interface to the user. Not the concepts or libs.

> I go into much trouble to explain my position on general data structures in the article I have linked previously.

Sorry, but not reading that, not after the first article. Too long, not enough meat, too unfocused. You should write shorter articles and stick to the topic when you want to reach people. Life is too short and full of content.

> 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.

And if you don't work with a solid foundation, you will start accumulating bloat of small pieces.

> I mean, you see, this is exactly why we have so many problems right now: people trying to use a general solution for everything.

That's wrong. Problems will always exist. Everything is a compromise of tradeoffs. It's not possible to have no problems. Well, except to no do it at all. The main reason why people tend to use more generalized solutions, is because it allows them to move faster, and specialize later if necessary.

Structures are also such a compromise. It enables you to handle more and press it into a form, but you will lose liberty to use forms outside your structure. Understanding and managing the tradeoffs is relevant here. There is a reason why we have types in the first place, and not write everything directly in memory like on a canvas. Similar there is a reason why we not have a thousand different types doing slightly the same thing, but use inheritance to build specialized types from a handful of basic types. XML is such a basic type, for tree-structures. And it is a good starting-point to build a foundation for structured editing. It is not the only type, but at the moment, the problem is, that there is not even this.

> It may be complex in comparison to notepad, sure, but,

Notepad is not an advanced editor. Is there even any editor which has a more complex editing than the vi-family?

> I mean I haven't seen what's so cryptic about it, not really.

Then maybe you just don't understand the problems tackled here at all.

That's the kind of viewpoint you get after years of using Unix or Windows.

> Sorry, but not reading that, not after the first article.

Ok. That one is not a rant, but whatever, you are arguing against its contents, and I don't see why I should be repeating myself. Sorry it's too long.

> And if you don't work with a solid foundation, you will start accumulating bloat of small pieces.

Exactly: you need a solid foundation to give you all the flexibility & meta-flexibility that you need. Otherwise meet bloat.

> That's wrong. Problems will always exist. Everything is a compromise of tradeoffs Hey, look, you keep arguing with the article you have decided not to read, and you are arguing with a strawman. I don't know what you think I am trying to do.

> Structures are also such a compromise. It enables you to handle more and press it into a form

You know what real flexibility means? It's the ability to decide when you want structure and when you don't. And this is the kind of structural editing I am proposing: you can simply recreate a string-based editor within it, for any of your elements. At the higher-level, it can be reused. No structure where none is required? Sure. I am all for it. But there's much more structure out there that meets the eye.

> Then maybe you just don't understand the problems tackled here at all.

Or maybe you don't? Because, explain your point better, please.

> show me a better editor than emacs first

I will. Just one correction: it's not going to be an editor. It's going to be many editors forming a cohesive whole.

Rune: Rune Is Not an Editor.

Other than that, what can I say? Yes, I have to prove my words, even though, in my opinion, the writings have enough to convince you that it can be done. And I will do my best to deliver.

I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway).

I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.