3 ms·

> But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". What does that mean? > start wi

> But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". What does that mean? > start with structuralizing the {} brackets. That's a semantic unit. So, vim. Getting simple structure done is not the problem. We have them everywhere and everyone can build their own tools in proper environments. Supporting the big picture and custom structure is the unsolved problem. The best we get in that realm would be support for XML, Lisp, maybe also JSON and YAML and the likes. But all those are hyper specialized tools, optimized for those specific cases. What we lack is something good which generalize this. > The gist of it boils down to the fact that you don't need to start at that very complex level, No, there is, there always is. Because if you start simple, you always end up with the wacky unsatisfying solutions at some point. Nothing scales well to infinity. Micro-managing and macro-managing are different scopes with different solutions. Simple is good for the micro-levels. Complex is good for the macro-parts. Think about the text-editing of advanced text-editors, and the abilities of vim. Advanced text-editors are simple, and not bad. But compared to the complex editing of vim it still cannot be compared.

some-mthfka 4y ago
> What does that mean? That means they are trying to solve some very difficult, general problem first. But, you see, that's exactly the problem: you don't want to go general. You want to go: specialized. And here's the key: then you want to mix and do the interplay for your simple, specialized well-working elements. And, indeed, you can define some general interface properties for that, once you have it. > Getting simple structure done is not the problem. I agree! > What we lack is something good which generalize this. I can't emphasize this enough, but trying to find a general structure and fit it for everything is a path to failure, and I am arguing vehemently against such structures or approaches [1]. Strings are such a general structure. Although there were others proposed, like Ted Nelsons zig-zags. That's where you do not want to go. But again: generalization is not the problem, the problem is the ability to specialize. But, yes, you are right: there has to be an overarching system, and that's exactly what I want to do. A system where the simple parts can interplay. And importantly: embed. The simple structures I listed, and a few others? Those will be enough for the applications that I want to do. And that will be plenty useful to me, already at that. See, the fact of embedding itself lets you manage the complexity, because that's where a lot of complexity lies within: in hierarchies. And then, when you are doing editing operations, you have full and easy introspection into all the structures that you are operating on, so, doing them right will be possible. PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. PPS I am sorry for responding slowly, there are quite a few comments. [1] https://project-mage.org/on-flexibility https://project-mage.org/on-flexibility
- PurpleRamen 4y ago
  > trying to find a general structure and fit it for everything is a path to failure Depends on whether you consider everything literal. That nothing can solve everything and your mother is obvious. But solutions which can handle majority, or even 99.99% of relevant cases of your domain, I think we already have that today for structures. XML for example was optimized for decades to handle structures. Not all parts are good for the majority of cases, but the general ideas and concepts are universal enough that flavors of them will always appear when tackling such problems. So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases. > PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. 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.
  - some-mthfka 4y ago
    > So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases. 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.

some-mthfka 4y ago

> What does that mean? That means they are trying to solve some very difficult, general problem first. But, you see, that's exactly the problem: you don't want to go general. You want to go: specialized. And here's the key: then you want to mix and do the interplay for your simple, specialized well-working elements. And, indeed, you can define some general interface properties for that, once you have it. > Getting simple structure done is not the problem. I agree! > What we lack is something good which generalize this. I can't emphasize this enough, but trying to find a general structure and fit it for everything is a path to failure, and I am arguing vehemently against such structures or approaches [1]. Strings are such a general structure. Although there were others proposed, like Ted Nelsons zig-zags. That's where you do not want to go. But again: generalization is not the problem, the problem is the ability to specialize. But, yes, you are right: there has to be an overarching system, and that's exactly what I want to do. A system where the simple parts can interplay. And importantly: embed. The simple structures I listed, and a few others? Those will be enough for the applications that I want to do. And that will be plenty useful to me, already at that. See, the fact of embedding itself lets you manage the complexity, because that's where a lot of complexity lies within: in hierarchies. And then, when you are doing editing operations, you have full and easy introspection into all the structures that you are operating on, so, doing them right will be possible. PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. PPS I am sorry for responding slowly, there are quite a few comments. [1] https://project-mage.org/on-flexibility https://project-mage.org/on-flexibility

PurpleRamen 4y ago
> trying to find a general structure and fit it for everything is a path to failure Depends on whether you consider everything literal. That nothing can solve everything and your mother is obvious. But solutions which can handle majority, or even 99.99% of relevant cases of your domain, I think we already have that today for structures. XML for example was optimized for decades to handle structures. Not all parts are good for the majority of cases, but the general ideas and concepts are universal enough that flavors of them will always appear when tackling such problems. So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases. > PS I have been using vim for quite a few years, and I don't see it as some kind of complex editing (other than bindings and modality which takes getting used to). Maybe I am misunderstanding what you mean by this exactly, though. 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.
- some-mthfka 4y ago
  > So instead of build yet another new solution, maybe just look at the existing tools and how we can make them more useable for your usecases. 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.