Emacs: The most successful malleable system
malleable.systems
malleable.systems
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.
Posted a comment awhile back with some specific examples from my experience: https://news.ycombinator.com/item?id=20551598
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.
[0]: https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorg...
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.
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.
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).
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...
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.
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.
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
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.
For this I use the xi-editor. 20 Gb text file? No problem.
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.)
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.
Textmate-Package-Format for some time seems to serve that area, but somehow it died out.
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.
Now I can't think of a reason to switch from Neovim :)
It has always really confused me why they made LSP. It seems like the exact opposite of something a Microsoft product would do.
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.)
This is also why I still use tmux come to think about it.
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 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 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.
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).
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>
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.
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.
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.
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 :)
It's a good thing, because it is time well spend.
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.
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.]
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”.
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.
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.
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.
If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.
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.
For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.
Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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'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...
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.
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).
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.
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.
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.
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).
IntelliJ handles this project pretty much without breaking a sweat.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.)
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).
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.
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.)
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'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.
> 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 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.
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.
https://sites.google.com/site/steveyegge2/tour-de-babel
Search for "Mailman" to find the relevant bit.
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.
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.
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.
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.
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
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.
If scheme where so different from elisp, no one would have bothered trying to make guilemacs yet here we are.
[0]https://gitlab.com/python-on-guile/python-on-guile/ [1]https://gitlab.com/NalaGinrut/guile-lua-rebirth
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.
(setq scroll-preserve-screen-position 1)
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.
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.
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.
> and the solution was something like "you are using it wrong - you need to use marks instead".
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.> 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.
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 ;)
When using Emacs, my workflow was very keyboard-centric, but sometimes navigation was a pain (even with tags and whatnot).
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?
If anything, I would go for web pages as a malleable system. Because with userscripts and userstyles you can change them however you want.
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.
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.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.
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.
- 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.
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.
Excel has probably put more programming power in the hands of more people than any piece of software in history.
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?
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.
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...
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.
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
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)
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.
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.
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)
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).
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.
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.
- No http/https connections
- No write access to home directory
- Internal prohibition against downloading/using something which is a "software package"
?
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".
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.
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
It's trivial to create a zip file containing the necessary files, plus a config elisp file which has the personal customizations.
That sounds like a verifiable claim. Do you have any proof?
How is it verifiable? Is there some statistics of this?
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
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!