Live data from Hacker News

Emacs Is Not Enough

project-mage.org

51–60 of 163 posts

Re: Emacs Is Not Enough

#51
It would be interesting to have such a general project go somewhere.

While in principle structural editing sounds like an incredible advance, there are 'good enough' advantages to plain-text tools that make it a much more practical solution. The other issue is of course integration with existing tooling, which you either skip entirely or compromise on the design.

What I feel is missing, between the description of "old, bad state of things" and "utopian vision" is a review of some of the projects that already tried to achieve this ideal state. It turns out there are a number of them, and most of them failed to achieve any traction or impact [0].

The rants are very long, so I skimmed quickly the one about git; I understand the complaints, although git is only bringing me joy and no pain --interactive rebase, absorb and a few aliases made it a breeze. But in a similar fashion there are projects trying to solve its fundamental issues, like pijul(.org); what are they missing?

[0] https://github.com/yairchu/awesome-structure-editors/blob/ma...

Re: Emacs Is Not Enough

#52
post #14

When reading this article, I think there is an interesting parallel to be made with Firefox. Emacs has questionable technical underpinnings. It is an old project; they've all learned a lot since the 1970s. ELisp wouldn't be built that way today, it wouldn't be written in C, it'd be designed with keybindings for a modern keyboard - probably cloning vim. Break from Emacs tradition and build something that is good at ed…

> it'd be designed with keybindings for a modern keyboard - probably cloning vim.

Or not. This is something some have a hard time understanding, but some of us prefer a non-modal editor and like having simpler key chords instead of key sequences. After all, vi isn't that much younger than Emacs, and the technical underpinnings of its command language are just about as old as the oldest versions of TECO Emacs. My point is that the difference between vi-style keystrokes and Emacs-style is a matter of taste.

Re: Emacs Is Not Enough

#53
post #50

Earlier quoted context omitted.

Seems like the argument is in the "Rune" part even more down below. I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that. The point on ambiguity localization is kind of curious too. I don't think there's an argument to be had for all structures, just that you can do it for each custom structure, and that's the point. Maybe the editors of the old…

> I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that. Emacs modes, in other words? Like how, in Emacs, C-n nearly always does "move to next line" but it could mean "highlight next mail message" and "Enter" nearly always does something with the current line but it could mean "open currently highlighted message" or "newline and indent as per lang…

Modes don't do embedding. Try having a fully-seperate mode for a comment section in your code. Try to do that contextually, too.

Modes don't do that. Neither do they let you control the underlying structure, they give you no ability to treat structures as objects. Yes, they do provide a common interface, but that's where the pros end. Ofc its emacs, and there are projects like Multi-Major-Modes that at least try to subdivide a document into editable areas... speaking of ridiculously slow.

Re: Emacs Is Not Enough

#54
post #11

I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my…

> I can't but reflect back on another post I made today, which is that everything fails at scale.

That reminds me of: Terry Davis' TempleOS Brutal Take Down of Linus Torvalds

https://youtu.be/gBE6glZNJuU?t=388

All computer people today have been jedi-mindtricked, they obsess on if there's one thing they all wanna show you they know is scaling. Everybody is obsessed with scaling. Guess what. Scaling works both ways. You can get bigger. What happens if you look the other direction and you scale down? It doesn't get bad, it gets worse when you scale up. It gets better when you scale down.

I think it's a fundamental problem of flexibility of specialization vs generality. I laid out my thoughts on this on the website in the "On Flexibility" article (There's an article on print statements, too, by the way).

Re: Emacs Is Not Enough

#55
post #52
post #14

When reading this article, I think there is an interesting parallel to be made with Firefox. Emacs has questionable technical underpinnings. It is an old project; they've all learned a lot since the 1970s. ELisp wouldn't be built that way today, it wouldn't be written in C, it'd be designed with keybindings for a modern keyboard - probably cloning vim. Break from Emacs tradition and build something that is good at ed…

> it'd be designed with keybindings for a modern keyboard - probably cloning vim. Or not. This is something some have a hard time understanding, but some of us prefer a non-modal editor and like having simpler key chords instead of key sequences. After all, vi isn't that much younger than Emacs, and the technical underpinnings of its command language are just about as old as the oldest versions of TECO Emacs. My poin…

Bill Joy, maker of Vi, was rather impressed by Emacs's input model in fact:

> I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors go, it pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me.

https://web.archive.org/web/20060701083055/http://web.cecs.p...

I am used to Emacs's parallel universe of keyboard shortcuts now, but I think you could make a good Emacs using standard Windows keybinds.

Re: Emacs Is Not Enough

#56

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the Project's Philosophy/Homogeneity section in [1] The Power of Structure. I am proposing we need to really start considering a different para…

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

Re: Emacs Is Not Enough

#57

Hi! I am the author. I will be glad to answer any questions. First of all, I don't want another Emacs rewrite, much less in Guile. Mixing languages is not good for power-use, which requires ease-of-use, or at least conceptual simplicity. I talk more about it in the article in the Project's Philosophy/Homogeneity section in [1] The Power of Structure. I am proposing we need to really start considering a different para…

What do you think about treesitter? https://github.com/tree-sitter/tree-sitter

The idea is to sync changes in the text to a tree structure, then have all the structure manipulation functions built on top of it. See the gif here for a visual representation: https://github.com/nvim-treesitter/playground

Re: Emacs Is Not Enough

#58

I very much like this article. I especially like the comparison to TempleOS. I think Terry Davis blew computing wide open. That is what a personal computer can do, when it’s treated as an instrument instead of an appliance, and the user treated like the player of said instrument, instead of a child in a china shop. Imagine if you could plug your guitar into a computer, have that audio file, be a widget in a buffer, a…

>Imagine if you could plug your guitar into a computer, have that audio file, be a widget in a buffer, and then, pass it to other functions just like any other object, process it using, idk, map(car), and then sync it to a video using list functions, maybe with different implementations for the data structures under the hood.

Amazing, thank you. This comment, and the replies to it, perfectly summarize what I am looking for in a complete LISP environment. True integration will treat not only text blocks/streams, but multimedia of any kind, seamlessly and as first-class citizens. The old LISP engineers understood that, but as another person said, the limitations of that time put significant barriers to that goal.

We no longer have such limitations; it is time to revisit that model.

Re: Emacs Is Not Enough

#59
post #51

It would be interesting to have such a general project go somewhere. While in principle structural editing sounds like an incredible advance, there are 'good enough' advantages to plain-text tools that make it a much more practical solution. The other issue is of course integration with existing tooling, which you either skip entirely or compromise on the design. What I feel is missing, between the description of "ol…

Really, to me, this project is all about writing a few applications for myself. This may get lost throughout the pages of writing, but really, I am doing this for myself: flexible note-taking, a comfortable REPL, and, _at last_, a Lisp IDE (especially, with comfortable print-statement debugging). Structual editing is just the means to get these specific things right.

Of the link provided (on a skim, so I may be wrong), they seem to be all doing structural editors for specific languages, and that's where their ambitions end. That's their focus: some language. My focus is: applications. Within a power-user environment, which can't be done without a GUI toolkit, which can't be done without image-based programming.

Surely, there are some efforts which I like. Glamourous Toolkit. Not particularly about structural editing, but whatever Smalltalk stuff you take, it just tends to be interesting. Ultimately, they fail to deliver in some way, for me at least. (I comment on GT in the "All Else is Not Enough" appendix article.)

I mean, yeah, look: practical applications. First of all: usable to myself. Then: flexible enough to fit anybody else.

PS The topic article is a rant, I admit. And I rant here and then a bit in the main article, sure. But, please, don't be too quick to classify everything there as a rant, even if it stylistically looks so.

PPS I have to take at pijul again, maybe I missed something, thank you.

Post reply on HN