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 head, such that any help the debugger gives is added to zero. Which... is not good.
That is, complaints that ridiculously large forms cause issues in a debugger seem... pointless? Lets say you managed to keep that from crashing, do you actually have a way to make it workable?
Don't get me wrong, if folks are constantly opening JSON files that are gigabytes in size, it makes sense to focus on that and make sure it doesn't crash. I just, can't imagine what benefit you get from opening an X gigabyte file. I can't even see what the advantages of opening an X megabyte file are. That is literally beyond my brain power.
So, looking to rewrite an emacs is always one that strikes me as a huge risk of throwing the baby out with the water. There is more than a fair chance that what you like about the current setup is a necessary implication of choices that you think you don't like.
Print debugging is a technique that will never go out of style. It works on any system, is used by programmers of any level of experience, is very quick to use and requires no tooling to understand. And sometimes, even if you do have other great tools at your disposal, it’s still the easiest way to track down a problem.
At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility.
Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.
There are ways to debug at scale that aren't step debugging. You can set conditional breakpoints, or breakpoints that run code, or even backwards debugging. You don't have to settle with print debugging, ever. But sometimes it's faster to use it.
I just, can't imagine what benefit you get from opening an X gigabyte file.
Maybe I don't fully understand the context, but... why shouldn't you open a big file?
I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit.
I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds.
If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.
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).
I've been working obsessively on a trivial and currently private emacs package, for a while now, and (having not read the article, yet) would concur with the idea that Emacs is great, there's little else like it, but it's also not enough; the promises that it makes (re: freedom to the user, access to internals via elisp, etc) are not fulfilled. It goes a great ways towards delivering it's promises, and casual users will feel the freedom it gives them (great things can still be done with it! Miles ahead of anything else!), but that just makes the walls all the more frustrating when you hit them. No specifics, but I do find the performance situation and the elisp and rendering implimentations to be at the center of my gripes. I am young enough to hope to see, and perhaps even contribute to, a successor to the Emacs philosophy.
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?
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.
I never cared about structural editors because the argument always seemed to be that being able to ruin the parse (going from a state where it parses to one where it doesn’t) with your editor is bad. Because I don’t care: I want the supreme flexibility of going from state A to B through some ill-formed textual editing much more than I want to be protected from ending up in a bad parse state, since syntax errors are one of the more simple things that a programmer has to deal with.
But I am perfectly willing to embrace structural editing if it makes editors much, much more efficient and less complex (e.g. you don’t need to cache things).
Maybe things become “janky” because many of us are a bit too good at limiting source files to at the most 1K lines, so we tolerate the minor hickups that we encounter?
> I want the supreme flexibility of going from state A to B through some ill-formed textual editing
Seems like the author agrees with you (albeit in a different article):
> … the traditional structural editors do tend to impose some limitations … But these are not the inherent qualities of structural editing. This is just the way someone chose to implement it. So, when I say that Rune provides seamless structural editing, what I mean is that the other kind of choices are possible: the kind where you are editing as if the structure is only apparent, but not in your face, and so, it's just like there are no seams.
Compared to me the author feels like a power user of emacs (or was one) and is making broad arguments against the existence of people like me: not power users.
I've never run into these issues they talk about and I don't really know elisp.
Mostly, over vim, I just like chord editors more than modal editors. If a more modern terminal-based chord editor came out I'd try it.
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 editing text maybe.
Firefox faced a similar challenge from modernity with changing security and performance demands. But they chose to remove XUL killed off their own extension ecosystem and put them in a permanent "Chrome but worse" category that they have been unable to escape from.
In some ways it is impressive that Emacs has managed to avoid being killed off in a massive rewrite attempting to chase other text editors. The temptation much be there, it has a lot of deficiencies. But it is a unique and rewarding piece of software for anyone who wants what it does.
> 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.
> In some ways it is impressive that Emacs has managed to avoid being killed off in a massive rewrite attempting to chase other text editors.
No point chasing when you’re the leader.
It would have to happen in a fork, and a fork attempting it would run into all the problems Richard Stallman identifies when these things are proposed (and rejected). It’s not like they’re unaware that some decades old critical components need to be redone. But this is emacs, not a FAANG throwaway, so that kind of work has constraints and expectations and standards to meet. Chunking garbage at it because emotions isn’t an option there.
And my reaction was, is it really so yanky? Maybe it's not yanky enough for me to notice. Except for the handling of long lines, that's really slow. I wish it is just yanky.
However I don't understand one thing. Did the author switch to something else or he's still using emacs after this long and convoluted rant?
> And then there are the floaters, the passers-by. They judge Emacs solely by its features.
> But that's not how a power users judges it. Instead, the power user judges a piece of software by what power it provides and what he could do with that power to help himself.
In that case I'm not a power user. I tried using emacs for a good amount of time, probably about a year of wall time has been spent with me using emacs as my primary editor. I installed a few packages, and never tried to script anything myself. My issues with emacs were not easily scriptable.
Although all-in-all, I didn't find emacs particularly lacking in features compared to vim, which is my preferred editor.
In the end I stuck with vim because it's slightly less clunky in my very subjective experience, and I am faster with it. And it is visibly slow, even if you set up an emacs server ("what is a text editor 'server'?" I can hear vim and nano users muttering).
Rather than just s**ing on emacs I want to present the things that I did like about it, compared to vim:
- The ability to quickly cycle through recently yanked/cut things. It's possible to do this on vim, but nowhere near as easily as M-y.
- Keyboard commands are universal and not modal, so I don't need to learn two totally different sets of commands for simple movement and editing.
- Keyboard commands are also available in many prompt-based tools like bash, gdb, and many REPLs. Don't tell me about vi-mode in bash unless you actually use it and like it.
I've found the emacs rant itself amusing, since it is a very old piece (slightly younger than me) and gargantuan piece of software, and it shows. On the other side, it is still the most extensible and moddable editor out there and its crown juwels (org, magit) are unmatched.
As for the project itself, I remain sceptical. Partly because I do not see how it would be more amazing for general text-editing tasks than emacs/vim + tree-sitter, partly because it is written by an adept of a language which is since decades more known for rants about programming than for delivering amazing software for end-users.
If you like mediocrity, sure. That's what so many have OK'd, and that's fine, not everybody has to care about tools.
And you are right for being sceptical: it's only natural, I would be too if I saw what I wrote without knowing what it was. As an Emacs user, I could be dismissive of new efforts, because, you know, emacs is enough and all.
And I have said this a few times in the comments, but I am far from tired: the point of structural editing is not just editing.
If you have time, take a look at Alchemy and what I want to do in it:
Yeah, but is it even good? I am using it myself, have been for many years. It doesn't bring me joy to say this: but it's not enough either. Far from it. Miles, and galaxies away from it. It could be so much better (the experience of note-taking and computational notebooks).
> an adept of a language which is since decades more known for rants about programming than for delivering amazing software for end-users
Look, all the rest of the languages didn't deliver it for me either (and for the computing industry at large, even though many people would prefer not to think about it).
Computer industry is very young. Very young. I get the skepticism, but just think of it!
Emacs kind of did deliver, to a point, for some time -- and that's written in lisp. One of the longest-living pieces of software.
Or are you saying that Common Lisp itself is a problem? I mean, it's was simply the most practical choice on my part. I don't consider myself an adept, I don't consider CL perfect, but it's suitable for what I want to do.
I merely skimmed this article because I personally don't care or much about the details, but also because I completely and fully understand his pain.
I've done quite a bit of the "searching for the perfect system," including doing Emacs + Org Mode for a few years.
I ditched it because I do like a lot of modern tools, and today I use a ton of little scripts and hacks, mostly around zim-wiki, but what I think the author is getting at is more-or-less the "hypercard" thing.
Namely, it could and should be far easier to cobble together systems of programs as individuals that work together and that don't strongly separate "user" and "developer."
Glamorous Toolkit[1] promotes the idea of moldable development[2].
There's a talk on it: Tudor Gîrba - Moldable development.[3]
The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook.
The site on moldable development states its difference with literate programming:
They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).
And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment.
The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool.
But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated.
It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself.
I can't say I can compare it to Project Mage in any meaningful way, except it's also a live environment.
This whole thread was a great read and since I have many times benefitted from finding gems like this on HN through a search engine well after the fact, hence leaving the link above.
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, 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. Or if you could make a game, modify it while you’re playing it, share that game as an image with a friend, and have them open it up, interact with it the same way they do with every other data structure from email to org mode.
Every time I see something like this, I'm also reminded of this demo of the Xerox Alto from a few years back. I'll link to the start of the most relevant piece: https://youtu.be/AnrlSqtpOkw?t=549
I'm always struck by the useful directions that desktop computers were going in the 70s, and how computing could be so much better than it is right now. But we've veered so off-course from all of this, away from composability and towards independent boxes ("applications") that can't talk to each other at all.
Emacs is in some ways the best thing we have today in the other direction, but it pales in comparison to what's possible.
>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.
I find the fascination with TempleOS honestly weird, and I think people are honestly only fascinated by it because of the author. We have had smalltalk for the longest time. We have had so many attempts at "embed rich content into shell", we have had all of this!
Hell, all of what you describe is basically available in the form of Mathmatica.
And "share a program with a friend" is called a webpage with Javascript. We have the universal VM, just not in the shape that you would like.
I don't want to be too dismissive of this stuff but I think at one point we gotta try using all these new fancy ideas that would be good for everyone, instead of constantly just imagining "what if they existed". Let's actualize a bit!
XEmacs was a great replacement back when UNIX environments were found lacking in IDE offerings.
I still have muscle memory for the stuff I used between 1995 and 2005, across various UNIX commercial workloads.
Nowadays thankfully all the environments I care about have quite good IDE support in some form, while Emacs experience at its core has hardly core, although it is much better than in the XEmacs vs Emacs days.
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 paradigm, and attempting to do it right, and that's structural editing. People are wondering if it's possible to be writing better structural editors. We all know there have been attempts to do those, and, well, lo and behold, those were janky too.
But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++".
Well, in fact, I could tell you how we could do exactly that: you could start small. You start with what you know. And you know that you could, say, start with structuralizing the {} brackets. That's a semantic unit. So, that's a start. Even without getting down to the compiler level.
But I am not arguing I am about to do wonders for something as complex as some mainstream langauge in terms of a structural editing. I believe it can certainly be attempted, though, and certainly improved, peacemeal. And what you can't do: mix it with the traditional string-based editing. Or take python: that one would structuralize pretty nicely by indentation. Would it accomplish everything? No. But it would certainly help.
The gist of it boils down to the fact that you don't need to start at that very complex level, you can do things piecemeal and still get many benefits. Ask yourself this: can you edit a /list/ structurally, i.e. edit like in a string-based editor while maintaning an actual list behind the scenes? Sure, you can. A tree? Absolutely. Look at Paredit.
THERE'S NO REASON FOR THAT TO BE JANKY. NO reason why that wouldn't work.
It can absolutely be done.
And, really, structural editing like I am proposing /subsumes/ string-based editing, because you can just write a specialized editor for general strings, and use that for things you don't know how to structure yet. And yet, even those string-based editors can be specialized further, as some semantic units like words, expressions and even characters are often immediately apparent.
What does that give us? At the very least: object identity and programmatic access, and having the ability to pick your own data structure.
This kind of small things are what's actually going to be very useful for stuff like note-takers and computational notebooks and REPLs and what not. We don't need to start with programming languages (though I am going to do a Common Lisp IDE).
Please, ask me anything! Let's talk!
PS Another very important point is that ambiguity can be localized. Look at the Alchemy section in [1] where I discuss dealing with the reader (but I also talk about it in Rune).
PPS And thank you for posting this. It's exciting to be reading comments. Truly.
> 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.
> 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.
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
Do you think managing CL packages in a way similar to 1968's Grail (https://www.youtube.com/watch?v=2Cq8S3jzJiQ) could work? I'm thinking of a visual overview of packages were a user can connect packages together (maybe by drawing lines or by holding a key down and clicking on packages to link them), and can afterwards click on the vertices connecting the nodes to configure which symbols get imported.
It might be a bit UML-ish, but that's probably because I spent a bit too much time playing around with Umbrello.
Basically, when you say 'structural editing', do you mean making a a parse tree for every kind of input and having a modal command language that permits traversal and editing of that parse tree. Like what sapling https://github.com/kneasle/sapling is attempting to do ?
> 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.
This is a huge problem with GNU. Lisp is an extremely elitist language, and extremely divisive. It's not taught that well in GNU documentation either, in my opinion.
The least elitist language today is probably JavaScript. We already had Atom, and then things like VS Code, that make heavy use of JavaScript.
But does using JavaScript as the scripting language imply that the editor must be Electron-based? Surely you can have a thinner JavaScript-based app for desktop? And who cares whether it runs in a browser.
[+] [-] taeric|3 years ago|reply
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 head, such that any help the debugger gives is added to zero. Which... is not good.
That is, complaints that ridiculously large forms cause issues in a debugger seem... pointless? Lets say you managed to keep that from crashing, do you actually have a way to make it workable?
Don't get me wrong, if folks are constantly opening JSON files that are gigabytes in size, it makes sense to focus on that and make sure it doesn't crash. I just, can't imagine what benefit you get from opening an X gigabyte file. I can't even see what the advantages of opening an X megabyte file are. That is literally beyond my brain power.
So, looking to rewrite an emacs is always one that strikes me as a huge risk of throwing the baby out with the water. There is more than a fair chance that what you like about the current setup is a necessary implication of choices that you think you don't like.
[+] [-] jb1991|3 years ago|reply
[+] [-] kqr|3 years ago|reply
At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility.
Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.
[+] [-] sudosysgen|3 years ago|reply
[+] [-] maydup-nem|3 years ago|reply
Curiously:
https://project-mage.org/overcoming-the-print-statement
[+] [-] narag|3 years ago|reply
Maybe I don't fully understand the context, but... why shouldn't you open a big file?
I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit.
I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds.
If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.
[+] [-] some-mthfka|3 years ago|reply
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).
[+] [-] pjmlp|3 years ago|reply
[+] [-] LanternLight83|3 years ago|reply
[+] [-] woolion|3 years ago|reply
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...
[+] [-] some-mthfka|3 years ago|reply
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.
[+] [-] avgcorrection|3 years ago|reply
But I am perfectly willing to embrace structural editing if it makes editors much, much more efficient and less complex (e.g. you don’t need to cache things).
Maybe things become “janky” because many of us are a bit too good at limiting source files to at the most 1K lines, so we tolerate the minor hickups that we encounter?
[+] [-] bradrn|3 years ago|reply
Seems like the author agrees with you (albeit in a different article):
> … the traditional structural editors do tend to impose some limitations … But these are not the inherent qualities of structural editing. This is just the way someone chose to implement it. So, when I say that Rune provides seamless structural editing, what I mean is that the other kind of choices are possible: the kind where you are editing as if the structure is only apparent, but not in your face, and so, it's just like there are no seams.
— https://project-mage.org/the-power-of-structure#orgeb59167
[+] [-] eatonphil|3 years ago|reply
Compared to me the author feels like a power user of emacs (or was one) and is making broad arguments against the existence of people like me: not power users.
I've never run into these issues they talk about and I don't really know elisp.
Mostly, over vim, I just like chord editors more than modal editors. If a more modern terminal-based chord editor came out I'd try it.
[+] [-] criddell|3 years ago|reply
[+] [-] roenxi|3 years ago|reply
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 editing text maybe.
Firefox faced a similar challenge from modernity with changing security and performance demands. But they chose to remove XUL killed off their own extension ecosystem and put them in a permanent "Chrome but worse" category that they have been unable to escape from.
In some ways it is impressive that Emacs has managed to avoid being killed off in a massive rewrite attempting to chase other text editors. The temptation much be there, it has a lot of deficiencies. But it is a unique and rewarding piece of software for anyone who wants what it does.
[+] [-] msla|3 years ago|reply
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.
[+] [-] ergonaught|3 years ago|reply
No point chasing when you’re the leader.
It would have to happen in a fork, and a fork attempting it would run into all the problems Richard Stallman identifies when these things are proposed (and rejected). It’s not like they’re unaware that some decades old critical components need to be redone. But this is emacs, not a FAANG throwaway, so that kind of work has constraints and expectations and standards to meet. Chunking garbage at it because emotions isn’t an option there.
[+] [-] ggm|3 years ago|reply
[+] [-] pmontra|3 years ago|reply
However I don't understand one thing. Did the author switch to something else or he's still using emacs after this long and convoluted rant?
[+] [-] guestbest|3 years ago|reply
[+] [-] veltas|3 years ago|reply
In that case I'm not a power user. I tried using emacs for a good amount of time, probably about a year of wall time has been spent with me using emacs as my primary editor. I installed a few packages, and never tried to script anything myself. My issues with emacs were not easily scriptable.
Although all-in-all, I didn't find emacs particularly lacking in features compared to vim, which is my preferred editor.
In the end I stuck with vim because it's slightly less clunky in my very subjective experience, and I am faster with it. And it is visibly slow, even if you set up an emacs server ("what is a text editor 'server'?" I can hear vim and nano users muttering).
Rather than just s**ing on emacs I want to present the things that I did like about it, compared to vim:
- The ability to quickly cycle through recently yanked/cut things. It's possible to do this on vim, but nowhere near as easily as M-y. - Keyboard commands are universal and not modal, so I don't need to learn two totally different sets of commands for simple movement and editing. - Keyboard commands are also available in many prompt-based tools like bash, gdb, and many REPLs. Don't tell me about vi-mode in bash unless you actually use it and like it.
[+] [-] lycopodiopsida|3 years ago|reply
As for the project itself, I remain sceptical. Partly because I do not see how it would be more amazing for general text-editing tasks than emacs/vim + tree-sitter, partly because it is written by an adept of a language which is since decades more known for rants about programming than for delivering amazing software for end-users.
[+] [-] some-mthfka|3 years ago|reply
If you like mediocrity, sure. That's what so many have OK'd, and that's fine, not everybody has to care about tools.
And you are right for being sceptical: it's only natural, I would be too if I saw what I wrote without knowing what it was. As an Emacs user, I could be dismissive of new efforts, because, you know, emacs is enough and all.
And I have said this a few times in the comments, but I am far from tired: the point of structural editing is not just editing.
If you have time, take a look at Alchemy and what I want to do in it:
https://project-mage.org/the-power-of-structure#AlchemyCL
Slime for lisp didn't do it for me.
My thoughts on tree-sitter:
https://news.ycombinator.com/item?id=34375137#34379449
> org is unmatched
Yeah, but is it even good? I am using it myself, have been for many years. It doesn't bring me joy to say this: but it's not enough either. Far from it. Miles, and galaxies away from it. It could be so much better (the experience of note-taking and computational notebooks).
> an adept of a language which is since decades more known for rants about programming than for delivering amazing software for end-users
Look, all the rest of the languages didn't deliver it for me either (and for the computing industry at large, even though many people would prefer not to think about it).
Computer industry is very young. Very young. I get the skepticism, but just think of it!
Emacs kind of did deliver, to a point, for some time -- and that's written in lisp. One of the longest-living pieces of software.
Or are you saying that Common Lisp itself is a problem? I mean, it's was simply the most practical choice on my part. I don't consider myself an adept, I don't consider CL perfect, but it's suitable for what I want to do.
[+] [-] jrm4|3 years ago|reply
I've done quite a bit of the "searching for the perfect system," including doing Emacs + Org Mode for a few years.
I ditched it because I do like a lot of modern tools, and today I use a ton of little scripts and hacks, mostly around zim-wiki, but what I think the author is getting at is more-or-less the "hypercard" thing.
Namely, it could and should be far easier to cobble together systems of programs as individuals that work together and that don't strongly separate "user" and "developer."
(aka screw GNOME? :) )
[+] [-] mmargerum|3 years ago|reply
https://gtoolkit.com/
[+] [-] some-mthfka|3 years ago|reply
Glamorous Toolkit[1] promotes the idea of moldable development[2].
There's a talk on it: Tudor Gîrba - Moldable development.[3]
The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook.
The site on moldable development states its difference with literate programming:
They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).
And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment.
The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool.
But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated.
It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself.
I can't say I can compare it to Project Mage in any meaningful way, except it's also a live environment.
[1] https://gtoolkit.com/ [2] https://moldabledevelopment.com/ [3] https://www.youtube.com/watch?v=Pot9GnHFOVU
[+] [-] herewulf|3 years ago|reply
This whole thread was a great read and since I have many times benefitted from finding gems like this on HN through a search engine well after the fact, hence leaving the link above.
[+] [-] Gollapalli|3 years ago|reply
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. Or if you could make a game, modify it while you’re playing it, share that game as an image with a friend, and have them open it up, interact with it the same way they do with every other data structure from email to org mode.
[+] [-] ryukafalz|3 years ago|reply
I'm always struck by the useful directions that desktop computers were going in the 70s, and how computing could be so much better than it is right now. But we've veered so off-course from all of this, away from composability and towards independent boxes ("applications") that can't talk to each other at all.
Emacs is in some ways the best thing we have today in the other direction, but it pales in comparison to what's possible.
[+] [-] ykonstant|3 years ago|reply
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.
[+] [-] rtpg|3 years ago|reply
Hell, all of what you describe is basically available in the form of Mathmatica.
And "share a program with a friend" is called a webpage with Javascript. We have the universal VM, just not in the shape that you would like.
I don't want to be too dismissive of this stuff but I think at one point we gotta try using all these new fancy ideas that would be good for everyone, instead of constantly just imagining "what if they existed". Let's actualize a bit!
[+] [-] pjmlp|3 years ago|reply
I still have muscle memory for the stuff I used between 1995 and 2005, across various UNIX commercial workloads.
Nowadays thankfully all the environments I care about have quite good IDE support in some form, while Emacs experience at its core has hardly core, although it is much better than in the XEmacs vs Emacs days.
[+] [-] some-mthfka|3 years ago|reply
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 paradigm, and attempting to do it right, and that's structural editing. People are wondering if it's possible to be writing better structural editors. We all know there have been attempts to do those, and, well, lo and behold, those were janky too.
But they don't have to be. When people start thinking of structure-editing, they immediately jump to the "how do we do C++". Well, in fact, I could tell you how we could do exactly that: you could start small. You start with what you know. And you know that you could, say, start with structuralizing the {} brackets. That's a semantic unit. So, that's a start. Even without getting down to the compiler level.
But I am not arguing I am about to do wonders for something as complex as some mainstream langauge in terms of a structural editing. I believe it can certainly be attempted, though, and certainly improved, peacemeal. And what you can't do: mix it with the traditional string-based editing. Or take python: that one would structuralize pretty nicely by indentation. Would it accomplish everything? No. But it would certainly help.
The gist of it boils down to the fact that you don't need to start at that very complex level, you can do things piecemeal and still get many benefits. Ask yourself this: can you edit a /list/ structurally, i.e. edit like in a string-based editor while maintaning an actual list behind the scenes? Sure, you can. A tree? Absolutely. Look at Paredit.
THERE'S NO REASON FOR THAT TO BE JANKY. NO reason why that wouldn't work.
It can absolutely be done.
And, really, structural editing like I am proposing /subsumes/ string-based editing, because you can just write a specialized editor for general strings, and use that for things you don't know how to structure yet. And yet, even those string-based editors can be specialized further, as some semantic units like words, expressions and even characters are often immediately apparent.
What does that give us? At the very least: object identity and programmatic access, and having the ability to pick your own data structure.
This kind of small things are what's actually going to be very useful for stuff like note-takers and computational notebooks and REPLs and what not. We don't need to start with programming languages (though I am going to do a Common Lisp IDE).
Please, ask me anything! Let's talk!
PS Another very important point is that ambiguity can be localized. Look at the Alchemy section in [1] where I discuss dealing with the reader (but I also talk about it in Rune).
PPS And thank you for posting this. It's exciting to be reading comments. Truly.
[1] https://project-mage.org/the-power-of-structure
[+] [-] db48x|3 years ago|reply
> 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.
[+] [-] PurpleRamen|3 years ago|reply
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.
[+] [-] SuperCuber|3 years ago|reply
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
[+] [-] tmtvl|3 years ago|reply
It might be a bit UML-ish, but that's probably because I spent a bit too much time playing around with Umbrello.
[+] [-] pjmlp|3 years ago|reply
https://www.reddit.com/r/programming/comments/25r6pw/a_demo_...
[+] [-] lenkite|3 years ago|reply
[+] [-] graboid|3 years ago|reply
[+] [-] veltas|3 years ago|reply
This is a huge problem with GNU. Lisp is an extremely elitist language, and extremely divisive. It's not taught that well in GNU documentation either, in my opinion.
The least elitist language today is probably JavaScript. We already had Atom, and then things like VS Code, that make heavy use of JavaScript.
But does using JavaScript as the scripting language imply that the editor must be Electron-based? Surely you can have a thinner JavaScript-based app for desktop? And who cares whether it runs in a browser.
[+] [-] _a_a_a_|3 years ago|reply
[+] [-] puffybuf|3 years ago|reply
[+] [-] some-mthfka|3 years ago|reply
[+] [-] hajovonta|3 years ago|reply
/s
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] steponlego|3 years ago|reply
[+] [-] jb1991|3 years ago|reply