Emacs: The most successful malleable system(malleable.systems)
malleable.systems
Emacs: The most successful malleable system
https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/
209 comments
Ironically I think org-mode is a great example of a non-malleable system. When I started using it I slowly tried to customize it to better suit my needs, but everything was quite brittle.
Posted a comment awhile back with some specific examples from my experience: https://news.ycombinator.com/item?id=20551598
Posted a comment awhile back with some specific examples from my experience: https://news.ycombinator.com/item?id=20551598
I'd say it's very customizable, but requires (sometimes significant) time investements.
I'll respond here since can't reply to the original comment:
1. "leading stars" -- I think the solution is org-hide-leading-stars (and it is basically the hack you are describing)
2. "now it takes multiple seconds to refresh my agenda view" -- org-super-agenda is a pretty mature library handles groups well. As for performance, the most significant speedup for me was setting org-agenda-span to a lower value
3. "it's actually pretty hard to find good examples of a full org-mode workflow." -- agree. One reason is perhaps because it's quite hard to communicate your workflow to other people becaue it's too specific to your needs.
4. "But problematically I now have a lot of files with similar names" -- yep, refile-outline-path, but also uniquify helps a lot.
5. "Apparently org-mode deliberately prevents the end user from adding their own custom emphasis formats" -- don't know whether that's the case; but you can abuse org-add-link-type, then you could write [highlight:Some text to highligtht], and do whatever styling you want during the export. Hacky, but kinda does the job.
Finally, it's at least possible in theory to override any org-mode function and change the logic. Of course, you can do it with any other text editor, but it would be way less effort to hack Emacs (even if it's dirty and adhoc).
I can however understand the frustration. It took me several attempts to pick up Emacs and Org-mode specifically. And I'm still very often frustrated by it, but I personally find being able to bend your editor into doing exactly what you want worth the effort.
I'll respond here since can't reply to the original comment:
1. "leading stars" -- I think the solution is org-hide-leading-stars (and it is basically the hack you are describing)
2. "now it takes multiple seconds to refresh my agenda view" -- org-super-agenda is a pretty mature library handles groups well. As for performance, the most significant speedup for me was setting org-agenda-span to a lower value
3. "it's actually pretty hard to find good examples of a full org-mode workflow." -- agree. One reason is perhaps because it's quite hard to communicate your workflow to other people becaue it's too specific to your needs.
4. "But problematically I now have a lot of files with similar names" -- yep, refile-outline-path, but also uniquify helps a lot.
5. "Apparently org-mode deliberately prevents the end user from adding their own custom emphasis formats" -- don't know whether that's the case; but you can abuse org-add-link-type, then you could write [highlight:Some text to highligtht], and do whatever styling you want during the export. Hacky, but kinda does the job.
Finally, it's at least possible in theory to override any org-mode function and change the logic. Of course, you can do it with any other text editor, but it would be way less effort to hack Emacs (even if it's dirty and adhoc).
I can however understand the frustration. It took me several attempts to pick up Emacs and Org-mode specifically. And I'm still very often frustrated by it, but I personally find being able to bend your editor into doing exactly what you want worth the effort.
See [0] for for #5 (customized highlighting).
[0]: https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorg...
[0]: https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorg...
> And I'm still very often frustrated by it, but I personally find being able to bend your editor into doing exactly what you want worth the effort.
I agree with this assessment. Emacs is frustrating and terrible and you'll never get things just right, but as a software developer, I've found its extensibility and programmability to be profoundly life-altering.
I agree with this assessment. Emacs is frustrating and terrible and you'll never get things just right, but as a software developer, I've found its extensibility and programmability to be profoundly life-altering.
> I'd say it's very customizable, but requires (sometimes significant) time investements.
It seemed like with enough effort I could get emacs to mostly do what I wanted, but it never seemed like I could get it to do what I wanted well. Maybe I just gave up on it too soon.
It seemed like with enough effort I could get emacs to mostly do what I wanted, but it never seemed like I could get it to do what I wanted well. Maybe I just gave up on it too soon.
Yes, it's quite brittle. Looking over your list, part of the problem is also that it was written to function as a WYSIWIG system in an environment meant for text buffers (rather than a generic MVC like framework where you could apply an arbitrary transformation on the on-disk data to present on the screen).
If you're a power user who would like a very malleable system, I can't imagine anything better than Scribble/Pollen. IME it felt very natural to use, and is infinitely flexible (fully-programmable in Racket).
If you're a power user who would like a very malleable system, I can't imagine anything better than Scribble/Pollen. IME it felt very natural to use, and is infinitely flexible (fully-programmable in Racket).
[can't add comment to your old post]
1. org-bullets 2. it seems like a bug with performance for long lines in emacs (at least it was in my case) 3. there is no size fits all: my org file are header, code blocks -heavy lots of hierarchy, tags, properties; yours may be completely different 4. refilling works via narrowing the list of candidates using ivy (it the same interface used for switching to a project, opening a file, switching to a different buffer, running a command, etc)
5. https://emacs.stackexchange.com/questions/5889/how-to-highli...
1. org-bullets 2. it seems like a bug with performance for long lines in emacs (at least it was in my case) 3. there is no size fits all: my org file are header, code blocks -heavy lots of hierarchy, tags, properties; yours may be completely different 4. refilling works via narrowing the list of candidates using ivy (it the same interface used for switching to a project, opening a file, switching to a different buffer, running a command, etc)
5. https://emacs.stackexchange.com/questions/5889/how-to-highli...
> 5. https://emacs.stackexchange.com/questions/5889/how-to-highli...
This is a good example of my frustration. The solution you suggested allows you to change how an existing emphasis character appears in emacs, but does not allow you to add a new emphasis character. Not great if you still want to be able to use all the old emphasis characters.
To add highlighting without interfering with an existing emphasis character, you're stuck with some ugly hacks (of which I tried a few before giving up). Apparently the reason for this particular limitation is so that org-mode has a consistent syntax for parsing outside of emacs (https://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg...). I don't care about parsing outside of emacs (and even if I did, it doesn't seem too terrible to just have my custom emphasis character get printed to the screen without the appropriate formatting). A truly malleable system wouldn't make it so hard for me to modify it to my liking based on my particular needs.
I was able to consistently get emacs/org-mode to work sorta how I wanted it to, but it was _always_ hacky and clunky.
This is a good example of my frustration. The solution you suggested allows you to change how an existing emphasis character appears in emacs, but does not allow you to add a new emphasis character. Not great if you still want to be able to use all the old emphasis characters.
To add highlighting without interfering with an existing emphasis character, you're stuck with some ugly hacks (of which I tried a few before giving up). Apparently the reason for this particular limitation is so that org-mode has a consistent syntax for parsing outside of emacs (https://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg...). I don't care about parsing outside of emacs (and even if I did, it doesn't seem too terrible to just have my custom emphasis character get printed to the screen without the appropriate formatting). A truly malleable system wouldn't make it so hard for me to modify it to my liking based on my particular needs.
I was able to consistently get emacs/org-mode to work sorta how I wanted it to, but it was _always_ hacky and clunky.
I’ve taken 3 semesters of OOP and 1 semester of functional and still have no idea how I would build a program if someone told me to
1. Write placeholder output, the equivalent of a Hello World for the task.
2. Start parameterizing parts of the program to generate the output, so that more and more of the output comes from a few source variables.
3. Eventually you want a user interface on this and have it load from disk instead of recompiling...and so you end up with a complete program.
You generally don't get there just by concentrating really hard on the architecture. You architect a bit and then try things to get empiric feedback.
2. Start parameterizing parts of the program to generate the output, so that more and more of the output comes from a few source variables.
3. Eventually you want a user interface on this and have it load from disk instead of recompiling...and so you end up with a complete program.
You generally don't get there just by concentrating really hard on the architecture. You architect a bit and then try things to get empiric feedback.
I'm writing a script right now. So far I've got a constructor written, and comments written for what the "main method" equivalent part of it will be doing.
My next step is to implement the first comment: reading in my input file, at which point I'll add some temporary code to loop through and print out what got read in, so I know I did that right.
Then I'll move on to implementing the next main-method comment, which'll loop through records from my input file, open files it says to, find certain lines, and edit the text of em. So basically using the loop I already wrote above, I'll add in code for it to find the line number I want, and print that out so I know that bit works.
etc etc. It's all iterative. You start with bare bones, and add meat and tendons here and there, iteratively, throwing in test output as you go so you know the bit you just made works.
edit: and you don't have to go in order, either. Writing comments like I did that lay out what my "main method" will be doing, lets me know "okay, i've got a file-reading bit, a file-seeking, -interpreting, and -writing bit, I'll need a bit that outputs results as CSV..." and I wrote above about implementing the first step and a little of the second, but the constructor I have written is for the last step, my results-as-CSV step, because that's a thing that was easy to think about while I pondered the tougher bits. I'll add more to that constructor, probably, as I realize "oh yeah I wanna know about X aspect of each operation result, too!"
There'll be lots of TODO comments here and there as I bounce around, and it'll get built up in bits and pieces, like starting with a spooky skeleton and adding more and more meat to it til eventually you have the whole body
My next step is to implement the first comment: reading in my input file, at which point I'll add some temporary code to loop through and print out what got read in, so I know I did that right.
Then I'll move on to implementing the next main-method comment, which'll loop through records from my input file, open files it says to, find certain lines, and edit the text of em. So basically using the loop I already wrote above, I'll add in code for it to find the line number I want, and print that out so I know that bit works.
etc etc. It's all iterative. You start with bare bones, and add meat and tendons here and there, iteratively, throwing in test output as you go so you know the bit you just made works.
edit: and you don't have to go in order, either. Writing comments like I did that lay out what my "main method" will be doing, lets me know "okay, i've got a file-reading bit, a file-seeking, -interpreting, and -writing bit, I'll need a bit that outputs results as CSV..." and I wrote above about implementing the first step and a little of the second, but the constructor I have written is for the last step, my results-as-CSV step, because that's a thing that was easy to think about while I pondered the tougher bits. I'll add more to that constructor, probably, as I realize "oh yeah I wanna know about X aspect of each operation result, too!"
There'll be lots of TODO comments here and there as I bounce around, and it'll get built up in bits and pieces, like starting with a spooky skeleton and adding more and more meat to it til eventually you have the whole body
I've been a long time Emacs user since ~1997 until ~2011, when I started developing mostly with ruby on rails on a mac, discovered TextMate and falled in love with it, with its slick UI, freshness (at the time) of ideas, ease of use, despite its obsession with mac based stuff, like the use of Finder for project navigation.
After a few years I discovered Sublime Text, with its tons of extensions and exceptional speed, bought a subscription and learned as much of it as possible, ditching TextMate.
Then I switched to Atom, mostly for the discoverability and the speed (back then) of development (and, frankly, for the hype). The only problem with Sublime Text, at least at the time, was the slow development process: new builds were few and far between.
I tried VS Code too soon, and wasn't impressed by how the navigation between buffers used to work (it has changed since then, I think).
A few years ago I did a serious attempt at learning Vim for good, but in the end I gave up, and I've come back to Emacs, this time to stay, unless something radically new is introduced.
The good thing is that I can usually tell my coworkers about features of the editors they use that they don't know, because I've used them a lot.
The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.
After a few years I discovered Sublime Text, with its tons of extensions and exceptional speed, bought a subscription and learned as much of it as possible, ditching TextMate.
Then I switched to Atom, mostly for the discoverability and the speed (back then) of development (and, frankly, for the hype). The only problem with Sublime Text, at least at the time, was the slow development process: new builds were few and far between.
I tried VS Code too soon, and wasn't impressed by how the navigation between buffers used to work (it has changed since then, I think).
A few years ago I did a serious attempt at learning Vim for good, but in the end I gave up, and I've come back to Emacs, this time to stay, unless something radically new is introduced.
The good thing is that I can usually tell my coworkers about features of the editors they use that they don't know, because I've used them a lot.
The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.
I might be in the minority here, but I don’t particularly enjoy how IDEs at the level of abstraction above vi/emacs encourage the normalization “things aren’t working well; and I’m powerless to fix it.”
To illustrate my point, if my colleague’s VSC config is broken, or if it’s taking way too long to detect python tests, or what have you, my colleague’s unfamiliarity with the layer of abstraction just below the editor (jedi, pytest, pylanguageserver), means they view the situation as inevitable, impenetrable, and part of the necessary cost of development.
With vi and emacs, you are usually aware of the programs that your IDE is dependent one, and you learn how to tune them. One might say that one shouldn’t need to concern oneself with things at that level of detail, but in practice you need to, if you’re interested in being the most effective composer of programs, no matter what IDE you choose.
For the curious and patient among us, it’s an eye-opening experience, to try and replicate your most used features of VS Code in vi or emacs. It’ll take you a while, but you’ll come out of it armed to debug and solve the kind of meta problems that most people (in my experience) view as the Sisyphean “cost of doing business”.
To illustrate my point, if my colleague’s VSC config is broken, or if it’s taking way too long to detect python tests, or what have you, my colleague’s unfamiliarity with the layer of abstraction just below the editor (jedi, pytest, pylanguageserver), means they view the situation as inevitable, impenetrable, and part of the necessary cost of development.
With vi and emacs, you are usually aware of the programs that your IDE is dependent one, and you learn how to tune them. One might say that one shouldn’t need to concern oneself with things at that level of detail, but in practice you need to, if you’re interested in being the most effective composer of programs, no matter what IDE you choose.
For the curious and patient among us, it’s an eye-opening experience, to try and replicate your most used features of VS Code in vi or emacs. It’ll take you a while, but you’ll come out of it armed to debug and solve the kind of meta problems that most people (in my experience) view as the Sisyphean “cost of doing business”.
I think this is prevalent in computer use generally. I came up on Dos & Win 3.1, and at every level the OS is trying to abstract the functionality from you.
Imagine trying to understand what a "driver" is without having a sense of what computer programming does... no way.
What i'm saying is: it's not just the IDEs... it's a mentality about computing.
And for one thing, it's the "i can do this quicker with an IDE" or "i can do this faster with a computer"
surely a computer can make things happen quickly, but truly understanding your tools takes much much longer than anybody realizes.
Imagine trying to understand what a "driver" is without having a sense of what computer programming does... no way.
What i'm saying is: it's not just the IDEs... it's a mentality about computing.
And for one thing, it's the "i can do this quicker with an IDE" or "i can do this faster with a computer"
surely a computer can make things happen quickly, but truly understanding your tools takes much much longer than anybody realizes.
> Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
Just last week I opened, edited, and saved, a 4 Gigabyte SQL dump file, in Emacs. It was a bit slower than usual, but still well usable, and certainly no crashes.
Just last week I opened, edited, and saved, a 4 Gigabyte SQL dump file, in Emacs. It was a bit slower than usual, but still well usable, and certainly no crashes.
You're right, I just opened a 1.2gb file (obtained with base64 -b 60) in fundamental mode, and it actually works decently enough.
I tried the same with Sublime Text: it took a long while to open the file but, once opened, navigating the file was very slick, I could scroll from top to end and vice versa in a breeze, so I would say that Sublime Text still wins this one.
[edited to clarify: Emacs opened the file in just a few seconds, but then going to the end of the buffer, to the beginning, to line 100.000 is quite slow.]
I tried the same with Sublime Text: it took a long while to open the file but, once opened, navigating the file was very slick, I could scroll from top to end and vice versa in a breeze, so I would say that Sublime Text still wins this one.
[edited to clarify: Emacs opened the file in just a few seconds, but then going to the end of the buffer, to the beginning, to line 100.000 is quite slow.]
Large files seem fine in emacs as long as the lines are not too long. A 100MB file is no problem if there are less than a couple of hundred characters per line. If the average line is 2K characters, emacs will be unusable.
As long as you turn off syntax highlighting, it's fine. But it's annoying that you need to do that.
I didn’t. I kept syntax highlighting on. And it was still fine.
> The odd thing about Emacs is that its vastly superior customizability (or malleabilty, as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.
I 100% agree with this. The customizability of Emacs is another double-edged sword.
On one hand you can do whatever you want within Emacs. On the other hand if you're not careful your configuration could become a gigantic mess of code that is hard to get through and debug.
You can also run into situations where you need to do a particular $thing. Sometimes that $thing are 1-2 lines of elisp, requiring a package, or just copy-pasting some lines of elsip. Other times that $thing will take hours or days to get working.
You can also find yourself in a situation where you were knee-deep in elisp customizing Emacs and then you take a break or want to switch over to a different task. Depending on what state you left your customization in Emacs could end up being broken or hard to work with until you finish your customization.
(These are all things I've personally run into).
I 100% agree with this. The customizability of Emacs is another double-edged sword.
On one hand you can do whatever you want within Emacs. On the other hand if you're not careful your configuration could become a gigantic mess of code that is hard to get through and debug.
You can also run into situations where you need to do a particular $thing. Sometimes that $thing are 1-2 lines of elisp, requiring a package, or just copy-pasting some lines of elsip. Other times that $thing will take hours or days to get working.
You can also find yourself in a situation where you were knee-deep in elisp customizing Emacs and then you take a break or want to switch over to a different task. Depending on what state you left your customization in Emacs could end up being broken or hard to work with until you finish your customization.
(These are all things I've personally run into).
Emacs offers so many tools for interactive development and debugging that your first scenario should never happen, assuming you learn what's available and how to use it. Of the systems in use today, only Smalltalk has better introspective capabilities. Common Lisp through its Genera manifestation is superior even to that, but not easily available.
Emacs is the only contemporary widely-used system that can really be described as an apex / convergence point of stability, extensibility and self-empowerment. It is the clearest manifestation of "computers are an extension of the human mind" idea that goes all the way back to control theory/cybernetics, Licklider ("Man-Computer Symbiosis"), Engelbart, Alan Kay ..
One reason Emacs is such a rabbit hole, is that it always asks more of you. It always reminds you, assuming your mind is receptive, of the sheer potential on offer. Like any iconoclastic technology, it exhibits agency in that it tempts you to start using it in the way it wants to be used! And that's powerful. Very powerful. You're not simply writing scripts to scratch a temporary itch, but really learning about how to develop strategies to better manage information. You are expanding your own mind (cybernetic fusion) and programming the new metasystem at the same time. That's not an easy problem to solve but perseverance will bring ample reward.
What does it say about the current state of affairs when the typical reaction to experiencing Emacs for the first time is one of instant recoil due to the size of the set of possibilities now made available? We've been so conditioned by tools that operate in A-B-C fashion to expect a single, well-lighted path that we become dissonant to an alternative that opens up entirely different ways of thinking about and dealing with information.
As to your last point, you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things. Eventually you'll reach the point where this sort of decision is automatic and seldom needed.
Emacs is the only contemporary widely-used system that can really be described as an apex / convergence point of stability, extensibility and self-empowerment. It is the clearest manifestation of "computers are an extension of the human mind" idea that goes all the way back to control theory/cybernetics, Licklider ("Man-Computer Symbiosis"), Engelbart, Alan Kay ..
One reason Emacs is such a rabbit hole, is that it always asks more of you. It always reminds you, assuming your mind is receptive, of the sheer potential on offer. Like any iconoclastic technology, it exhibits agency in that it tempts you to start using it in the way it wants to be used! And that's powerful. Very powerful. You're not simply writing scripts to scratch a temporary itch, but really learning about how to develop strategies to better manage information. You are expanding your own mind (cybernetic fusion) and programming the new metasystem at the same time. That's not an easy problem to solve but perseverance will bring ample reward.
What does it say about the current state of affairs when the typical reaction to experiencing Emacs for the first time is one of instant recoil due to the size of the set of possibilities now made available? We've been so conditioned by tools that operate in A-B-C fashion to expect a single, well-lighted path that we become dissonant to an alternative that opens up entirely different ways of thinking about and dealing with information.
As to your last point, you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things. Eventually you'll reach the point where this sort of decision is automatic and seldom needed.
> Emacs gives you so many tools for interactive development and debugging that your first scenario should never happen, assuming you learn what's available and how to use it.
Haha, I first used Emacs without knowing how to use the interactive development and debugging tools. I learned how to use the tools after I kept on running into issues.
> you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things.
This is a great idea! I'm going to do this from now on.
> Emacs is the only system available today that can really be described as an apex / convergence point of stability, extensibility and self-empowerment.
I absolutely agree. Using Emacs just feels so /cool/. The only time I've felt limited by Emacs has never really been Emacs' fault, it was either I didn't know enough elisp or it was due to some other program or process not interacting nicely with Emacs (which could be fixed if I knew more elisp).
Haha, I first used Emacs without knowing how to use the interactive development and debugging tools. I learned how to use the tools after I kept on running into issues.
> you can always fire up a new Emacs process and do your highly experimental customization there if you don't feel confident in being able to keep track of what's happening and/or worried about breaking things.
This is a great idea! I'm going to do this from now on.
> Emacs is the only system available today that can really be described as an apex / convergence point of stability, extensibility and self-empowerment.
I absolutely agree. Using Emacs just feels so /cool/. The only time I've felt limited by Emacs has never really been Emacs' fault, it was either I didn't know enough elisp or it was due to some other program or process not interacting nicely with Emacs (which could be fixed if I knew more elisp).
>As to your last point, you can always fire up a new Emacs process and do your highly experimental customization there
I guess I didn't feel confident in my ability to adhere to that policy (of making changes only to the secondary Emacs process), so what I do is keep a backup of my Elisp code with the result that
I guess I didn't feel confident in my ability to adhere to that policy (of making changes only to the secondary Emacs process), so what I do is keep a backup of my Elisp code with the result that
emacs -q -l <path to backup init file>
i commit all of my Emacs config to git and use version control, so in theory i can just git checkout abcdef1234 and I'm back up and running.
Can you, please, describe, why do you think that Genera was superior to Smalltalk? I never had the opportunity to test it for real; however, I checked a lot of materials about Genera, and my impressions were the opposite. So I would really appreciate some arguments.
You should really try and use it if you are seriously interested in this paradigm. You can get your hands on it with a bit of searching. As for comparing the two, the philosophies and ideas are similar. Obviously there was significant cross-pollination.
Smalltalk always had an experimental, research-oriented aura around it. It did end up in industry but in a degraded, business sense did not live up to its potential at all in that domain. The Smalltalk environments that have significant value today (mainly Squeak and to a somewhat lesser extent Pharo) are firmly rooted in research.
Genera embraces the same philosophies but also hones them to an extreme degree through the forge of practicality. Its systemic cohesion and attention to detail is unparalleled. There is little "slack" and you don't get the sense that there exist systemic aspects that were not extremely well thought-out in both design and implementation.
Smalltalk always had an experimental, research-oriented aura around it. It did end up in industry but in a degraded, business sense did not live up to its potential at all in that domain. The Smalltalk environments that have significant value today (mainly Squeak and to a somewhat lesser extent Pharo) are firmly rooted in research.
Genera embraces the same philosophies but also hones them to an extreme degree through the forge of practicality. Its systemic cohesion and attention to detail is unparalleled. There is little "slack" and you don't get the sense that there exist systemic aspects that were not extremely well thought-out in both design and implementation.
What's interesting to me is that some users seem to "imprint" like this on the first serious editor they use.
I certainly did with vi. I've jumped editors a bunch of times and still use others for specific tasks, but always come back. I'm guessing it is some combination of learning something complex - the first thing in a new area you study tends to inform how you look at other things in that area. And muscle memory.
FYI, on the Mac, BBEdit handles huge files like a champ.
I certainly did with vi. I've jumped editors a bunch of times and still use others for specific tasks, but always come back. I'm guessing it is some combination of learning something complex - the first thing in a new area you study tends to inform how you look at other things in that area. And muscle memory.
FYI, on the Mac, BBEdit handles huge files like a champ.
[deleted]
> The only feature I miss from all other editors is the incredible speed of Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I will never ever have to do again), I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
I just tried opening a 1.1GB SQL dump in vim. It took 11 seconds or so to open. That was pretty slow, but after it opened, it was pretty fluid. I could jump to the end or the middle of the file in an instant and move around like it was nothing.
EDIT: I just grew it to 10GB, and though it took longer to open, vim still works fluidly after it does. Saving the file does take about a minute or two, though.
I was surprised to find that ex wasn't able to open the 1.1GB file. It returns an error actually saying that the file is too large. Since feedback is very minimal, I would have expected it to work by loading the file incrementally in a small buffer like less does without even worrying about the whole thing at the start (no displaying total number of lines, etc.).
ed was able to open the 1.1GB file, but not the 10G one. It returns an error saying that there is no space left on device. I imagine it refers to RAM. That's pretty disappointing.
I just tried opening a 1.1GB SQL dump in vim. It took 11 seconds or so to open. That was pretty slow, but after it opened, it was pretty fluid. I could jump to the end or the middle of the file in an instant and move around like it was nothing.
EDIT: I just grew it to 10GB, and though it took longer to open, vim still works fluidly after it does. Saving the file does take about a minute or two, though.
I was surprised to find that ex wasn't able to open the 1.1GB file. It returns an error actually saying that the file is too large. Since feedback is very minimal, I would have expected it to work by loading the file incrementally in a small buffer like less does without even worrying about the whole thing at the start (no displaying total number of lines, etc.).
ed was able to open the 1.1GB file, but not the 10G one. It returns an error saying that there is no space left on device. I imagine it refers to RAM. That's pretty disappointing.
> Saving the file does take about a minute or two, though.
Last time I strace-ed vim, it did a ftruncate to 0 on the original file before writing the whole content back; so no suprise it's rather slow if it dumps 10GB on disk :)
Last time I strace-ed vim, it did a ftruncate to 0 on the original file before writing the whole content back; so no suprise it's rather slow if it dumps 10GB on disk :)
Yeah, I wasn't expecting it not to write the whole 10GB. I don't think optimizing to write just the changes is worth it. Probably no editor has done something like that. I mean if the user inserts or deletes near the beginning of the file, there's no other choice but to write the whole thing to shift the content, anyways. It's just not worth the additional complexity to minimize the writes.
I think ed uses a tmp file.
You can try a custom sam(1) fork (it uses structural regex, google/ddg them): https://github.com/deadpixi/sam
sam -d for the classic cli mode.
You can try a custom sam(1) fork (it uses structural regex, google/ddg them): https://github.com/deadpixi/sam
sam -d for the classic cli mode.
Yeah, ex too. I didn't know sam had a cli mode. Unfortunately, the one I have installed from[1] coredumps with the 1.1GB file after trying to write to a temp file.
[1] https://swtch.com/plan9port/
[1] https://swtch.com/plan9port/
That's the plan9 port edition, maybe the forked one works better. Use "sam -d" for the cli version. You won't miss a lot in the end.
I just wrote about this exact progression from TextMate to Visual Studio Code (and why I think VSCode is the end of the road) here https://blog.robenkleene.com/2020/04/13/is-visual-studio-cod...
I mostly agree with what you've written. VSC is a great product and I can't imagine moving away from it.
However, the team behind VSC has made a couple of fundamental contributions to the IDE space that makes it's continued dominance less likely. The Language Server and Debugging Server protocols that were pioneered by them mean that language support is no longer tied to a particular text editor. Clangd (C++) or rust-analyzer (Rust) and other language servers will (mostly) work just as well on any editor as long as it implements support for the protocol. These protocols have lowered the barrier for entry for text editors.
However, the team behind VSC has made a couple of fundamental contributions to the IDE space that makes it's continued dominance less likely. The Language Server and Debugging Server protocols that were pioneered by them mean that language support is no longer tied to a particular text editor. Clangd (C++) or rust-analyzer (Rust) and other language servers will (mostly) work just as well on any editor as long as it implements support for the protocol. These protocols have lowered the barrier for entry for text editors.
I second this, I used to have VSCode installed alongside Vim, but LSP allows to have a proper autocompletion virtually effortlessly, or at least more easily than before.
Now I can't think of a reason to switch from Neovim :)
Now I can't think of a reason to switch from Neovim :)
> However, the team behind VSC has made a couple of fundamental contributions to the IDE space that makes it's continued dominance less likely.
It has always really confused me why they made LSP. It seems like the exact opposite of something a Microsoft product would do.
It has always really confused me why they made LSP. It seems like the exact opposite of something a Microsoft product would do.
My impression from what I've read about VS Code is that it has lots great lightweight IDE functionality (stuff that depends on parsing code), but it doesn't seem to actually have a lot of text editing functionality like Vim or Emacs does. It has multiple cursors, which is great, but that seems to be about it.
In Emacs I can quickly select by units of characters, words, lines, sentences, paragraphs, parenthesized expression, contents of a string, LaTeX environment, etc. And there are commands to sort lines or paragraphs, change case, apply rot13, run a google search, swap two units, delete text until the next occurrence of a character or a string, etc. Vim offers a similarly rich ranges of text editing operations. Does VS Code? If so it seems sort of hidden, I couldn't find more than a handful of text editing operations in the manual.
Maybe the IDE-like features are so good that people put up with a lack of text editing operations, but that doesn't really help people like me that mostly edit prose.
Another issue is that VS Code doesn't seem to be made for easy scriptability and extension. Emacs is so easy to extend, I'll often write commands I only ever intend to use while editing one particular file. For example, I was organizing a conference once and had file with all the talk submissions, each with an ID, speaker, title and summary. I had a little table were I was planning the schedule by putting talk IDs in the time slots. I wrote a command to insert a talk ID given the speaker name (with completion!), and command to flash the speaker and title of the talk ID under the cursor. With those, shuffling the IDs around was a breeze. This was a total of about 10 lines of code which took maybe 5 minutes to write, and it gave me a bespoke UI perfect for planning that specific conference. I stored the code in the same file as all the talk information and the timetable: neat, tidy and self-contained.
I know VS Code is extensible, but it seems to be pretty high-ceremony. As far as I know I can't type a JavaScript function in buffer, select it and press a key combo to suddenly have a new editor command defined. I think I need to package the code as an extension, and the code needs to be stored in files, maybe even in a specific directory structure with some metadata?
I would love to be wrong about both the lack of text editing features and about how cumbersome extending VS Code is. (And for all I know I am wrong, I haven't tried using it for more than a couple of hours --the impressions here don't come from that but from reading the online documentation and people's blog posts.)
In Emacs I can quickly select by units of characters, words, lines, sentences, paragraphs, parenthesized expression, contents of a string, LaTeX environment, etc. And there are commands to sort lines or paragraphs, change case, apply rot13, run a google search, swap two units, delete text until the next occurrence of a character or a string, etc. Vim offers a similarly rich ranges of text editing operations. Does VS Code? If so it seems sort of hidden, I couldn't find more than a handful of text editing operations in the manual.
Maybe the IDE-like features are so good that people put up with a lack of text editing operations, but that doesn't really help people like me that mostly edit prose.
Another issue is that VS Code doesn't seem to be made for easy scriptability and extension. Emacs is so easy to extend, I'll often write commands I only ever intend to use while editing one particular file. For example, I was organizing a conference once and had file with all the talk submissions, each with an ID, speaker, title and summary. I had a little table were I was planning the schedule by putting talk IDs in the time slots. I wrote a command to insert a talk ID given the speaker name (with completion!), and command to flash the speaker and title of the talk ID under the cursor. With those, shuffling the IDs around was a breeze. This was a total of about 10 lines of code which took maybe 5 minutes to write, and it gave me a bespoke UI perfect for planning that specific conference. I stored the code in the same file as all the talk information and the timetable: neat, tidy and self-contained.
I know VS Code is extensible, but it seems to be pretty high-ceremony. As far as I know I can't type a JavaScript function in buffer, select it and press a key combo to suddenly have a new editor command defined. I think I need to package the code as an extension, and the code needs to be stored in files, maybe even in a specific directory structure with some metadata?
I would love to be wrong about both the lack of text editing features and about how cumbersome extending VS Code is. (And for all I know I am wrong, I haven't tried using it for more than a couple of hours --the impressions here don't come from that but from reading the online documentation and people's blog posts.)
The major concession I have for still using Emacs quite a bit in light of the elegance of VSCode you've pointed out is that I can do extended coding across multiple projects and runtime buffers without having to even think about reaching for my mouse.
This is also why I still use tmux come to think about it.
This is also why I still use tmux come to think about it.
> The odd thing about Emacs is that its vastly superior customizability (or malleabilty as the article says) tend to be a trap, for one can spend hours, and days, getting lost in its huge universe and falling into rabbit hole after rabbit hole instead of actually getting stuff done, but I've not yet decided if that's a bad thing or a good one.
Investing in tools is generally good ROI, but investing in tools that stand the test of time and won't go away is the best ROI.
Yes, I've probably spent a cumulative few weeks customizing emacs. But I've been using it since 1991 and expect to continue using it for the rest of my life. That's as good as it gets for a tool.
When I'm forced to use some tool du jour I don't bother spending much any time customizing it because I know it is a passing fad, soon to fade. So why bother. But timeless tools are worth the love.
Investing in tools is generally good ROI, but investing in tools that stand the test of time and won't go away is the best ROI.
Yes, I've probably spent a cumulative few weeks customizing emacs. But I've been using it since 1991 and expect to continue using it for the rest of my life. That's as good as it gets for a tool.
When I'm forced to use some tool du jour I don't bother spending much any time customizing it because I know it is a passing fad, soon to fade. So why bother. But timeless tools are worth the love.
> I'm surely reaching for Sublime Text, no other editor can AFAIK open a 200+MB file without freezing and/or crashing.
For this I use the xi-editor. 20 Gb text file? No problem.
For this I use the xi-editor. 20 Gb text file? No problem.
I didn't realize Xi was in a "usable" state now. What frontend do you use?
It is usable for reading and editing files. Not something I'd use all day, but if I need to edit a huge file, there aren't really great options for that.
Oh, that's great. I saw the announcement of xi-editor when it was in its early stages, I'll git it a try.
[deleted]
Last time I checked there was no vim keybindings :(
> but I've not yet decided if that's a bad thing or a good one.
It's a good thing, because it is time well spend.
It's a good thing, because it is time well spend.
It's a shame that the Sublime package ecosystem seems to be a shell of its former self, with once-popular packages going unmaintained or entirely deleted.
Sublime is one of the few closed-source proprietary programs that I've been more than happy to pay for, just because it's that good.
Sublime is one of the few closed-source proprietary programs that I've been more than happy to pay for, just because it's that good.
Sublime was a victim of it's own success when it came to it's packages. It was a great ecosystem, but Sublime needed a complete rework to support some more basic customization, like allowing packages to add functionality to the sidebar.
I wonder whether it would be feasible to create some limited but advanced enough standard for editor-packages which could be used with all editors. Similar to the LSP oder webExtensions that browsers have. I mean a good part of editor packages are probably quite simple and could be generalized enough to work with all mature editors.
Textmate-Package-Format for some time seems to serve that area, but somehow it died out.
Textmate-Package-Format for some time seems to serve that area, but somehow it died out.
> but I've not yet decided if that's a bad thing or a good one.
It's a bad thing, you should watch football instead.
(The meaning of the above string is that I argue that investing spare time into hobbyistic software development is time well spent.)
It's a bad thing, you should watch football instead.
(The meaning of the above string is that I argue that investing spare time into hobbyistic software development is time well spent.)
While I am a fan of Emacs (IMO any one of Org, AUCTeX, or Magit is in itself a worthwhile reason to use Emacs, though of course the ease of customizing nearly anything with just a few lines of elisp is the main comfort), I think it's also worth looking at lessons from the failures of Emacs — what prevents or prevented Emacs from being even more successful? (As the post says, Emacs's "success" is only when considered relative to other malleable systems.)
As a die-hard Emacs user, this is also something that has been occupying me lately. There is too little thought going into the deficits of Emacs; many people I convinced to give it a try went back to Sublime, VSCode etc. Emacs has two main shortcomings, in my opinion. The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors; Emacs completely ignored these. The main argument has always been "won't work in a tty", but there should come a point where tty is deprecated or at least treated differently. The other is evolving the language. Elisp was great for its time, but compared to modern languages its age clearly shows. There are no namespaces, it can be dead slow, support for networking is limited, regular expressions are weird etc. I think there should be more work going into modernizing the language, which can also be used to introduce facilities for GUI elements and networking code, especially async.
I strongly believe that TTY compatibility is a feature which should not be discarded. But that doesn't, I think, prevent the kind of features you mention: they just need to be first-class UI features like the minibar is.
Agreed that Elisp needs to be upgraded. I think that it should just be replaced with Common Lisp, which has namespaces (packages), and is very fast, and whose implementations support networking & threads just fine. Of note, part of why Emacs regexps are so unusual is that they are pragmatic: since they will be used to match Lisp source so often, () are not the metachars they are in other regexp dialects.
Agreed that Elisp needs to be upgraded. I think that it should just be replaced with Common Lisp, which has namespaces (packages), and is very fast, and whose implementations support networking & threads just fine. Of note, part of why Emacs regexps are so unusual is that they are pragmatic: since they will be used to match Lisp source so often, () are not the metachars they are in other regexp dialects.
> Emacs regexps are so unusual
Parentheses are also not metachars in Vi (and Vim) regexps by default, and are not metachars in POSIX BRE (basic regular expressions).
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
The grep utility, for instance, understands BREs by default; you must use grep -E to get ERE (extended regex) in which ( and ) are grouping characters, or else the deprecated egrep command (not in POSIX).
Parentheses are also not metachars in Vi (and Vim) regexps by default, and are not metachars in POSIX BRE (basic regular expressions).
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
The grep utility, for instance, understands BREs by default; you must use grep -E to get ERE (extended regex) in which ( and ) are grouping characters, or else the deprecated egrep command (not in POSIX).
> Emacs has two main shortcomings, in my opinion.
Eh, no.
Emacs has a shitload of bugs (sorry for the language), and an ad-hoc configuration and package installation that inevitably turns your Emacs installation into a bespoke ball of mud.
(Goes in hand with 'malleability', I guess, but still a very subpar user experience.)
Eh, no.
Emacs has a shitload of bugs (sorry for the language), and an ad-hoc configuration and package installation that inevitably turns your Emacs installation into a bespoke ball of mud.
(Goes in hand with 'malleability', I guess, but still a very subpar user experience.)
I'm not going to "defend" Emacs here, it's a piece of software and you use it if it suits your purposes, but I find it to be quite stable for the feature set it offers. Also if you put moderate effort into it, it's possible to achieve a reproducible packaging and configuration state. I can check out my .emacs.d (https://github.com/afroisalreadyinu/emacsd/) on any Linux computer, start Emacs and work on it as if it's my own computer.
I spend most my time in emacs; my experience is it's pretty buggy. Probably mostly packages & their interactions than emacs per se, but for me emacs is all about the customizability & the packages...
Yeah there's this dilemma. Emcas, out of the box, seems stable enough (and performs well enough?). But for many of us, the features it offers ootb are nowhere near enough. So you start installing packages and it quickly turns into a clusterfuck and you have bizarre little bugs and interactions everywhere. And it still doesn't work exactly the way you want, even if the bugs were not present.. so you have to spend a huge amount of time trying to figure the clusterfuck out so that you can start working on it and make it right. And figure out why it got slow. Or sigh and give up.
It isn't helped by the fact that some devs insist on using bleeding edge melpa packages and their stable versions are broken. Other devs' bleeding edge versions are prone to break..
Emacs, with its packages, is one of the most chaotic things I've seen. I don't know if there's any hope for me to tame it in a reasonable timeframe.
It isn't helped by the fact that some devs insist on using bleeding edge melpa packages and their stable versions are broken. Other devs' bleeding edge versions are prone to break..
Emacs, with its packages, is one of the most chaotic things I've seen. I don't know if there's any hope for me to tame it in a reasonable timeframe.
Ha, yeah, you've captured it nicely. I have a TODO list 25 items long of problems to try to track down; occasionally I'll pick one off, but I think the list is growing faster than it's shrinking.
It's an open question, but I suspect it's not impossible to have both a robust and flexible system...think Emacs, but instead of the wild-west of Lisp as the extension language, something more in the vein of Rust...
It's an open question, but I suspect it's not impossible to have both a robust and flexible system...think Emacs, but instead of the wild-west of Lisp as the extension language, something more in the vein of Rust...
Since you use evil.. does term-char-mode work? Can you send C-x or C-z to the application? (without a workaround like (term-send-raw-string "^X"))
> The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors;
What do you mean? Emacs has them too, just not nice ones. Also, emacs is not an IDE, so there is some limit on what kind of interfaces people will build.
But yes, the GUI-parts of emacs are a big liability for future growing. While emacs does has offer all the nice visual tweaks, they also all sucks because of bad implementation and limitations in emacs itself.
What do you mean? Emacs has them too, just not nice ones. Also, emacs is not an IDE, so there is some limit on what kind of interfaces people will build.
But yes, the GUI-parts of emacs are a big liability for future growing. While emacs does has offer all the nice visual tweaks, they also all sucks because of bad implementation and limitations in emacs itself.
I do love the fact that emacs runs on a TTY, though. It means that useful programs in emacs are useful TTY programs. For instance, the ebook reader, nov.el, is the best available epub reader for the TTY right now. It would be awful to lose that.
The defaults. They aren't very good, IMO. Many users don't want to spend time with customizing, they want a system which works instantly with language plugins, and so on. VSCode does a very good job at that.
Emacs is for people who like to deeply personalize their editors. That's why I use it. But it takes time and learning elisp and many people are unwilling to do that.
Emacs is for people who like to deeply personalize their editors. That's why I use it. But it takes time and learning elisp and many people are unwilling to do that.
But I believe people trying emacs are attracted by it because something in them makes them crave customization above out-of-the-box productivity.
My theory is that the awful defaults are a test: a baptism of (pretty ugly) fire. It's designed to make you take one look and walk away in amused bewilderment... which I'd say is the right choice for most people! People want "it just works tm". Emacs is not that kind of application.
If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.
If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.
I’m not sure this is true. The enormity of the amount of things that need to be configured before it becomes usable leads new people to use things like Spacemacs etc. This means they rely on other peoples’ config, and aren’t able to customise the editor for themselves.
The same issue exists in Vim. So many nice features of Vim (such as file management using buffers) are underused, because by default they aren’t configured in a usable way.
The same issue exists in Vim. So many nice features of Vim (such as file management using buffers) are underused, because by default they aren’t configured in a usable way.
Otoh Vim has some good stuff out of the box that emacs sorely needs. Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required, and I have not found anything like that for emacs. Ctags works out of the box. It's a bit weird that cscope integration is worse (you need a script that scans up your directory hierarchy to find the database; ctags support has this built in). In emacs you can install the xcscope package but it's miserable compared to vim's built-in cscope support, and doesn't integrate with evil's tag stack.. sigh.
> Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required
For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.
For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.
I remember using emacs for C programming with make. M-x compile worked out of the box. I don't think emacs culture would suffer if TypeScript worked out of the box today.
Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands in emacs 9 times out of 10. Emacs still does some fundamentals better (undo), can be used in a terminal and, if you avoid bloatware like spacemacs, also offers better performance. If one is willing to ignore the spyware and proprietary component aspects, vs code by now is a better choice even for most power users, IMO.
> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things
I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development.
For me though it's still not even close.
I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development.
For me though it's still not even close.
I find this hard to believe. Not that you may like one over the other, but that one is superior.
Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.
Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.
That's also built into VSCode. The feature is called "Remote".
Not the same, from what I have seen. But, more pointedly, I have been doing this specific workflow for over the last decade.
So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.
So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.
> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things
Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with.
With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently.
In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.
Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with.
With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently.
In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.
> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands
I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.
VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.
From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.
It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.
I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.
VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.
From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.
It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.
I tried typescript lsp in emacs (tide) and it gave me a lot for free (realtime type check, formatting). What else VSCode has ? nicer hints (dom based) and refactoring ? Genuinely curious.
Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.
Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.
From my observation, the IDE-parts of VS Code are what put most computers to their knees. VS is very performant when acting like a regular text editor, even better than emacs in certain cases -_-
But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.
But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.
That's odd.. tsc doesn't seem to be the issue (I barely notice it on my machine). But I'm no internal dev so maybe.
emacs is by now quite inferior to VSCode for most thing
I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together.
The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better".
This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.
I wouldn’t call that it’s only success. It’s an application that’s been used and maintained for 40 years. It’s the application that practically spawned the Free Software movement. It’s one of the most portable programs I’ve ever seen. The basic interface has been cloned (with less malleability) dozens of times.
It may not be the most used text editor today but overall I’d rank it one of the most successful applications in history — along with perhaps Netscape and Excel.
It may not be the most used text editor today but overall I’d rank it one of the most successful applications in history — along with perhaps Netscape and Excel.
(Replying to myself.) For what it's worth, I somewhat regret the wording of the parent post. I was hoping for a thread on lessons from Emacs generally applicable to the topic of malleable systems — maybe things like: (1) periodically integrate the community's best "packages" into the "core" else you'll have a mess (also consider: LaTeX), (2) figure out how you can continue to change defaults without fear of breaking old users' workflows — whatever, I was hoping for more lessons — but instead it (I should have known this!) became a thread mostly about Emacs in particular.
> what prevents or prevented Emacs from being even more successful?
Because is big, stuck in it's own past, with many useless quirks. Additionally the malleable system has a price, which for most is bigger than it's benefits. Emacs is always stuck in a loop of fetching up with the rest of the world, living in it's own utopia and creeping away everone who can't dive deep fast enough.
Most people are pracmatic about their tools. Tools should just do their job and don't get in the way. Emacs doe not deliver that, and the people can be quite dogmatic about certain things. It changed in the last years, fresh blood and concepts are spreading their influence, but we will see in another decade whether this actually had some longlasting effect or was jsut another circle of quirk-building.
Because is big, stuck in it's own past, with many useless quirks. Additionally the malleable system has a price, which for most is bigger than it's benefits. Emacs is always stuck in a loop of fetching up with the rest of the world, living in it's own utopia and creeping away everone who can't dive deep fast enough.
Most people are pracmatic about their tools. Tools should just do their job and don't get in the way. Emacs doe not deliver that, and the people can be quite dogmatic about certain things. It changed in the last years, fresh blood and concepts are spreading their influence, but we will see in another decade whether this actually had some longlasting effect or was jsut another circle of quirk-building.
Everything you write I see the other way around.
I've been using IDEs for nearly 30 years, from QBasic in DOS, Turbo Pascal, Visual Basic, Delphi, Visual Studio, Eclipse, RubyMine, IntelliJ... and every time my career shifts a bit, I ended up learning a new IDE with new keystrokes and new idioms.
Changing IDE every 3 to 5 years gets old after a while. You learn not to learn too much of the IDE, because a lot of stuff beyond the basics of text editing won't come with you to the next IDE.
Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. When you say "stuck in the past", I say "stuff I did 20 years ago still works".
You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.
YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.
[1] IntelliJ is far inferior to Eclipse for incremental compiles and running tests, but Eclipse has a horrific UI, weird modal system, and a parallel project management universe in workspaces. Neither have editors as good as Emacs.
I've been using IDEs for nearly 30 years, from QBasic in DOS, Turbo Pascal, Visual Basic, Delphi, Visual Studio, Eclipse, RubyMine, IntelliJ... and every time my career shifts a bit, I ended up learning a new IDE with new keystrokes and new idioms.
Changing IDE every 3 to 5 years gets old after a while. You learn not to learn too much of the IDE, because a lot of stuff beyond the basics of text editing won't come with you to the next IDE.
Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. When you say "stuck in the past", I say "stuff I did 20 years ago still works".
You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.
YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.
[1] IntelliJ is far inferior to Eclipse for incremental compiles and running tests, but Eclipse has a horrific UI, weird modal system, and a parallel project management universe in workspaces. Neither have editors as good as Emacs.
Yes -- at first I saw emacs' age as an annoyance, now I find it to be its greatest strength.
Yes, elisp could be more "modern," even by lisp standards. Yes, twiddling a bunch of global vars and then calling global functions is not an ideal way to program to an API (this is at least sometimes the case in emacs).
But the payoff for accepting these shortcomings is you get to draw on literally decades of development and a large pool of knowledgeable ongoing contributors. I've seen calls to have emacs support Rust, JavaScript, python, etc. But the X in "emacs should support X" seems to change almost yearly. Learning to accept elisp means learning to respect all the work that went before, all the code that just silently runs and works every day. Which in turn means your own contributions are much more likely to be doing some good for years and years.
Yes, elisp could be more "modern," even by lisp standards. Yes, twiddling a bunch of global vars and then calling global functions is not an ideal way to program to an API (this is at least sometimes the case in emacs).
But the payoff for accepting these shortcomings is you get to draw on literally decades of development and a large pool of knowledgeable ongoing contributors. I've seen calls to have emacs support Rust, JavaScript, python, etc. But the X in "emacs should support X" seems to change almost yearly. Learning to accept elisp means learning to respect all the work that went before, all the code that just silently runs and works every day. Which in turn means your own contributions are much more likely to be doing some good for years and years.
> Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc.
If you are at the point where you use emacs for everythings, then it doesn't matter anymore how alien emacs is. But until then it's a long path, and not many are willing to walk it.
But even then you must accept some sacrifies and ignore that what emacs can't do. If you are with it for so long, you likely don't know and miss all the fancy new stuff, and at this point you don't need it anymore. But new user are differnt there.
> You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.
I would not say always, there were times when development of emacs was much much more worse then today. I jsut think those darkest times are completly gone and what in the past were single drops of blood is now a steady river for the next decacde.
If you are at the point where you use emacs for everythings, then it doesn't matter anymore how alien emacs is. But until then it's a long path, and not many are willing to walk it.
But even then you must accept some sacrifies and ignore that what emacs can't do. If you are with it for so long, you likely don't know and miss all the fancy new stuff, and at this point you don't need it anymore. But new user are differnt there.
> You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case.
I would not say always, there were times when development of emacs was much much more worse then today. I jsut think those darkest times are completly gone and what in the past were single drops of blood is now a steady river for the next decacde.
Every IDE is alien when you come into it. It took me ages to get used to Eclipse, and even then I greatly enjoyed jumping ship to IntelliJ. Visual Studio deeply irritated me with its different key bindings and editor behaviour to Borland IDEs, I ended up writing a bunch of VBA macros to take care of some of the more subtle differences, until VS stopped integrating VBA!
> Every IDE is alien when you come into it.
I don't think so. Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. But Emacs is not even doing that. Simply because it was made long before this lingua and concepts were established. Vim is similar in that regard, though not much as worse as emacs, if we ignore the conceptional difference.
Any complex application has it's quirks and special parts. But with emacs you have on top that even the basic parts are special and full of quirks. So instead of needing to adapts to 10% or 50% new ground, it's more like 80% or 100%, and for many this can be too much.
I don't think so. Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. But Emacs is not even doing that. Simply because it was made long before this lingua and concepts were established. Vim is similar in that regard, though not much as worse as emacs, if we ignore the conceptional difference.
Any complex application has it's quirks and special parts. But with emacs you have on top that even the basic parts are special and full of quirks. So instead of needing to adapts to 10% or 50% new ground, it's more like 80% or 100%, and for many this can be too much.
Most modern Apps follow established lingua and concepts on the fundamental and often middle levels.
> Most modern Apps follow established lingua and concepts on the fundamental and often middle levels
This is not at all true of the IDE pair (Visual Studio / XCode) I use at work.
I do all my code editing in spacemacs and use the IDEs as heavyweight build / debug / code-search frontends (not for lack of trying to do these things in emacs, mind you). The process of doing each of those things is completely different between XCode and VS.
This is not at all true of the IDE pair (Visual Studio / XCode) I use at work.
I do all my code editing in spacemacs and use the IDEs as heavyweight build / debug / code-search frontends (not for lack of trying to do these things in emacs, mind you). The process of doing each of those things is completely different between XCode and VS.
> I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.
I'm in a similar boat to you, in a different language environment. With OmniSharp, I'm able to do 80% of my C# development in emacs, and could probably do more if we were on .NET Core rather than .NET Framework. But I still have to go into Visual Studio for managing project files, and occasionally for debugging. While working remotely, I intensely wish I could just SSH into my Windows workstation and do my work in Emacs rather than having to use the kludgy remote desktop software we use.
I'm in a similar boat to you, in a different language environment. With OmniSharp, I'm able to do 80% of my C# development in emacs, and could probably do more if we were on .NET Core rather than .NET Framework. But I still have to go into Visual Studio for managing project files, and occasionally for debugging. While working remotely, I intensely wish I could just SSH into my Windows workstation and do my work in Emacs rather than having to use the kludgy remote desktop software we use.
> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs.
If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.
If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.
I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it.
It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while.
I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).
It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while.
I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).
Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.
I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable.
IntelliJ handles this project pretty much without breaking a sweat.
IntelliJ handles this project pretty much without breaking a sweat.
I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.
> Additionally the malleable system has a price, which for most is bigger than it's benefits.
And yet here we are, talking in a web browser, the most malleable modern environment of all. We’re not running some forum-only app, like we used to have.
And yet here we are, talking in a web browser, the most malleable modern environment of all. We’re not running some forum-only app, like we used to have.
Disputable. Are web browsers the sytem or web-technologies (html, css,...)? Emacs has also browers, but with limited abilities, does that make emacs more malleable than web browsers, despite offering just a subset of them?
Anyway, I think one reason why web browsers are so successful despite offering that malleable experience is that 1) it was designed for this specific usecase, and at some point even enhanced direction from document- to app-environment, and 2) someone else is paying the price for it, so the users don't care and can just consum.
If emacs would receive as much money and competence as web-technologies and browsers received, it surelye would be a first-rate environment with excellent support for all users on all skill-levels. But then it probably would be just a web-stack of different name.
Anyway, I think one reason why web browsers are so successful despite offering that malleable experience is that 1) it was designed for this specific usecase, and at some point even enhanced direction from document- to app-environment, and 2) someone else is paying the price for it, so the users don't care and can just consum.
If emacs would receive as much money and competence as web-technologies and browsers received, it surelye would be a first-rate environment with excellent support for all users on all skill-levels. But then it probably would be just a web-stack of different name.
The strength of emacs is that once you can program it it's extremely easy to write extensions for it, even for one off tasks, because it's so quick and easy.
Compared to this writing extensions for vscode, for example, is much more convoluted. You wouldn't create a new vscode extension for a 1 hour task, while with emacs it's trivial to write some small code which can help you with your current task. I often do.
Compared to this writing extensions for vscode, for example, is much more convoluted. You wouldn't create a new vscode extension for a 1 hour task, while with emacs it's trivial to write some small code which can help you with your current task. I often do.
> The strength of emacs is that once you can program it it's extremely easy to write extensions for it
It's not easy by many miles. It's possible but learning the emacs-environment to some aceptable level can take much time and toll.
> Compared to this writing extensions for vscode, for example, is much more convoluted.
Depends on your competence and tooling I would say. From what I've seen, it isn't much harder than writing something midly complex for emacs, But very simple stuff is easier done in emacs, something like single functions. But those have the price that you need to learn emacs lisp on decent enough level first.
But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
It's not easy by many miles. It's possible but learning the emacs-environment to some aceptable level can take much time and toll.
> Compared to this writing extensions for vscode, for example, is much more convoluted.
Depends on your competence and tooling I would say. From what I've seen, it isn't much harder than writing something midly complex for emacs, But very simple stuff is easier done in emacs, something like single functions. But those have the price that you need to learn emacs lisp on decent enough level first.
But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
> It's not easy by many miles.
Depends on the perspective of-course. I mean, LISP is a real barrier, but once you got over the parenthesis and suck-up some quirks [1], you can get productive quite easily.
Here are two example extensions from my `init.el`.
Use this function my typing `M-x hh <tab>` to see all my extensions, if I forgot the name. I have bound hh-insert-date to a key b/c I use it frequently.
[1] https://www.heinrichhartmann.com/blog/problem-lisp.html
Depends on the perspective of-course. I mean, LISP is a real barrier, but once you got over the parenthesis and suck-up some quirks [1], you can get productive quite easily.
Here are two example extensions from my `init.el`.
(defun hh-curl (url)
"Create tmp buffer with curl output"
(interactive "sURL: ")
(let ((buffer url))
(with-output-to-temp-buffer buffer
(shell-command (format "curl -s %s" url) buffer)
(pop-to-buffer buffer))))
(defun hh-insert-date ()
"Insert current date in ISO format"
(interactive)
(insert (format-time-string "%Y-%m-%d")))
Use this function my typing `M-x hh <tab>` to see all my extensions, if I forgot the name. I have bound hh-insert-date to a key b/c I use it frequently.
[1] https://www.heinrichhartmann.com/blog/problem-lisp.html
I'm not talking about lisp or syntax. Learning that is fast. But this is worthless. Learning syntax is fast in any language after a certain point of knowledge.
The juice is in the batteries. The datatypes, the libraries, the environment. Getting to know how to do the most simple things can be very cumbersome in any language, and especially in something old and loaded like emacs.
There is a reason why popular external libs like s.el or f.el are so widely used, and why emacs-projects itself has started modernizing on that front. But those are things you don't know as a beginner.
The juice is in the batteries. The datatypes, the libraries, the environment. Getting to know how to do the most simple things can be very cumbersome in any language, and especially in something old and loaded like emacs.
There is a reason why popular external libs like s.el or f.el are so widely used, and why emacs-projects itself has started modernizing on that front. But those are things you don't know as a beginner.
After spending lots of time customizing various software from macOS to Emacs to Vim to AppleScript to iOS with Workflow, I've come to the conclusion the language and environment are practically irrelevant. There are simply two kinds of people:
1. People who complain about this or that problem in the environment (and say that's why they don't customize it).
2. People who learn and use the environment.
These two groups exist in every one of these communities. There just a fact of life in the world of customization.
(PS: I'm trying to put this in the most neutral way possible, I'm trying not to make any judgements here, personally I'm a customizer, but I'll be the first to admit that I waste a lot of time customizing, and I won't make the argument that customizing is inherently better, just that I prefer it. The point is, the very nature of customizing is what makes it hard, the quirks of the individual environment just don't seem to make much a difference.)
1. People who complain about this or that problem in the environment (and say that's why they don't customize it).
2. People who learn and use the environment.
These two groups exist in every one of these communities. There just a fact of life in the world of customization.
(PS: I'm trying to put this in the most neutral way possible, I'm trying not to make any judgements here, personally I'm a customizer, but I'll be the first to admit that I waste a lot of time customizing, and I won't make the argument that customizing is inherently better, just that I prefer it. The point is, the very nature of customizing is what makes it hard, the quirks of the individual environment just don't seem to make much a difference.)
Yes, I agree that creating more complex extensions is cumbersome. Would love to have ready-to-use python dicts + string functions!
> But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
I'm not sure what you're saying here? How does another "useful tooling-language" help if your goal is to customize your editor? I guess what you're saying is why don't you write those customizations in another environment like Bash? The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text (I often want to remove some text quickly without having to think about whether I might want it again later). I have lots of little customizations like that.
I'm not sure what you're saying here? How does another "useful tooling-language" help if your goal is to customize your editor? I guess what you're saying is why don't you write those customizations in another environment like Bash? The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text (I often want to remove some text quickly without having to think about whether I might want it again later). I have lots of little customizations like that.
I'm referencing the "1 hour-task", which from my understanding usually does not demand to customize the editor itself. I mean what task would even demand customizing the editor, which would not be possible with other environments like bash, python, ruby, powershell?
> The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text
But you don't need elisp for this. Interweaving external tools is possible in any mature editor, including emacs.
> The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text
But you don't need elisp for this. Interweaving external tools is possible in any mature editor, including emacs.
> I'm referencing the "1 hour-task", which from my understanding usually does not demand to customize the editor itself.
I your task involves the same kind of editing, for example, then in emacs it's trivial to write a custom function and bind a key to it, making your task much easier.
I your task involves the same kind of editing, for example, then in emacs it's trivial to write a custom function and bind a key to it, making your task much easier.
I agree with your first point.
Learning elisp and becoming comfortable within the Emacs ecosystem is definitely a daunting task, but once you do learn elisp then modifying Emacs to how you want it to be is extremely easy.
Other editors require creating a plugin/extension that follows some sort of guidelines (or you can just modify the source code).
For example, here's VS Code's "Hello World" plugin anatomy: https://code.visualstudio.com/api/get-started/extension-anat...
They recommend a plugin to have several files and to have JSON to specify specifics of the extension.
Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Granted, it's not quite fair to compare Emacs and VS Code in this fashion. VS Code has a system in place for having an extension whereas Emacs treats your .emacs file as an extension of itself. Part of Emacs is written in elisp, and when Emacs runs it runs the code in your .emacs file just like other elisp code (this statement is probably not entirely true, but it's just a simplified way of viewing it).
To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Regarding this point: > But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
You can take advantage of existing tooling for Emacs - you can actually get away with quite a lot in Emacs without knowing any elisp. The barrier to entry to try out code snippets from the internet is extremely low - all you need to do is copy-paste.
That being said, this is a double-edged sword. Once you start copy-pasting a ton of snippets there's a chance that things may conflict and break. You'll need to start learning how to use Emacs' debugging tools and you'll probably have to familiarize yourself with elisp.
In addition to that, the tooling depends on what other Emacs users have created - if you're trying to do something in Emacs that other Emacs users haven't worked with then you may need to learn elisp. The existing tooling for Emacs is quite great, I haven't found too many things that didn't have tooling, or if there wasn't any tooling, then there's something that is generic enough to work with what I'm trying to do.
Ex: company-mode (https://github.com/company-mode/company-mode) for auto complete can work for programming languages that do not have a company-mode backend, there's also dumb-jump for getting to definitions(https://github.com/jacktasia/dumb-jump).
Learning elisp and becoming comfortable within the Emacs ecosystem is definitely a daunting task, but once you do learn elisp then modifying Emacs to how you want it to be is extremely easy.
Other editors require creating a plugin/extension that follows some sort of guidelines (or you can just modify the source code).
For example, here's VS Code's "Hello World" plugin anatomy: https://code.visualstudio.com/api/get-started/extension-anat...
They recommend a plugin to have several files and to have JSON to specify specifics of the extension.
Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Granted, it's not quite fair to compare Emacs and VS Code in this fashion. VS Code has a system in place for having an extension whereas Emacs treats your .emacs file as an extension of itself. Part of Emacs is written in elisp, and when Emacs runs it runs the code in your .emacs file just like other elisp code (this statement is probably not entirely true, but it's just a simplified way of viewing it).
To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Regarding this point: > But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
You can take advantage of existing tooling for Emacs - you can actually get away with quite a lot in Emacs without knowing any elisp. The barrier to entry to try out code snippets from the internet is extremely low - all you need to do is copy-paste.
That being said, this is a double-edged sword. Once you start copy-pasting a ton of snippets there's a chance that things may conflict and break. You'll need to start learning how to use Emacs' debugging tools and you'll probably have to familiarize yourself with elisp.
In addition to that, the tooling depends on what other Emacs users have created - if you're trying to do something in Emacs that other Emacs users haven't worked with then you may need to learn elisp. The existing tooling for Emacs is quite great, I haven't found too many things that didn't have tooling, or if there wasn't any tooling, then there's something that is generic enough to work with what I'm trying to do.
Ex: company-mode (https://github.com/company-mode/company-mode) for auto complete can work for programming languages that do not have a company-mode backend, there's also dumb-jump for getting to definitions(https://github.com/jacktasia/dumb-jump).
> For example, here's VS Code's "Hello World" plugin anatomy:
Yes, boilerplate like this is typical with frameworks. It's a tradeoff with some benefits and a price. IIRC there are some cli-commands for generating and handling this, so it's probably less effort than it seems.
> Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Depends on what you are doing. For packages, emacs also has boilerplate. And if you add elpa or melpa there is even more to do. At the end the only real difference is the lack of simple adaptability in VS Code. And I'm not enough of an expert on this topic to know whether it's even completly true.
> To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Considering VS Code is just a browser under the hood, I wonder whether it wouldn't be possible to do something similar out of the box to some degree. I can understand that that they have some tighter control over GUI-stuff, but considering you can hot-load extensions I would assume there are some ways for this and they are probably just bad. Maybe some emacs-culture should leek to vs code to make this happen.
I heard atom editor is better in that regard, but also worse in performance.
Yes, boilerplate like this is typical with frameworks. It's a tradeoff with some benefits and a price. IIRC there are some cli-commands for generating and handling this, so it's probably less effort than it seems.
> Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Depends on what you are doing. For packages, emacs also has boilerplate. And if you add elpa or melpa there is even more to do. At the end the only real difference is the lack of simple adaptability in VS Code. And I'm not enough of an expert on this topic to know whether it's even completly true.
> To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Considering VS Code is just a browser under the hood, I wonder whether it wouldn't be possible to do something similar out of the box to some degree. I can understand that that they have some tighter control over GUI-stuff, but considering you can hot-load extensions I would assume there are some ways for this and they are probably just bad. Maybe some emacs-culture should leek to vs code to make this happen.
I heard atom editor is better in that regard, but also worse in performance.
For the record, I've written customizations in most major text editors, here's how I'd rank them in ease of customization, from easiest to hardest:
Emacs = Vim > Atom > BBEdit > TextMate > Visual Studio Code
It mainly comes down to whether a text editor has a built-in place to quickly add customizations, and whether there's a DSL to quickly wrap shell commands. Visual Studio Code has neither.
(Admittedly wrapping shell commands is just the approach to writing customizations that I personally prefer.)
Emacs = Vim > Atom > BBEdit > TextMate > Visual Studio Code
It mainly comes down to whether a text editor has a built-in place to quickly add customizations, and whether there's a DSL to quickly wrap shell commands. Visual Studio Code has neither.
(Admittedly wrapping shell commands is just the approach to writing customizations that I personally prefer.)
> Emacs = Vim
I don't know about that. I agree they're roughly equivalent in some respects, but elisp is way nicer than vimscript, which is horrifying. Honestly elisp being nicer than vimscript is the primary reason I switched from vim to evil-mode/emacs.
I don't know about that. I agree they're roughly equivalent in some respects, but elisp is way nicer than vimscript, which is horrifying. Honestly elisp being nicer than vimscript is the primary reason I switched from vim to evil-mode/emacs.
This is very true. To combat this, I've developed a process of using a personal extension customize VS Code, the details of how this works are in the my personal extension's README (https://github.com/robenkleene/vscode-robenkleene). This lets me customize VSCode in a similar way to how I can customize Emacs and Vim.
Emacs is more like an Elisp programming environment that happens to have a text editor built in. And a window manager, process manager, shell, terminal multiplexer, async event loop, cross-platform OS APIs, debugger, a bazillion libraries for everything you could need.
Just to see how far one can go I cobbled together a few libraries one afternoon and wrote a Dockerfile that enables one to write web applications in Elisp: https://github.com/agentultra/Dockmacs
I'm having trouble finding them but I've read stories of hackers developing and deploying useful applications they built in emacs to end users. I don't know that I'd go that far but... you do get cross-platform GUI controls so it doesn't seem impossible for simple, straight forward tools.
Just to see how far one can go I cobbled together a few libraries one afternoon and wrote a Dockerfile that enables one to write web applications in Elisp: https://github.com/agentultra/Dockmacs
I'm having trouble finding them but I've read stories of hackers developing and deploying useful applications they built in emacs to end users. I don't know that I'd go that far but... you do get cross-platform GUI controls so it doesn't seem impossible for simple, straight forward tools.
One you may be thinking of is that Amazon used an Emacs Lisp interface for their customer service for a number of years.
https://sites.google.com/site/steveyegge2/tour-de-babel
Search for "Mailman" to find the relevant bit.
https://sites.google.com/site/steveyegge2/tour-de-babel
Search for "Mailman" to find the relevant bit.
One idea I've always wanted to try out if I had the knowledge and time is creating a text editor in Racket that effectively worked like Emacs, but instead of elisp you leveraged the language creation features of Racket. So your init.el could be #lang Python and then you would configure it using Python, or #lang Java or even #lang elisp. Of course all of those languages are just being translated back into Racket but that's not the point. The idea would be that you could customize the editor using the syntax you preferred.
There are definitely some cons to this approach. But the goals would be accessibility and customizability for the end user especially people without a programming background.
Oh and you could choose Emacs or Vim keybinding and all editor functionality would be supported using either.
There are definitely some cons to this approach. But the goals would be accessibility and customizability for the end user especially people without a programming background.
Oh and you could choose Emacs or Vim keybinding and all editor functionality would be supported using either.
The big advantage of eLisp is it inherited the capability of changing a running program while it is running from earlier lisps. Schemes, including Racket, generally can't do that.
So with eLisp, it's natural to allow editing config.el and reloading without restarting Emacs. It's possible to do in languages outside the Common Lisp branch of the tree of life. But it's a Turing tarpit. The default is changing a program requires killing the existing instance and restarting. That's fine for a distributed application because there are lots of instances. In a word processor, a single thread is a reasonable abstraction.
So with eLisp, it's natural to allow editing config.el and reloading without restarting Emacs. It's possible to do in languages outside the Common Lisp branch of the tree of life. But it's a Turing tarpit. The default is changing a program requires killing the existing instance and restarting. That's fine for a distributed application because there are lots of instances. In a word processor, a single thread is a reasonable abstraction.
Lots of schemes do let you change running programs and elisp doesn’t support the various crazy CLOS things for dealing with instances of classes since redefined.
If scheme where so different from elisp, no one would have bothered trying to make guilemacs yet here we are.
If scheme where so different from elisp, no one would have bothered trying to make guilemacs yet here we are.
I think this was sort of the idea of emacs-on-guile, guile supports elisp, but also supports scheme and there are other languages availble too like python[0] and lua [1]
[0]https://gitlab.com/python-on-guile/python-on-guile/ [1]https://gitlab.com/NalaGinrut/guile-lua-rebirth
[0]https://gitlab.com/python-on-guile/python-on-guile/ [1]https://gitlab.com/NalaGinrut/guile-lua-rebirth
This is a really great idea, IMO. I don't know Racket very well but I'd be very willing to learn just for this project. You should get an interest check going on Reddit or wherever Racket users frequent most.
That's my dream! Do you know of any existing efforts towards it? I don't know much about Racket, how would #lang Python thing work (i.e. in terms of calling foreign functions etc)?
You could probably use Edwin[1][2] as a starting point. MIT Scheme is close enough to Racket that you could probably do some automated source-to-source translations, or use "#lang sicp"[3] or "#lang r5rs"[4] within Racket.
Haven't tried it, but it would be interesting.
[1] https://www.gnu.org/software/mit-scheme/documentation/mit-sc...
[2] https://github.com/jaseemabid/mit-scheme/tree/master/src/edw...
[3] https://docs.racket-lang.org/sicp-manual/SICP_Language.html
[4] https://docs.racket-lang.org/r5rs/r5rs-mod.html
Haven't tried it, but it would be interesting.
[1] https://www.gnu.org/software/mit-scheme/documentation/mit-sc...
[2] https://github.com/jaseemabid/mit-scheme/tree/master/src/edw...
[3] https://docs.racket-lang.org/sicp-manual/SICP_Language.html
[4] https://docs.racket-lang.org/r5rs/r5rs-mod.html
As to `#lang python` interop with Racket, it's possible, but the farther a language's semantics and object model differ from Racket, the harder and less pleasant it is to build and use in practice.
In other words, you need converters between runtime values between Racket and Python when their semantics differ.
For example, Python strings are instances of Python's string class, with a bunch of methods, and you can mutate the string class at runtime.
They are very different from Racket's strings.
Then you have all the differences in core reduction semantics, how concurrency and parallelism is handled, etc, and there are a lot of differences to smooth over.
There is a project called PyonR (https://github.com/pedropramos/PyonR) that implements Python 2.7 as a Racket #lang, but it hasn't been developed for a while, and I'm not sure how interoperable it actually is. It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least. The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code.
The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways. While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc. If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's. Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!) But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package. It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.
There is a project called PyonR (https://github.com/pedropramos/PyonR) that implements Python 2.7 as a Racket #lang, but it hasn't been developed for a while, and I'm not sure how interoperable it actually is. It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least. The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code.
The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways. While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc. If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's. Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!) But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package. It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.
I agree with you. In a perfect world you would be able to drop in Python code and only have to add a #lang Python at the top of it. But realistically I think it would be closer to what you were saying about creating a pythonic language.
So maybe the practical solution is to have a language that looks like Python, Java, Ocaml, etc. I'm not sure how many #langs you would need to make the majority of programmers feel comfortable but I think even implementing a few would be a huge step up in accessibility than what we currently have.
So maybe the practical solution is to have a language that looks like Python, Java, Ocaml, etc. I'm not sure how many #langs you would need to make the majority of programmers feel comfortable but I think even implementing a few would be a huge step up in accessibility than what we currently have.
I intend to write at least a small version of this.
There are a couple of existing “Emacs-in-Racket” projects which I may borrow code or ideas from.
The older one is https://github.com/tonyg/rmacs, which runs but is not in a state where it's really usable for anything, and there is a newer https://github.com/soegaard/remacs which I have never gotten to run on a Linux system.
Essentially my plan is to make an Emacs-like editor with a line-editor interface for my embedded-in-Racket shell, Rash (https://rash-lang.org). Of course, I will also make a TUI interface, like terminal Emacs, and while I probably won't write it myself, I would leave it open to have a GUI interface as well, and generally be embeddable in arbitrary Racket programs that need an editor component. While I don't have the time or will to really make something that could compete with Emacs as a general-purpose editor, or seriously try to implement a `#lang elisp` to give Emacs compatability, I think building an Emacs-like editor in Racket with an actual function that people will use (better line editing for Racket, Rash, other Racket languages) could give people enough reason to hack on it themselves that it could grow and be useful at least as a line editor.
Additionally, I have some ideas on plugin sandboxing I would like to try out. In other words, while I would obviously just have an interpreter with which you could run arbitrary code to modify the editor, like Emacs but with Racket code in any #lang, I also may add an API using Racket's sandboxing features so that you can run extensions with limited, explicit privileges. I want to be able to run extension code written by internet randos without auditing it, but trust that it won't steal my ssh keys and such.
That said, I'm trying to finish my PhD and I haven't even done any direct work on Rash itself for a while. My advisor says “your editor should be your first side project after graduating”, and I agree with him. So my Emacs-in-Racket may yet be eternal vaporware, and even if it isn't, advanced features that I want might not make the cut when I actually determine how much time I can commit to it. We'll see.
At any rate, even if other people do it first and better, I'm likely to make a small version of this some day just because I want to -- I've already written my own terminal emulator in Racket (which works but is slow, and I don't recommend anybody use it), and my own shell in Racket (which is awesome, and I do recommend people use it, at least for scripting, and eventually I will develop it further [contributors welcome!]), so naturally I need to make my own editor as well.
Essentially my plan is to make an Emacs-like editor with a line-editor interface for my embedded-in-Racket shell, Rash (https://rash-lang.org). Of course, I will also make a TUI interface, like terminal Emacs, and while I probably won't write it myself, I would leave it open to have a GUI interface as well, and generally be embeddable in arbitrary Racket programs that need an editor component. While I don't have the time or will to really make something that could compete with Emacs as a general-purpose editor, or seriously try to implement a `#lang elisp` to give Emacs compatability, I think building an Emacs-like editor in Racket with an actual function that people will use (better line editing for Racket, Rash, other Racket languages) could give people enough reason to hack on it themselves that it could grow and be useful at least as a line editor.
Additionally, I have some ideas on plugin sandboxing I would like to try out. In other words, while I would obviously just have an interpreter with which you could run arbitrary code to modify the editor, like Emacs but with Racket code in any #lang, I also may add an API using Racket's sandboxing features so that you can run extensions with limited, explicit privileges. I want to be able to run extension code written by internet randos without auditing it, but trust that it won't steal my ssh keys and such.
That said, I'm trying to finish my PhD and I haven't even done any direct work on Rash itself for a while. My advisor says “your editor should be your first side project after graduating”, and I agree with him. So my Emacs-in-Racket may yet be eternal vaporware, and even if it isn't, advanced features that I want might not make the cut when I actually determine how much time I can commit to it. We'll see.
At any rate, even if other people do it first and better, I'm likely to make a small version of this some day just because I want to -- I've already written my own terminal emulator in Racket (which works but is slow, and I don't recommend anybody use it), and my own shell in Racket (which is awesome, and I do recommend people use it, at least for scripting, and eventually I will develop it further [contributors welcome!]), so naturally I need to make my own editor as well.
Rash looks great. You honestly sound way more qualified to do this than I do. It makes me happy to hear that so many people have had the same idea/wanted the same thing. Racket is uniquely positioned to do this. I would definitely be interested in the GUI portion of this. Who knows maybe one day something will appear in a Racket News blog post ;)
It was a trend not long ago to use org as a form of literate config. Not sure if it is still possible, but the general idea is similar.
Emacs is amazing. I stopped using it a few years ago because I became lazy to keep my configuration and extensions up-to-date.
I was also extremely bothered by the fact that the cursor cannot live outside the current viewport and scrolling the buffer would drag the cursor as well. At the time, it seemed impossible to fix because of the way Emacs works, and the solution was something like "you are using it wrong - you need to use marks instead".
But I would love to go back to it, to be honest. VSCode is very good, but Emacs is a whole other level of automation and convenience.
I was also extremely bothered by the fact that the cursor cannot live outside the current viewport and scrolling the buffer would drag the cursor as well. At the time, it seemed impossible to fix because of the way Emacs works, and the solution was something like "you are using it wrong - you need to use marks instead".
But I would love to go back to it, to be honest. VSCode is very good, but Emacs is a whole other level of automation and convenience.
> I was also extremely bothered by the fact that the cursor cannot live outside the current viewport and scrolling the buffer would drag the cursor as well.
I can see how that would be annoying. I can also see why the developers might not have noticed. When I'm in Emacs, I tend to navigate using the keyboard, which means I scroll by moving the cursor and dragging the viewport with it.
So they probably added the ability to scroll without moving the cursor so Emacs would have the feature. But if they never really used it, they wouldn't have noticed the shortcomings in their implementation.
Sorry for the rambling, not sure if I really had a point to make ;)
I can see how that would be annoying. I can also see why the developers might not have noticed. When I'm in Emacs, I tend to navigate using the keyboard, which means I scroll by moving the cursor and dragging the viewport with it.
So they probably added the ability to scroll without moving the cursor so Emacs would have the feature. But if they never really used it, they wouldn't have noticed the shortcomings in their implementation.
Sorry for the rambling, not sure if I really had a point to make ;)
[deleted]
If well configured, mouse support can be handful when navigating code. There is a niche editor called Acme[1] that is almost "mouse-only", where even Return won't put you in the next line :)
When using Emacs, my workflow was very keyboard-centric, but sometimes navigation was a pain (even with tags and whatnot).
[1]https://www.youtube.com/watch?v=dP1xVpMPn8M
When using Emacs, my workflow was very keyboard-centric, but sometimes navigation was a pain (even with tags and whatnot).
[1]https://www.youtube.com/watch?v=dP1xVpMPn8M
Oh sure, I'm not saying it's not a useful feature. Just an observation of how different usage patterns can lead to blindspots.
> Emacs is amazing. I stopped using it a few years ago because I became lazy to keep my configuration and extensions up-to-date.
> But I would love to go back to it, to be honest.
What helps me not get bogged down in versioning, is to let someone else deal with it.
For example, Debian and NixOS each package many Emacs packages. I just use their versions, and treat it like any other piece of software managed by the OS.
Alternatively you could try things like Doom, which I think handles versioning.
> But I would love to go back to it, to be honest.
What helps me not get bogged down in versioning, is to let someone else deal with it.
For example, Debian and NixOS each package many Emacs packages. I just use their versions, and treat it like any other piece of software managed by the OS.
Alternatively you could try things like Doom, which I think handles versioning.
Knee-Deep in Elisp?
not sure when it was implemented, but to keep the cursor position fixed while scrolling
(setq scroll-preserve-screen-position 1)
(setq scroll-preserve-screen-position 1)
Unfortunately, that's not what OP wants. What OP wants is that when they scroll, the position of the cursor remains at the same position in the buffer (the contents), even when that means that it leaves the currently visible screen.
What scroll-preserve-screen-position determines, is whether the point/cursor stays at the same visual position in the screen — i.e. if for instance your cursor was in the middle of the screen, it will stay in the middle when you scroll.
OP needs the currently non-existent scroll-preserve-buffer-position.
What scroll-preserve-screen-position determines, is whether the point/cursor stays at the same visual position in the screen — i.e. if for instance your cursor was in the middle of the screen, it will stay in the middle when you scroll.
OP needs the currently non-existent scroll-preserve-buffer-position.
You could just set mark when scrolling starts. Then, next cursor move jump back to mark first.
Some heuristics to make it fully behave. Multiple scroll events should not modify mark, for example. Mouse click does not jump back to mark. Etc.
Some heuristics to make it fully behave. Multiple scroll events should not modify mark, for example. Mouse click does not jump back to mark. Etc.
The lack of "scroll-preserve-buffer-position" has been a very minor pet peeve for me for multiple years, and for some reason this very simple solution just never occurred to me.
I can't believe I didn't think of this. I'm already using marks to keep track of position when I scroll, it's just all manual right now.
I'll likely mess around with some hooks in my config this weekend and see if this is actually feasible, or if it comes with caveats I'm not seeing right now. I guess it would need to account for multiple windows open into the same buffer too.
I can't believe I didn't think of this. I'm already using marks to keep track of position when I scroll, it's just all manual right now.
I'll likely mess around with some hooks in my config this weekend and see if this is actually feasible, or if it comes with caveats I'm not seeing right now. I guess it would need to account for multiple windows open into the same buffer too.
I'm convinced the edge cases will dominate this code, but the general idea seems straight forward. If you get this working, please share. Not something I think I want, per se, but I could be mistaken on seeing it work. :)
Agreed, was thinking the same.
"Instead of setting the mark in order to operate on a region, you can also use it to remember a position in the buffer (by typing C-<SPC> C-<SPC>), and later jump back there (by typing C-u C-<SPC>)." -- https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...
Sure, but then every time the user does anything that might scroll the point off the screen, he has to remember to C-<SPC> C-<SPC> first. Installing a new habit that has to activate before such a wide range of editing operations can take a lot of time, during which the user is less productive because part of his attention is devoted to installing the new habit.
You're right. In practice I usually C-/ (undo) C-g / (redo) to get back to where I was; which is something you can do after you've lost your place in the file, but it assumes to previously made some change in that location.
From C-h v
This variable was introduced, or its default value was changed, in version 22.1 of Emacs.
Probably introduced at or before Emacs version 20.1.Author mentions web browsers and extensions in the context of barriers to creating a successful malleable system.
Surely the web browser - considered in relation to web pages & technologies (HTML, Javascript etc), rather than extensions - is perhaps the most successful malleable system in history.
The core browser "functionality" has been and can be extended in an almost infinite number of ways via web "pages". You could consider his dichotomy between "foundational" features (unavailable to the user/tinkerer) and extendable features to be comparable between Emacs (C vs elisp) and the Browser (C++ [for example] vs HTML/Javascript/CSS).
I realise that to "extend" the browser by building a web page includes a great deal more friction than playing with elisp in scratch. Does this rule out the browser as a "malleable" system?
Surely the web browser - considered in relation to web pages & technologies (HTML, Javascript etc), rather than extensions - is perhaps the most successful malleable system in history.
The core browser "functionality" has been and can be extended in an almost infinite number of ways via web "pages". You could consider his dichotomy between "foundational" features (unavailable to the user/tinkerer) and extendable features to be comparable between Emacs (C vs elisp) and the Browser (C++ [for example] vs HTML/Javascript/CSS).
I realise that to "extend" the browser by building a web page includes a great deal more friction than playing with elisp in scratch. Does this rule out the browser as a "malleable" system?
You are taking the point of view of a web developer, not a web user: a web browser gives a web site's developer a lot of control over the experience of a visitor to the web site; the visitor has some control over his or her own experience, but not much. In contrast, an Emacs user has a lot of control over his or her own experience.
Simple example: Emacs is of course used to view files not written by the Emacs user. It is the sole decision of the Emacs user what size, color and thickness/thinness the text will be. In contrast, the writer of a web page decides those things, and maybe the user can modify that and maybe they cannot.
In Chrome for example, there is no simple way to increase the text size without also increasing the size of all the other elements on the page (without increasing the zoomLevel, in other words). If some of those other elements are fixed-position elements (elements that remain in the viewport no matter how much the user scrolls) that already take up a large fraction of the viewport (which happens a lot when you browse the web on a 1360-pixel-wide monitor and you have old eyes and consequently need large text), it might not be possible to increase the zoomLevel.
Simple example: Emacs is of course used to view files not written by the Emacs user. It is the sole decision of the Emacs user what size, color and thickness/thinness the text will be. In contrast, the writer of a web page decides those things, and maybe the user can modify that and maybe they cannot.
In Chrome for example, there is no simple way to increase the text size without also increasing the size of all the other elements on the page (without increasing the zoomLevel, in other words). If some of those other elements are fixed-position elements (elements that remain in the viewport no matter how much the user scrolls) that already take up a large fraction of the viewport (which happens a lot when you browse the web on a 1360-pixel-wide monitor and you have old eyes and consequently need large text), it might not be possible to increase the zoomLevel.
That's not the same thing: if the content can be modified by the content provider then it is malleable for him, not for the user; the dynamicity is entirely controlled by the site owner.
Following that logic, wouldn't be everyting that eats content to display them malleable? Image-viewers, audio&video-players, office-applications, MS Paint and Windows Notepad? They all have the core-functionality of showing something to the user which is not embedded in their source-code, while this core-functionality is part of it.
If anything, I would go for web pages as a malleable system. Because with userscripts and userstyles you can change them however you want.
If anything, I would go for web pages as a malleable system. Because with userscripts and userstyles you can change them however you want.
Emacs is malleable enough that someone implemented a whole screen reader in it.
The basic idea is that you have a library that lets you stick your own code at the beginning/end/around existing functions. So, someone did that for functions responsible for moving to the next/previous line/word/character, and they had a basic screen reader in place. In about 30 minutes.
Now, it's far more advanced, and, because of the malleability, you can "hack" information out of someone else's code if they don't provide it to you directly, which comes in very handy for such things.
As an aside, NVDA, the main screen reader for Windows at this point, is very malleable too. It's written in Python, so extensions can modify anything they wish. Amazing things have been built for it, including a whole remote access package, team-viewer style.
The basic idea is that you have a library that lets you stick your own code at the beginning/end/around existing functions. So, someone did that for functions responsible for moving to the next/previous line/word/character, and they had a basic screen reader in place. In about 30 minutes.
Now, it's far more advanced, and, because of the malleability, you can "hack" information out of someone else's code if they don't provide it to you directly, which comes in very handy for such things.
As an aside, NVDA, the main screen reader for Windows at this point, is very malleable too. It's written in Python, so extensions can modify anything they wish. Amazing things have been built for it, including a whole remote access package, team-viewer style.
(global-set-key (kbd "å") 'hippie-expand)
; Swedish "å" is useless in Finnish keyboard.
; After 40 years I finally understood I do not
; have suffer this injustice anymore. Quite logical
; because "ååå" pronounced in Gay Swedish way is an
; expression of frustation and indecisiveness.For those who are intrigued by all of this, I will mention that the built-in tutorial (Help->Read the Emacs Manual) and the intro lisp tutorial (Help->More Manuals->Introduction to Emacs Lisp) are both interactive and very readable.
I've recently decided to start writing my miscellaneous scripts in Emacs Lisp, both as a way to learn a lisp and a way to get more productive in a platform which I expect to be around until I die. And it's pretty fun.
I've recently decided to start writing my miscellaneous scripts in Emacs Lisp, both as a way to learn a lisp and a way to get more productive in a platform which I expect to be around until I die. And it's pretty fun.
I used emacs for a year and a quarter as a common lisp developer.
There was an integration into emacs from the compiler that provided support for a lot of things like jumping definitions and seeing who calls, and it was much better than the IDE IMO, in that syntax highlighting worked correctly for one, along with the ability to use multiple buffers and windows.
I used it as my main place of development while I worked at that company, and it was a pretty great pleasure minus a few issues.
I never tried using SLIME because our lisp didn't seem to automatically support having project files being loaded into it, but I probably would have had I stayed too much longer.
There was an integration into emacs from the compiler that provided support for a lot of things like jumping definitions and seeing who calls, and it was much better than the IDE IMO, in that syntax highlighting worked correctly for one, along with the ability to use multiple buffers and windows.
I used it as my main place of development while I worked at that company, and it was a pretty great pleasure minus a few issues.
I never tried using SLIME because our lisp didn't seem to automatically support having project files being loaded into it, but I probably would have had I stayed too much longer.
I use emacs for two primary use cases:
- Niche programming languages tend to have invested resources into building an emacs mode for their language. Importantly, these emacs modes tend to be maintained by core language contributors. In contrast, VSCode or other editors tend to be community contributions which are discarded over a period of months/years.
- markdown editing
- that's it (I've tried magit (too clunky/sensitive), org-mode (too much lock-in), etc
On windows i find Emacs horribly slow to render text/buffer updates.
On linux it is blazing fast.
- Niche programming languages tend to have invested resources into building an emacs mode for their language. Importantly, these emacs modes tend to be maintained by core language contributors. In contrast, VSCode or other editors tend to be community contributions which are discarded over a period of months/years.
- markdown editing
- that's it (I've tried magit (too clunky/sensitive), org-mode (too much lock-in), etc
On windows i find Emacs horribly slow to render text/buffer updates.
On linux it is blazing fast.
I find it weird that your point against org-mode is "too much lock-in".
It is a plain text format, which looks good even wherever it is viewed.
Pandoc even supports org-mode[1], which should let you convert an org-file to say markdown if you want.
It is a plain text format, which looks good even wherever it is viewed.
Pandoc even supports org-mode[1], which should let you convert an org-file to say markdown if you want.
sure, only if you stick to bare-bones org-mode. if you start using any of the "power-features" unique to org-mode you're stuck. If you restrict yourself to markdown-compatibilty, why not just write in markdown?
Wouldn't there be a stronger argument for Excel?
Excel has probably put more programming power in the hands of more people than any piece of software in history.
Excel has probably put more programming power in the hands of more people than any piece of software in history.
Malleability refers to the ability to make your tool fit your needs. Excel is not as malleable a system as Emacs, but it's indeed one of the most powerful tools out there.
I've been curious about emacs, and tried it once without know what the hell I was doing. But I've heard enough good things that I'm considering trying again.
I run i3 and vim, so I already have my tiling WM dialed in, and I'm good enough with vim that I don't struggle with using it. I have almost 0 interest in learning Lisp, beyond what I'm willing to learn to make emacs fit my use-case. I spend all day in terminal windows. I've heard about ORG-mode, and wondered if it will help me become more organized.
I killer-feature of vim that I've edited into my work-flow is that I have it auto-save a backup copy+time stamp of any file I save. It's a VCS-style hack, that 'works for me' and I think it is a better fit then git would be under the situation. (i.e. httpd.conf_2020-04-15_14:10:01)
Can a similar hack be incorporated into emacs?
I run i3 and vim, so I already have my tiling WM dialed in, and I'm good enough with vim that I don't struggle with using it. I have almost 0 interest in learning Lisp, beyond what I'm willing to learn to make emacs fit my use-case. I spend all day in terminal windows. I've heard about ORG-mode, and wondered if it will help me become more organized.
I killer-feature of vim that I've edited into my work-flow is that I have it auto-save a backup copy+time stamp of any file I save. It's a VCS-style hack, that 'works for me' and I think it is a better fit then git would be under the situation. (i.e. httpd.conf_2020-04-15_14:10:01)
Can a similar hack be incorporated into emacs?
Yes.
Though, I would say, you should really look at something like https://github.com/ryuslash/git-auto-commit-mode so your directories don't get cluttered with save files.
Though, I would say, you should really look at something like https://github.com/ryuslash/git-auto-commit-mode so your directories don't get cluttered with save files.
> Note: Geoffrey Litt’s post on browser extensions takes a different point of view, considering browser extensions as a way to modify not browsers but Web applications.
This one rang a bell. When I was working for Canonical, I built an extension to make Launchpad more comfortable for me. It still has some users (but probably needs a lot of fixing): https://chrome.google.com/webstore/detail/launchpad-tweaks/p...
This one rang a bell. When I was working for Canonical, I built an extension to make Launchpad more comfortable for me. It still has some users (but probably needs a lot of fixing): https://chrome.google.com/webstore/detail/launchpad-tweaks/p...
Emacs is an excellent malleable system because elisp is an excellent programming language.
A few important qualities that make it particularly good for this sort of environment:
1. Dynamic scope. Dynamic scope (aka special variables) means that if I locally bind the variable foo to bar, that binding is available for the dynamic extent of the let (ie a function deep in the call stack may access that binding of foo even if it was not defined lexically inside the binding). This allows passing state or options or configuration between different places which are amenable to extension, or modifying the behaviour of existing features by temporarily modifying their state. In other systems these problems may be solved by using lots of arguments, special mechanisms for passing custom parameters around, or well defined protocols to extensions with their own state. In those alternatives the fallback is either to impossibility or to storing state in poorly managed global variables. Elisp handles that “local global” state better and eg makes sure it correctly deals with multiple bindings or stack unwindings. One example usage would be for some custom comment syntax. You can just (locally) bind custom values to the variables which define the comment syntax and then call the usual comment function.
2. Hooks are very natural data structures which extensions use to make explicit extension points. Because books are lists, they may be conveniently dynamically bound (e.g. (let ((foo-hook (cons blah foo-hook))) ...)).
3. Buffer-local variables attach arbitrary state to each buffer and make it available as global variable bindings when that buffer is current. The alternative would be less begged local state, state attached to many more different things, and doing lots of requests for current-buffer.state.foo. Maybe these would make you think more about the current buffer changing but I’m not sure thinking about the problems leads to less buggy code. Buffer local variables makes writing modes easier and it makes it easy to not have to care much about the existence of other buffers while still easily being able to write code that spans multiple buffers.
4. Advice. Advice is like complex hooks except you can put it almost anywhere. You can “advise” any function with extra code to run in various places (eg before, after, around, just modifying the arguments, before but the advice is and’d with the function so if it returns nil the function isn’t called, and so on). This lets you tweak just about anything. For example I was using a build-managing mode which was not so extensible but by advising process creation I could modify its behaviour to nice the compiler executable.
5. Various save-restore macros. This could be done with first class functions but programming against the macros makes common idioms so much easier. Maybe an argument could be made that not having global state would make things a lot more manageable but I think macros like save-excursion, with-temp-buffer, and so on generally keep things under control
6. Most state is globally accessible. By this I mean most variables are special, and there is lots of important state which is global or buffer local like the point, mark, window configuration, or current buffer. This means that the current state is generally available to any extension code that runs and not kept private to some other bit of code (prohibiting extensions from getting at it). It allows most behaviour to be tweaked.
7. Recursive editing. It’s just really nice that you can pause half way through your program, have some editing done, then resume where you were: the user may live inside as well as outside the elisp call stack. Though mostly this is infrequently used.
8. Simple data structures. Because most things are text in buffers, you generally move around this data structure in a rough way (search forward for this, edit that, and so on) which is resilient to that data structure being changed/extended under you.
It’s curious that a lot of these qualities are generally considered terrible features for writing maintainable code. This is because maintainable code generally wants different things to not be able to affect one another much. If you want an extensible, malleable system, it probably makes sense to have things which are easy to modify the behaviour of from just about anywhere.
A few important qualities that make it particularly good for this sort of environment:
1. Dynamic scope. Dynamic scope (aka special variables) means that if I locally bind the variable foo to bar, that binding is available for the dynamic extent of the let (ie a function deep in the call stack may access that binding of foo even if it was not defined lexically inside the binding). This allows passing state or options or configuration between different places which are amenable to extension, or modifying the behaviour of existing features by temporarily modifying their state. In other systems these problems may be solved by using lots of arguments, special mechanisms for passing custom parameters around, or well defined protocols to extensions with their own state. In those alternatives the fallback is either to impossibility or to storing state in poorly managed global variables. Elisp handles that “local global” state better and eg makes sure it correctly deals with multiple bindings or stack unwindings. One example usage would be for some custom comment syntax. You can just (locally) bind custom values to the variables which define the comment syntax and then call the usual comment function.
2. Hooks are very natural data structures which extensions use to make explicit extension points. Because books are lists, they may be conveniently dynamically bound (e.g. (let ((foo-hook (cons blah foo-hook))) ...)).
3. Buffer-local variables attach arbitrary state to each buffer and make it available as global variable bindings when that buffer is current. The alternative would be less begged local state, state attached to many more different things, and doing lots of requests for current-buffer.state.foo. Maybe these would make you think more about the current buffer changing but I’m not sure thinking about the problems leads to less buggy code. Buffer local variables makes writing modes easier and it makes it easy to not have to care much about the existence of other buffers while still easily being able to write code that spans multiple buffers.
4. Advice. Advice is like complex hooks except you can put it almost anywhere. You can “advise” any function with extra code to run in various places (eg before, after, around, just modifying the arguments, before but the advice is and’d with the function so if it returns nil the function isn’t called, and so on). This lets you tweak just about anything. For example I was using a build-managing mode which was not so extensible but by advising process creation I could modify its behaviour to nice the compiler executable.
5. Various save-restore macros. This could be done with first class functions but programming against the macros makes common idioms so much easier. Maybe an argument could be made that not having global state would make things a lot more manageable but I think macros like save-excursion, with-temp-buffer, and so on generally keep things under control
6. Most state is globally accessible. By this I mean most variables are special, and there is lots of important state which is global or buffer local like the point, mark, window configuration, or current buffer. This means that the current state is generally available to any extension code that runs and not kept private to some other bit of code (prohibiting extensions from getting at it). It allows most behaviour to be tweaked.
7. Recursive editing. It’s just really nice that you can pause half way through your program, have some editing done, then resume where you were: the user may live inside as well as outside the elisp call stack. Though mostly this is infrequently used.
8. Simple data structures. Because most things are text in buffers, you generally move around this data structure in a rough way (search forward for this, edit that, and so on) which is resilient to that data structure being changed/extended under you.
It’s curious that a lot of these qualities are generally considered terrible features for writing maintainable code. This is because maintainable code generally wants different things to not be able to affect one another much. If you want an extensible, malleable system, it probably makes sense to have things which are easy to modify the behaviour of from just about anywhere.
Nicely written summary!
This paper was written by Richard Stallman in 1981 and delivered in the ACM Conference on Text Processing which touches on all of your points and a few more: https://www.gnu.org/software/emacs/emacs-paper.html
This paper was written by Richard Stallman in 1981 and delivered in the ACM Conference on Text Processing which touches on all of your points and a few more: https://www.gnu.org/software/emacs/emacs-paper.html
It doesn’t mention some of the newer things like hooks.
I love how much emphasis there is on efficiently updating the display. That mostly isn’t a problem these days (indeed it’s somewhat likely that emacs is slowed down by trying to compute efficient updates instead of just sending out the updates as soon as possible)
I love how much emphasis there is on efficiently updating the display. That mostly isn’t a problem these days (indeed it’s somewhat likely that emacs is slowed down by trying to compute efficient updates instead of just sending out the updates as soon as possible)
By hooks I meant advice
> Lesson #1: Provide significant out-of-the-box utility
There has been a push to move certain modes out of the core Emacs distribution and into package repos, I guess because it makes it makes them easier to maintain. Emacs comes with a Python mode, for example, and that conceivably could go to ELPA. But not everyone has access to package repos, and switching from a kitchen-sink model to a framework-for-external-repos model would make Emacs far less useful for such users.
There has been a push to move certain modes out of the core Emacs distribution and into package repos, I guess because it makes it makes them easier to maintain. Emacs comes with a Python mode, for example, and that conceivably could go to ELPA. But not everyone has access to package repos, and switching from a kitchen-sink model to a framework-for-external-repos model would make Emacs far less useful for such users.
I never understood that argument. What prevents emacs-devs from maintaining an emacs-core with all modes outsourced to ELPA, and still deliver a emacs-classic-distribution which loads packages from elpa on compiling? You can easily mark versions of the elpa-packges matching the emacs-classic-version, while developing it independant from it.
Only a tiny minority of users can't access package repos. They can download the packages at home and mail themselves in a zip file.
It's trivial to create a zip file containing the necessary files, plus a config elisp file which has the personal customizations.
It's trivial to create a zip file containing the necessary files, plus a config elisp file which has the personal customizations.
The problem with that Point of view is discoverability. It's the same issue I have with tweaking Vim to slowly provide some better ergonomics for my projecting, and has honestly been a consistent hurdle even when I was first learning computer suites like Word Processors and other office stuff.
I've never done well at navigating the initial humps of learning plugin/package ecosystems. Especially when I can't phrase what it is I'm looking for correctly, and I've grown reluctant to spend excessive amounts of time trying to dedup toolsets because it leads to pristine garage syndrome.
You have a system gleaming clean and ready to do things, but you're so exhausted getting things just so, you don't do anything with it.
It has nothing to do with the fact I like to blow away and remake systems on a regular basis, I swear. :P
I've never done well at navigating the initial humps of learning plugin/package ecosystems. Especially when I can't phrase what it is I'm looking for correctly, and I've grown reluctant to spend excessive amounts of time trying to dedup toolsets because it leads to pristine garage syndrome.
You have a system gleaming clean and ready to do things, but you're so exhausted getting things just so, you don't do anything with it.
It has nothing to do with the fact I like to blow away and remake systems on a regular basis, I swear. :P
[deleted]
> Only a tiny minority of users can't access package repos.
That sounds like a verifiable claim. Do you have any proof?
That sounds like a verifiable claim. Do you have any proof?
Only my personal experience. I never encountered a situation in my professional life where I couldn't access the net.
How is it verifiable? Is there some statistics of this?
How is it verifiable? Is there some statistics of this?
What are the main examples you have in mind of users who can use emacs but can’t install packages?
I use Emacs at work, where unapproved external packages are prohibited. If Python mode were pushed out to a repo, I would basically be forced to use another editor.
Another example might be using Emacs on a device without network access.
If we relax "can't" to include "won't", then there are casual users who might want to try Emacs but can't be bothered to set up package archives, etc. Such a user will start it up, say "What, no Python mode?", and switch to something else.
Another example might be using Emacs on a device without network access.
If we relax "can't" to include "won't", then there are casual users who might want to try Emacs but can't be bothered to set up package archives, etc. Such a user will start it up, say "What, no Python mode?", and switch to something else.
Having never worked at a company like that I'm curious how it works. Is it
- No http/https connections
- No write access to home directory
- Internal prohibition against downloading/using something which is a "software package"
?
- No http/https connections
- No write access to home directory
- Internal prohibition against downloading/using something which is a "software package"
?
Internal prohibition. Using Emacs at all requires approval. The "product owner" is not an Emacs user, so building a custom distribution to include, say, Magit, is out of the question. I am stuck using commandline Git :(
this sounds a bit crazy.
It is unfortunately common.
Any organization with high-value data has a responsibility to try not to be the next Equifax.
Programmers, sysadmins, and DB admins are excellent targets for attackers.
So, it's not actually so crazy to require that all tools be vetted by internal security teams, especially third-party extensions for Turing machines like Emacs.
I love Emacs but its architecture is a nightmare for Blue Team, and the easiest stance is definitely "no installing packages", or just "thou shalt use this IDE and no other".
Any organization with high-value data has a responsibility to try not to be the next Equifax.
Programmers, sysadmins, and DB admins are excellent targets for attackers.
So, it's not actually so crazy to require that all tools be vetted by internal security teams, especially third-party extensions for Turing machines like Emacs.
I love Emacs but its architecture is a nightmare for Blue Team, and the easiest stance is definitely "no installing packages", or just "thou shalt use this IDE and no other".
I get that, but the right approach to securing high value data is to secure the data, not try and control every aspect of the environment it lives within; that's often more security theater. Note I'm not suggesting that the right approach is "wild west", rather that any vetting process that doesn't allow for well established and widely used tools to be adopted is probably too rigid.
I didn't say the "right" stance was to ban extensions, just the "easiest".
Since humans default to lazy, I thought that clearly explained why the phenomenon happens.
Perhaps I should have been clearer that I don't think it's the ideal approach, even if I understand where it comes from.
Since humans default to lazy, I thought that clearly explained why the phenomenon happens.
Perhaps I should have been clearer that I don't think it's the ideal approach, even if I understand where it comes from.
In my experience of US corporate culture it's also unfortunately common for employees at all levels to kowtow unnecessarily to "legal" without considering whether what "legal" are saying is sensible or not.
> so building a custom distribution to include, say, Magit,
I mean, you don't need to really "build" anything, you just need to install the package:
I mean, you don't need to really "build" anything, you just need to install the package:
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
(package-initialize)
M-x package-refresh-contents
M-x package-install magit
Is there a powerful resistance to approving elisp packages that aren't default? Could you lay the groundwork with whoever maintains the list of approved packages by asking about approving certain versions of emacs packages that you use, and make your current setup much richer at the same time (e.g. by adding lsp-mode, ms-lsp, flycheck and whatever else you may be doing without now).
What is really an "external package" in emacs?
There should be nothing stopping someone just copying and pasting an entire elisp source text from a website into scratch, evaluate the buffer on the spot, and have the exact same functionality as installing the package would.
I'm not saying that retrieving an external package isn't easier, but due to emacs' nature there isn't really sort of delineation based on how the elisp got into the emacs.
There should be nothing stopping someone just copying and pasting an entire elisp source text from a website into scratch, evaluate the buffer on the spot, and have the exact same functionality as installing the package would.
I'm not saying that retrieving an external package isn't easier, but due to emacs' nature there isn't really sort of delineation based on how the elisp got into the emacs.
It's more complicated than that: Emacs packages should be thought of the same as any other language's packages. They might comprise multiple files, and it's possible that their performance will be noticeably compromised if they are not byte-compiled. Installing Emacs packages should be done with the package manager.
Probably someone on the remote machine with restricted or no internet connection and admin privileges. It happens e.g. on company or academic clusters.
It is much easier to ask admin to install emacs and use defaults than to ask to install emacs and packages (and resolve problems that may happen on the way).
It is much easier to ask admin to install emacs and use defaults than to ask to install emacs and packages (and resolve problems that may happen on the way).
I can offer one data point.
The company I'm an on-site (well, usually) contractor for, whose network I use at work, proxies web traffic over HTTP. It's encrypted at the proxy for HTTPS, but everything outbound from the internal network is effectively plain text.
Emacs doesn't allow packages to be installed over HTTP, so in order to use the package repositories, I have to use my phone as a hotspot.
The company I'm an on-site (well, usually) contractor for, whose network I use at work, proxies web traffic over HTTP. It's encrypted at the proxy for HTTPS, but everything outbound from the internal network is effectively plain text.
Emacs doesn't allow packages to be installed over HTTP, so in order to use the package repositories, I have to use my phone as a hotspot.
If you have sufficient disk space (~5GB), you can also keep an elpa-mirror on your machine.
https://github.com/d12frosted/elpa-mirror
https://github.com/d12frosted/elpa-mirror
Didn’t know about this possibility. It’s a good idea to archive it locally and update regularly (just in case something happens with internet ;). Is the same possible for melpa?
> Emacs doesn't allow packages to be installed over HTTP
Are you sure about that? I think that you can specify http as usual in the URL:
Are you sure about that? I think that you can specify http as usual in the URL:
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
I kinda hope they don't go down that path: the over-the-top, kitchen-sink-ness absurdity is what I love about Emacs. I've only been using it for a few years, so I'm still stumbling down crazy rabbit-holes (more like, giant caverns) of functionality and tools that I never knew were there - and can't believe that they'd bundle in by default.
Sure I'll probably never need most of the stuff - but it make me happy to know it's there... and is great fun to explore: especially if you're on an 18 hour flight with no wifi!
Sure I'll probably never need most of the stuff - but it make me happy to know it's there... and is great fun to explore: especially if you're on an 18 hour flight with no wifi!
what about minecraft? seems way more successful and malleable
Yep, with vanilla minecraft you can make a ton of interesting changes to the game using command blocks, redstone, etc. And then you have to consider modding, which opens up infinite possibilities.
I think that title must go to Excel.
[deleted]
Does anyone have a favorite example of the coolest thing done in Emacs / coolest, most interesting configuration?
Sure, would be nice if there was an alternative to install that didn't need a MySQL client though!
Flash forward to now: I picked up Emacs a year or so ago because of Org-mode and its promise of organizing my tasks. Gradually growing my init.el to fit with my way of thinking was my first encounter with programming with any kind of direct practical application, since (as the author mentions) a beginning user frequently pastes simple Lisp functions off StackExchange, and you can kind of puzzle out how they work with your own eyes, immediately, even if you lack significant training. It soon gave me the goal of using code that I could understand (at least somewhat) when I needed new Emacs functionality, rather than just downloading a big package off MELPA that would be far beyond my comprehension. And that was the point I started to learn Emacs Lisp.
Currently I've been working on a minor mode. Who knows how long it'll take me, but it's been a fun ride, and I credit this personal development to the lack of barriers in Emacs that the author describes.