15 ms·

Emacs Is Not Enough

151 points by lycopodiopsida 4y ago

Gollapalli 4y ago
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.
- ryukafalz 4y ago
  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 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.
  - vfclists 4y ago
    What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. > 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. This is the consequence of deliberate corporate agendas, but many people are still in denial of that. The worse thing that happened to this kind of computing was the policy of forcing everything through the web interface, which was deliberately crippled to let the industry majors to get a heads up in browser based software.
    - msla 4y ago
      > What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. No, more like Interlisp, which is kinda like Smalltalk in terms of being an active environment, only without having to deal with... you know... Smalltalk in order to use it. Plus, there's something to be said for a plan that's probably now mostly forgotten, to re-write Emacs to use Guile as its language and compile other languages to Guile so programmers could extend it in any of multiple languages and they'd all interoperate. The target language doesn't have to be Guile, of course; the modern conception would likely involve WASM and/or LLVM bitcode. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
      - snamellit 4y ago
        Interestingly TJ Devries just did something like that for neovim. He made a transpiler from vim9script to Lua to allow compatibility. I found that around neovim there is a similar crafting vibe you find around Emacs.
        vfclists 4y ago
        And they've got Fennel and some Fennel based frameworks to enable them to configure the Vim settings in a Lisp.
  - abudabi123 4y ago
    > 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 joining Blender, sensors, actuators, voice assist, Ai, lisp, Emacs. If a project could attract the backers Blender is getting to explore and document design possibilites for Emacs that's a move in a better direction.
    - ykonstant 4y ago
      Yes, yes, yes and yes. I am glad to see this sentiment expressed here!
  - agumonkey 4y ago
    I wonder if the sidefx houdini guys knew about smalltalk and if kay and his team ever saw houdini. The universal connecting data is very similar (and one of the most pleasurable thing ever)
  - jll29 4y ago
    Very true. From one vantage point, things look like this: 1970s: The Visionaries - showing us how the future (of desktop computing) can look like. 2023: pre-1970s state stuff has become pervasive, runs faster and is cheaper, but not nearly at the level of sophistication that the 1970s had. (State of the art is still free clones of Unix, a 1960s OS.) So where is the course correction? And where are the 2023 ideas that as look far into the future from today as the J.C.R. Lickliders, D. Engelbarts, T. Nelson and A. Kays of the day? (Thankfully, in some areas, things look better - e.g. mobile phones, robotics, machine learning applications etc., so the point here is only valid about destop HCI progress.)
- rtpg 4y ago
  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!
- ykonstant 4y ago
  >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.
steponlego 4y ago
They're going to try to ruin emacs like they are with x.org. It's inevitable. Too many people want it gone. It's too good.
- jb1991 4y ago
  Who is “they“?
  - xxswagmasterxx 4y ago
    Big Wayland
    - jb1991 4y ago
      What does that mean?
      - justoreply 4y ago
        it is a joke, like Big Pharma
        Woodi 4y ago
        It's amazing how everybody knows but nothing is done and apparently wrong peoples keeps being elected... It's literaly electric shocking-like.
hajovonta 4y ago
so... instead of contributing, why not rewrite the whole thing? ok that would certainly help /s
ggm 4y ago
The entire article comes down to this quote: WHY IS EVERYTHING SO JANKY AF?
- guestbest 4y ago
  That’s the good part. The bad part is the lengthy complaining about needing something better than emacs before concluding that emacs is the best.
  - ggm 4y ago
    I had to laugh when I read the complaint about evil mode interactions. Running an emulator for another UI paradigm, unhappy about how it works.
- pmontra 4y ago
  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?
  - d0mine 4y ago
    There is so-long.el which is part of Emacs since 27.1 http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long.el http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long...
  - mickeyp 4y ago
    Long lines are 'fixed' in Emacs 29.1. They've redone bits of the engine that made it slow.
  - some-mthfka 4y ago
    > Did the author switch to something else or he's still using emacs after this long and convoluted rant? Building my own solution which the website is dedicated to.
LanternLight83 4y ago
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.
personomas 4y ago
TLDR?
- throwawayoaky 4y ago
  Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigating that. Also he has a 5 year plan to prove this all. Still deciding if I buy it. only wants 1000 bucks a month to work on it full time, I think exploring the area is worth that at least.
  - Syntonicles 4y ago
    I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost. I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.
    - maydup-nem 4y ago
      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 tried to bite off too much when they attempted embedded structures, and they didn't have the right abstractions in place. If you look at https://tylr.fun https://tylr.fun it shows that things that weren't being done back then, there are interesting approaches now.
      - msla 4y ago
taeric 4y ago
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.
- jb1991 4y ago
  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.
  - taeric 4y ago
    I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it. Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
  - worik 4y ago
    Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.
roenxi 4y ago
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.
- msla 4y ago
  > 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.
  - shadowofneptune 4y ago
    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.pdx.edu/~kirkenda/joy84.html 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.
  - npsimons 4y ago
pjmlp 4y ago
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.
avgcorrection 4y ago
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?
- bradrn 4y ago
  > 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. — https://project-mage.org/the-power-of-structure#orgeb59167 https://project-mage.org/the-power-of-structure#orgeb59167
  - avgcorrection 4y ago
    Yup. Apparently.[1] Seems that we agree that your typical structural editor is either too gimped or to inflexible to be useful. But I believe him when he writes that it is possible to make a unified language for editing all kinds of structures. I certainly wouldn’t wanna learn a new editing mode for every little yaml/json/java/rust/yaml-superset/yaml-superset-superset. [1] But I don’t have time right now to read that main article to find out, since Firefox claims that it is a 2 hour+ read. :p
kkfx 4y ago
Others and I without digging that much have expressed something similar, i.e. https://www.reddit.com/r/emacs/comments/so7os8/notdeft_notes_manager_with_xapianefficient/hw7opus/ https://www.reddit.com/r/emacs/comments/so7os8/notdeft_notes... https://www.reddit.com/r/emacs/comments/speq69/uomf_pathindependent_links_to_local_files_via/ https://www.reddit.com/r/emacs/comments/speq69/uomf_pathinde... https://www.reddit.com/r/emacs/comments/zl8nfa/is_there_something_like_org_roam_but_for_files/ https://www.reddit.com/r/emacs/comments/zl8nfa/is_there_some... https://takeonrules.com/2022/02/26/note-taking-with-org-roam-and-transclusion/ https://takeonrules.com/2022/02/26/note-taking-with-org-roam... The long story short is that we need something to process text automatically in easy to compose and easy to query ways. Emacs peoples mostly hate databases, and SOME DB models are strict, hard to keep bending, graph DB have not succeed so much so far, so it might be ad unsolved problem, a VERY OLD one, let's say: - ~612 BC Ashurbanipal of Nineveh cataloguing system - ~245 BC Callimacus Pinakes cataloguing system - ~1545 libraries of Babel by Conrad Gessner - 1673-94 Gottfried Wilhelm Leibniz, Scrinium Literatum - ... to the Mundaneum (Paul Otlet/Henry La Fontaine) - ... to the web first concept, the search engine concept ... Natural language is not much computable directly, some modern ML tools try to work on it, some classic algorithms try to do the same, most results are not much good at small scale, they are just good at very large scale for very limited results. But the point of Emacs is another, is the LispM concept, witch was also the Xerox PARC Smalltalk workstations concept: as we need ways to act on text with automation so we need OSes as a single application, where the source is live, changeable, where anything is a function the user can use anywhere so that if I have a CAS on my desktop I can solve and ODE with it inside an email and link the email in a paper. Old systems was limited by the tech of their time, Emacs by the size of its community and the burden of legacy it have, but they show a starting point that's effective. The rest is still to be invented, implemented and done. NO OTHER TOOLS so far have proven to be better in general so...
some-mthfka 4y ago
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. [1] https://project-mage.org/the-power-of-structure https://project-mage.org/the-power-of-structure
puffybuf 4y ago
After 25 years my dot emacs is _only_ 1000 lines.
- some-mthfka 4y ago
  I did a lot of custom bindings. Those can really bloat up the config. + Lots of packages with their configs.
woolion 4y ago
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/main/README.md https://github.com/yairchu/awesome-structure-editors/blob/ma...
- some-mthfka 4y ago
  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.
cutler 4y ago
TLDR - Emacs sucks.
distantsounds 4y ago
this article is hilarious because the vim csv plugin 'just works.'
- db48x 4y ago
  So does the Emacs one.
- allarm 4y ago
  Turned out the author didn’t know that csv-mode exists.
  - some-mthfka 4y ago
    Yep. I will have to add it to the article (and why it's insufficient as well).
    - allarm 4y ago
      Just make sure that you’ve checked the documentation beforehand, so that you don’t miss anything obvious again.
eatonphil 4y ago
I'm not an emacs power user. I use emacs solely. 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 4y ago
  I think his point is that you cannot use Emacs solely. You probably need a browser and a spreadsheet and lots of other software.
  - tmtvl 4y ago
    But Emacs has browsers and spreadsheet programs and a lot of other software. Out of the box it even comes with a great editor.
  - scruple 4y ago
    Can nano or pico do it? Can vim do it out of the box? For that matter, how does VSCode stand up to "very large" CSV files? I really don't know but I suspect this is less of an Emacs "problem" than it is a matter of fact for most editors that aren't specialized to the specific task of "very large" CSV files.
lycopodiopsida 4y ago
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.
- some-mthfka 4y ago
  > text-editing tasks than emacs/vim + tree-sitter 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 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 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.
mmargerum 4y ago
All I can say is "Glamorous toolkit" https://gtoolkit.com/ https://gtoolkit.com/
- some-mthfka 4y ago
  Wrote a review on it on the website, copypasting: 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/ https://gtoolkit.com/ [2] https://moldabledevelopment.com/ https://moldabledevelopment.com/ [3] https://www.youtube.com/watch?v=Pot9GnHFOVU https://www.youtube.com/watch?v=Pot9GnHFOVU
pvaldes 4y ago
But it is such a perfect place to start, my love
deleted 4y ago
[deleted]
veltas 4y ago
> 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.
_a_a_a_ 4y ago
What a strange, whiney article.
jrm4 4y ago
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." (aka screw GNOME? :) )
draw_down 4y ago
[dead]
Woodi 4y ago
Agree at all but bashing "representations" and APIs seems strange and asking for troubles.
herewulf 4y ago
More recent follow up discussion: https://news.ycombinator.com/item?id=34380373 https://news.ycombinator.com/item?id=34380373 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.

ryukafalz 4y ago
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 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.
- vfclists 4y ago
  What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. > 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. This is the consequence of deliberate corporate agendas, but many people are still in denial of that. The worse thing that happened to this kind of computing was the policy of forcing everything through the web interface, which was deliberately crippled to let the industry majors to get a heads up in browser based software.
  - msla 4y ago
    > What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. No, more like Interlisp, which is kinda like Smalltalk in terms of being an active environment, only without having to deal with... you know... Smalltalk in order to use it. Plus, there's something to be said for a plan that's probably now mostly forgotten, to re-write Emacs to use Guile as its language and compile other languages to Guile so programmers could extend it in any of multiple languages and they'd all interoperate. The target language doesn't have to be Guile, of course; the modern conception would likely involve WASM and/or LLVM bitcode. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
    - snamellit 4y ago
      Interestingly TJ Devries just did something like that for neovim. He made a transpiler from vim9script to Lua to allow compatibility. I found that around neovim there is a similar crafting vibe you find around Emacs.
      - vfclists 4y ago
        And they've got Fennel and some Fennel based frameworks to enable them to configure the Vim settings in a Lisp.
- abudabi123 4y ago
  > 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 joining Blender, sensors, actuators, voice assist, Ai, lisp, Emacs. If a project could attract the backers Blender is getting to explore and document design possibilites for Emacs that's a move in a better direction.
  - ykonstant 4y ago
    Yes, yes, yes and yes. I am glad to see this sentiment expressed here!
- agumonkey 4y ago
  I wonder if the sidefx houdini guys knew about smalltalk and if kay and his team ever saw houdini. The universal connecting data is very similar (and one of the most pleasurable thing ever)
- jll29 4y ago
  Very true. From one vantage point, things look like this: 1970s: The Visionaries - showing us how the future (of desktop computing) can look like. 2023: pre-1970s state stuff has become pervasive, runs faster and is cheaper, but not nearly at the level of sophistication that the 1970s had. (State of the art is still free clones of Unix, a 1960s OS.) So where is the course correction? And where are the 2023 ideas that as look far into the future from today as the J.C.R. Lickliders, D. Engelbarts, T. Nelson and A. Kays of the day? (Thankfully, in some areas, things look better - e.g. mobile phones, robotics, machine learning applications etc., so the point here is only valid about destop HCI progress.)
rtpg 4y ago
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!
ykonstant 4y ago
>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.

steponlego 4y ago

They're going to try to ruin emacs like they are with x.org. It's inevitable. Too many people want it gone. It's too good.

jb1991 4y ago
Who is “they“?
- xxswagmasterxx 4y ago
  Big Wayland
  - jb1991 4y ago
    What does that mean?
    - justoreply 4y ago
      it is a joke, like Big Pharma
      - Woodi 4y ago
        It's amazing how everybody knows but nothing is done and apparently wrong peoples keeps being elected... It's literaly electric shocking-like.

hajovonta 4y ago

so... instead of contributing, why not rewrite the whole thing? ok that would certainly help /s

ggm 4y ago

The entire article comes down to this quote: WHY IS EVERYTHING SO JANKY AF?

guestbest 4y ago
That’s the good part. The bad part is the lengthy complaining about needing something better than emacs before concluding that emacs is the best.
- ggm 4y ago
  I had to laugh when I read the complaint about evil mode interactions. Running an emulator for another UI paradigm, unhappy about how it works.
pmontra 4y ago
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?
- d0mine 4y ago
  There is so-long.el which is part of Emacs since 27.1 http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long.el http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long...
- mickeyp 4y ago
  Long lines are 'fixed' in Emacs 29.1. They've redone bits of the engine that made it slow.
- some-mthfka 4y ago
  > Did the author switch to something else or he's still using emacs after this long and convoluted rant? Building my own solution which the website is dedicated to.

LanternLight83 4y ago

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.

personomas 4y ago

TLDR?

throwawayoaky 4y ago
Treating a document like a 2d text buffer is the root of all evil. Treating a document like a string is even worse. Emacs does both, so does everybody else. The big idea is mapping the doc to a tree of nested structures whose schemas define constraints, which constraints define the editing and viewing semantics of the parts of the tree you're looking at. Also lisp should have won the 70s and we're not done relitigating that. Also he has a 5 year plan to prove this all. Still deciding if I buy it. only wants 1000 bucks a month to work on it full time, I think exploring the area is worth that at least.
- Syntonicles 4y ago
  I understand the argument for it, but I can't make heads or tails of the implementation article discussing constraints. How do constraints help us at all? For context, I wrote a graph-based CSP-solver and I'm still completely lost. I hit page-down 40 times and wasn't even halfway through. I feel like billing $1000 to skim the proposal.
  - maydup-nem 4y ago
    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 tried to bite off too much when they attempted embedded structures, and they didn't have the right abstractions in place. If you look at https://tylr.fun https://tylr.fun it shows that things that weren't being done back then, there are interesting approaches now.
    - msla 4y ago

taeric 4y ago

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.

jb1991 4y ago
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.
- taeric 4y ago
  I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it. Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
- worik 4y ago
  Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.

roenxi 4y ago

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.

msla 4y ago
> 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.
- shadowofneptune 4y ago
  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.pdx.edu/~kirkenda/joy84.html 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.
- npsimons 4y ago

pjmlp 4y ago

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.

avgcorrection 4y ago

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?

bradrn 4y ago
> 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. — https://project-mage.org/the-power-of-structure#orgeb59167 https://project-mage.org/the-power-of-structure#orgeb59167
- avgcorrection 4y ago
  Yup. Apparently.[1] Seems that we agree that your typical structural editor is either too gimped or to inflexible to be useful. But I believe him when he writes that it is possible to make a unified language for editing all kinds of structures. I certainly wouldn’t wanna learn a new editing mode for every little yaml/json/java/rust/yaml-superset/yaml-superset-superset. [1] But I don’t have time right now to read that main article to find out, since Firefox claims that it is a 2 hour+ read. :p

kkfx 4y ago

Others and I without digging that much have expressed something similar, i.e. https://www.reddit.com/r/emacs/comments/so7os8/notdeft_notes_manager_with_xapianefficient/hw7opus/ https://www.reddit.com/r/emacs/comments/so7os8/notdeft_notes... https://www.reddit.com/r/emacs/comments/speq69/uomf_pathindependent_links_to_local_files_via/ https://www.reddit.com/r/emacs/comments/speq69/uomf_pathinde... https://www.reddit.com/r/emacs/comments/zl8nfa/is_there_something_like_org_roam_but_for_files/ https://www.reddit.com/r/emacs/comments/zl8nfa/is_there_some... https://takeonrules.com/2022/02/26/note-taking-with-org-roam-and-transclusion/ https://takeonrules.com/2022/02/26/note-taking-with-org-roam... The long story short is that we need something to process text automatically in easy to compose and easy to query ways. Emacs peoples mostly hate databases, and SOME DB models are strict, hard to keep bending, graph DB have not succeed so much so far, so it might be ad unsolved problem, a VERY OLD one, let's say: - ~612 BC Ashurbanipal of Nineveh cataloguing system - ~245 BC Callimacus Pinakes cataloguing system - ~1545 libraries of Babel by Conrad Gessner - 1673-94 Gottfried Wilhelm Leibniz, Scrinium Literatum - ... to the Mundaneum (Paul Otlet/Henry La Fontaine) - ... to the web first concept, the search engine concept ... Natural language is not much computable directly, some modern ML tools try to work on it, some classic algorithms try to do the same, most results are not much good at small scale, they are just good at very large scale for very limited results. But the point of Emacs is another, is the LispM concept, witch was also the Xerox PARC Smalltalk workstations concept: as we need ways to act on text with automation so we need OSes as a single application, where the source is live, changeable, where anything is a function the user can use anywhere so that if I have a CAS on my desktop I can solve and ODE with it inside an email and link the email in a paper. Old systems was limited by the tech of their time, Emacs by the size of its community and the burden of legacy it have, but they show a starting point that's effective. The rest is still to be invented, implemented and done. NO OTHER TOOLS so far have proven to be better in general so...

some-mthfka 4y ago

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. [1] https://project-mage.org/the-power-of-structure https://project-mage.org/the-power-of-structure

puffybuf 4y ago

After 25 years my dot emacs is _only_ 1000 lines.

some-mthfka 4y ago
I did a lot of custom bindings. Those can really bloat up the config. + Lots of packages with their configs.

woolion 4y ago

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/main/README.md https://github.com/yairchu/awesome-structure-editors/blob/ma...

some-mthfka 4y ago
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.

cutler 4y ago

TLDR - Emacs sucks.

distantsounds 4y ago

this article is hilarious because the vim csv plugin 'just works.'

db48x 4y ago
So does the Emacs one.
allarm 4y ago
Turned out the author didn’t know that csv-mode exists.
- some-mthfka 4y ago
  Yep. I will have to add it to the article (and why it's insufficient as well).
  - allarm 4y ago
    Just make sure that you’ve checked the documentation beforehand, so that you don’t miss anything obvious again.

eatonphil 4y ago

I'm not an emacs power user. I use emacs solely. 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 4y ago
I think his point is that you cannot use Emacs solely. You probably need a browser and a spreadsheet and lots of other software.
- tmtvl 4y ago
  But Emacs has browsers and spreadsheet programs and a lot of other software. Out of the box it even comes with a great editor.
- scruple 4y ago
  Can nano or pico do it? Can vim do it out of the box? For that matter, how does VSCode stand up to "very large" CSV files? I really don't know but I suspect this is less of an Emacs "problem" than it is a matter of fact for most editors that aren't specialized to the specific task of "very large" CSV files.

lycopodiopsida 4y ago

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.

some-mthfka 4y ago
> text-editing tasks than emacs/vim + tree-sitter 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 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 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.

mmargerum 4y ago

All I can say is "Glamorous toolkit" https://gtoolkit.com/ https://gtoolkit.com/

some-mthfka 4y ago
Wrote a review on it on the website, copypasting: 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/ https://gtoolkit.com/ [2] https://moldabledevelopment.com/ https://moldabledevelopment.com/ [3] https://www.youtube.com/watch?v=Pot9GnHFOVU https://www.youtube.com/watch?v=Pot9GnHFOVU

pvaldes 4y ago

But it is such a perfect place to start, my love

deleted 4y ago

[deleted]

veltas 4y ago

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

_a_a_a_ 4y ago

What a strange, whiney article.

jrm4 4y ago

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." (aka screw GNOME? :) )

draw_down 4y ago

[dead]

Woodi 4y ago

Agree at all but bashing "representations" and APIs seems strange and asking for troubles.

herewulf 4y ago

More recent follow up discussion: https://news.ycombinator.com/item?id=34380373 https://news.ycombinator.com/item?id=34380373 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.