Emacs: The Editor for the Next Forty Years [video]
media.emacsconf.org
media.emacsconf.org
Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result.
I do not know of a better environment for multi-language programming, and I often look around and try different things to see if they match up.
I constantly add to my setup, mostly for email handling, though. I have a filtering system built in CL on top of MH-E on top of nmh.
Unless you are using org-mode, in which case updating org-mode may cause issues that require reading up on the breaking changes that were introduced between org-mode versions.
(This is meant as a heads up for newcomers using org-mode, since it's pretty popular at this point.)
When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags/cquery, installing global, configuring per-project variants, sacrificing ungulats, hail baphomet.
And for statically typed languages (I've tried Rust and Go) the lsp-mode experience is flawless and works out of the box.
However, LSP really may change that.
This one is supported - lsp-find-implementations
The other one I am not sure (I am not a go user). If it make sense it will be added to the server.
This is true, to an extent. I have not touched my current Emacs configuration in about 6 months now, but it took years of tweaking and probably hundreds of hours to get it to a state where Emacs was mostly the way I wanted it... though it'll never really be complete, as there are still a lot of things I'd like it to do that it doesn't yet but could, and there are always new things I could do that would be interesting or new, more efficient ways to do what I'm already doing.
So, overall, it has the potential to be a great time suck, and certainly was for me when I first started.
How much time it'll take for you really depends on your needs, and how much you're willing to live with the defaults that Emacs and its various modes and packages provide, and how much tweaking and customization you want to do. I needed and wanted quite a lot myself.
The most important productivity step is to launch your editor.
Unfortunately if every time you launch your editor, you get distracted by the editor itself... Well, your init.el will be well maintained. :)
Hear hear. I've been using Emacs since the late 70s when my int file was a compiled TECO library that other people also used.
Nowadays my init file is only a few dozen lines and when I log into some random machine (with no init file) most things simply work without surprising me.
It is highly customizable but it doesn't mean it must be customized.
Actually during my UNIX phase, I rather used XEmacs, as it provided much more friendly tooling than Emacs.
Nowadays Emacs really fails short from what Java and .NET environments offer out of the box, specially in graphical tooling. Including mixed language development with C++.
It is also interesting that James Gosling nowadays prefers IDEs as any UNIX editor, as stated in several interviews.
Personally I use emacs over vscode due to following reasons,
1. it does not waste CPU cycle in rendering html, we have browsers for it.
2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles,
3. and last but not the least does one thing very well which is processing and rendering text and by virtue became the most customizable editor in the world (not necessary to use customization all the time as it provides a very good out of box experience as well).
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C, not a radical improvement or a paradigm shift.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C. Simplicity of C is still far superior to Rust.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack will enable it to stay relevant with modern generation Z programmers.
IDEs also don't waste CPU cycles displaying HTML.
C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.
Also the UI while visually clunky is neat and free of distractions.
The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having to readjust to changes in look and feel, and for what?
Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.
I typically use a document editor, to you know, write documents ...
Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion.
https://thenewstack.io/a-conversation-with-the-creators-behi...
It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them.
The baseband for nearly everything I work with is text, pretty much all of Latin form (ASCII, UTF-8, ISO-8859-x etc). When it comes to having to switch context between various languages and codebases, all of many and varying levels of hygene, I've come to a conclusion that I have "a particular tool" that is more suitable than most others.
Of course, when I have the luxury of working with "more structured" code, I will use the appropriate tools, but quite often the tools don't work as effectively once the code deviates from more idiomatic structure (Eclips is notably robust in this sense - but I find it can be quite clunky).
But if I have the time to learn the tools, and the tools can make the code more "fluid" to work with then I'm all for it.
In particular "Java" (which is I presume why you're linking Gosling) lends itself to this, and I did make this point above. The language itself is so robust, and the development culture seems to value best practices well enough that making the investment to learn these tools is worthwhile (EDIT - exactly in the sense that Gosling describes in TFA).
Another example in recent times has been Apple XCode when doing IOS development. The tool-chain is far too complex for me to get a "bottom up" appreciation of how it works, and the IDE in that case works just fine for me.
But these are exceptions in my 20 years or so of experience. More often than not I've a big mess to be dealing with that demands a powerful text editor.
As a younger guy I used to spend hours trying to set up my IDE and get projects to work with my tools, but I've got kids to feed now and have other stuff to do.
EDIT - read it now. Still unclear of what point you are making, unless you are erroneously assigning me to the "real men use vi" camp ... vi (or vim) has it's place, but I wouldn't really put it in the same category as Emacs, except for the fact that maybe Emacs has a terminal mode of operation. vi to me is more like windows notepad. It's always there when I need to quickly edit a configuration file.
I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend years just understanding basic syntax, use of language and its traits.
C is like English, Hindi or simplified Chinese not very pure with flaws and ambiguity, still became lingua Franca of the majority world due to simplicity.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
https://security.googleblog.com/2019/08/adopting-arm-memory-...
https://android-developers.googleblog.com/2019/10/introducin...
https://developer.apple.com/swift/#fast
English only became the lingua Franca after the two big wars, and even then, good luck trying to make use of English in some world regions.
I recommend reading a bit about the history of lingua francas since the beginning of mankind.
"The Last Lingua Franca: English Until the Return of Babel"
https://www.amazon.com/Last-Lingua-Franca-English-Return/dp/...
No, it's just an indication of how many existing C code already exists that you have to conform to.
C code is simple in the sense that it closely matches the simple binary interfaces of the compiled code: plain symbols with simple calling conventions. Anything more complicated than this presents a seemingly insurmountable barrier to code reuse thats leads people to rewrite stuff in C.
The current situation is any code that's meant to be reused will be written in C so that every other language has access to the resulting functionality. The higher level languages either have much more complicated binary interfaces or are completely virtualized so code reuse is extremely difficult. C++ and Rust can export C interfaces but the benefits of those languages are not available to the users of the code because the interface has been reduced to C.
Explaining just how powerful that is to people who don't use Emacs is difficult. People need to sit with you for an hour or so and watch you work to truly appreciate just what that means.
I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took weeks of being slow.
I'm sure it's the same story for every emacs user - I literally never turned back. And I don't think I've touched my dotfiles in 2 years. But I get why it looks so esoteric from the outside.
so, that question is a no go because the thing has a transcendent dimension, it puts you at the heart of the storm, the center of computing where you commune with the gods of our field in perfect calm.
once you slay the dragons. best of luck!
Yes, good point, agree that would be a very positive direction.
> elisp is indeed pretty crap
Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing.
What are your biggest criticisms of elisp? Mine is basically that the naming of functions in the standard library is terrible.
Also: I'm still a bit confused about whether I should be using lexical binding (probably my fault for not thinking about it hard enough); the situation with threading is a little obscure; on the face of it threads in now exist in the elisp API, but are they not fully featured in some aspect?
When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutable state, but for the most part, it is going to introduce the kinds of bugs that people solve one of per week on a six figure salary.
I think the text buffer as a persistent vector of extended grapheme clusters is an interesting thought.
However, it is no match for modern IDEs tooling.
For such an old editor, the development scene feels incredibly alive.
I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.
- No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling.
- Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either.
- The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".
- Elisp is the worst Lisp dialect I've ever used. No packages or namespaces. No bignums. Weak regexes, using a syntax completely incompatible with any other. It's improving but very slowly. It finally got support for lexical scoping a few years ago.
Except for the generous contribution of Unicode support, it feels like a system whose technical attributes were not even terribly impressive for the 1980's. Emacs is truly greater than the sum of its parts. It has to be, because each part is worst-of-breed.
It has pros and cons.
The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.
No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.
Taking that away from Emcas would IMO be a major loss.
And as an editor it is quite slow/sluggish.
Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.
Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.
After quitting spacemacs, it was refreshing. I do not believe a "meta package" system is correct. Each individual maintainer should be able to update and release their plugins with an independent cadence. Imagine if VSCode extension releases were all gated by a single point of failure... Nobody would use it (and rightfully so).
I'd recommend just switching to the develop branch. Honestly they should just make it master.
>I learned Emacs in September, 1983
>It is now November, 2019
>...that’s over thirty six years!
>An amazingly long time.
Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it.
I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental improvement. I'm sorry but I think we are still in the Bronze Age of programming.
But some of the main productivity drivers are distributed version control systems, dependency management libraries, and sites like GitHub for sharing code and libraries.
Being able to automatically generate a project from a template, and pull in any open source library written by anyone on the planet with a single line in a config file, is amazing.
Also, remote hosting and cloud provisioning to quickly deploy any code to be used by anyone in the world with a web browser. Arguably even app stores by eliminating the need to figure out distribution and payments on your own. (The stuff maybe not everyone considers "development", but is key to the overall productivity of any software project.)
Internet and resources like stack overflow.
Back in the days, I remember the isolation.
First from the domain, we could only run part of the application or use unnaturally tiny dataset meaning that the application behaviour in prod was an abstract concept. Hell, we could not even build the app at all on large application.
Second from knowledge. If you didn't know something, you needed to pick a book and read or find someone who knew. Nowadays, with a few hours on the net, you can build enough of a working knowledge of a tech to at least know if it is worth the investment.
There were newsgroups, basically SO on comp.* subgroups.
I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.
Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.
PyCharm: Yes
VS Code: Yes
Eclipse: Yes
When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.
When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.
Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.
So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.
An efficient text editor with completion + powerful refactoring. This is the winning combination.
Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.
E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.
I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?
The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.
And that's being generous.
http://xenodium.com/trying-out-mu4e-and-offlineimap
http://xenodium.com/adding-mu4e-maildirs-extension
http://xenodium.com/trying-out-mu4e-with-mbsync
http://xenodium.com/faster-junk-mail-deletion-with-mu4e
http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e
http://xenodium.com/building-mumu4e-on-macos
http://xenodium.com/mu4e-as-macos-mail-composer
edited: formatting
Here's the diff https://github.com/xenodium/xenodium.github.io/commit/73a27f...
ps. You may want to look at the GMail/SMTP parts of this post https://github.com/redguardtoo/mastering-emacs-in-one-year-g...
While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.
I assume you've started listening to the latest episode: it was released after a long break and I guess in my mind it was geared towards existing listeners, with whom I've developed a relationship of sorts. Based on their feedback, it made sense to meander and focus on personal feelings and experience. I find it hard to balance between being insider-friendly and being attractive to new audiences. Perhaps, one of the earlier episodes could be better suited, but all of them contain personal stories.
Your comment was quite a sharp revelation tbh, it got me thinking. For now, I chose to define my project as a weird, personal journal rather than anything else, and try to further evolve the relationship with its existing listeners.
> Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system.
Is that really true? I've really enjoyed concurrency in D.
http://jordi.inversethought.com/blog/advent-of-d/#day18
How much better can it be? And yes, D's concurrency is also based around types.
Rust guarantees that a data-race is a compilation error.
D.. does not guarantee anything.. a data-race won't even give you a run-time error..
So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better.
FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).
In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter.
There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.)
This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.
[1] https://github.com/remacs/remacs
Guile now runs elisp, although there is a lot of low hanging fruit left when it comes to optimization. Guile is shaping up to become a very neat little VM, with proper threading, JIT compilation, and delimited continuations.
I think the idea of elisp running outside of Emacs, with access to all of the gory glory of Emacs libraries sounds fantastic. Imagine org-mode and a (emacs PKG org-mode) library you can use outside of Emacs with a sub 0.1s startup :)
I could appreciate it if there were legitimate architectural concerns that need to be addressed (see, for example, neovim).
But then again scripting languages don't really have these interruption features by design. I'm developing something with a scripting layer and occasionally come across accidental infinite loops myself. I wonder what e.g. Factorio or Minecraft do if a mod enters an infinite loop. If the answer is "program more carefully" and "don't use badly coded mods" then I guess it can't be helped.
Proper concurrency in elisp can't come fast enough. At least then we could have a task manager to kill hung threads with.
pkill -SIGUSR2 emacs
It's a huge endorsement of VS code.
I've been a full-time Vim user for the past decade (now NeoVim) but I've seriously considered switching, VSCode with vim mode turned on is truly fantastic, it's just not portable enough for my needs.
Not when starting up…
Important speed metrics for me are: Switching between buffers
Scrolling up/down a page (vim used to be terrible for me before i switched terminals to Kitty)
Substitutions
Search
Lousy macro support from the Vim emulator. Evil is still leaps-and-bounds above anything else (possibly Vim itself).
Flexibility of split windows. I like to view multiple files side-by-side. From my experience, Emacs and Vim have the best support for split panes; whereas VS Code and JetBrains editors have the worst.
VS Code has nothing like Magit. In my time with VS Code, I would keep Emacs open in another space for git.
In fact its not even remotely close.
In the years since first picking up Emacs, I have probably spent 100 hours or more configuring it, reconfiguring it, refactoring my configuration, and other things that wasted my time I'm not going to make the world a better place by configuring my editor. I'm going to do it by shipping code.
I'm a recovering terminal junkie. I had a problem. I was bored with my work so I wanted to challenge myself. Maybe I even enjoyed procrastinating a little.
As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.
If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".
Play is supremely important in almost any activity. Not only is there incredible work insight to be found in activity without goals, but play is fun and good for you.
From one of the books I'm currently reading (Blueprint, The evolutionary Origins of a Good Society, by Nicholas Christakis — itself a great read), I learnt of an interesting book reference: Homo Ludens: A Study of the Play-Element in Culture (1938).
The abstract sounds promising:
"[...] With cross-cultural examples from the humanities, business, and politics, Huizinga examines play in all its diverse guises—as it relates to language, law, war, knowledge, poetry, myth, philosophy, art, and much more. As he writes, “Civilization is, in its earliest phases, played. It does not come from play like a baby detaching itself from the womb: it arises in and as play, and never leaves it.” [...] Starting with Plato, Huizinga traces the contribution of “man the player” through the Middle Ages, the Renaissance, and early modern world. [...]"
[*] https://www.amazon.com/Homo-Ludens-Study-Play-Element-Cultur...
When I was younger, it felt more like play. In my late 20's it became work.
Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.
This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.
I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...
Maybe you went too far, but I think there's also a widespread problem with people not going far enough. I know smart people who have been working in the industry for over a decade who don't bother learning basic text manipulation tools because they look down on the shell and assume they're going to have to switch text editors every few years anyway. Sublime Text, BBEdit, Atom, VSCode -- you only get two or three years with each one, so there's no point learning more than delete, copy, paste, search/replace in file, jump to file, jump to symbol, and if you're really fancy, search/replace in multiple files.
But you can't get past how much of everything we work on is text, no matter how lofty the abstractions it encodes. Munging text takes an inordinate amount of our time. I have seen senior engineers spend an hour writing and debugging scripts to make changes in a big file that they could have made in minutes by using regex-replace or recording a keyboard macro in their editor. Same with basic sed and awk usage. If they can do it by hand in under ten minutes they'll do it that way; otherwise they'll file a ticket and write a script.
I have seen senior engineers painstaking picking through multi-kB json blobs adding line breaks in strategic places to make them readable. ("I used to use this one web site that reformatted JSON for you, but then it shut down, and I always felt nervous about posting internal data to random web sites anyway.") That's an extreme case, but I've seen it more than once, and it's tragic.
I agree it's hard to know ahead of time where to invest your time. One of the best engineers I ever worked with once told me, "The best thing that ever happened to me was that in undergrad I was working for a professor who had all these crazy awk scripts. I spent a whole semester using awk basically every day, even though I hated it." That impressed me —- this was a guy of very impressive theoretical background and incredible ability to design complex systems that worked in simple, reliable ways, and he was talking to me about awk? But it didn't impress me enough, because it was another five years before it sunk in that over the course of my career I had scrolled past an awful lot of simple one or two line awk solutions (on, e.g., Stack Overflow) to get to the solutions I could comprehend -- which were always much more complicated.
When considering how to spend your time, I don't think you should worry about the pits you might fall into. I think you should look at the positive possibilities, the positive possibilities, and try to achieve them. It's possible to be very productive in the terminal and in your editor or IDE without going down too many rabbit holes.
My .emacs file is 59 lines long.
Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.
(custom-set-variables
'(indent-tabs-mode nil)
'(inhibit-startup-screen t)
'(menu-bar-mode nil)
'(show-paren-mode t)
'(tool-bar-mode nil))
Where it sucks though is programming language smarts such as "intellisense" completion. Even something basic such as syntax coloring doesn't work reliably--depends on the mode implementation and most of them are buggy.
I get by in other editors such as Visual Studio and VSCode by downloading emacs emulators.
Auto code completion works pretty much flawlessly for me now.
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack.
That means when you know that Ctrl+E and Ctrl+A (`C-e' / `C-a') goes to the end or beginnings of a line in Emacs, you know it'll also work in your bash shell (or indeed any tool that uses GNU readline.)
Thanks to all those awesome people who put effort over the years.
TeXmacs is based on Guile and there is apparently already a Guile-based implementation of Emacs that is near feature complete.
Perhaps a Guile-based Emacs could somehow be embedded as an elisp-compatible interpreter "back-end" inside TeXmacs, much like how Mathematica is separated into a kernel (for computation) and a front-end (for input and rendering) that communicate with each other over a protocol called MathLink.
There is also DomTerm from Per Bothner, who perhaps coincidentally has also worked hard to produce his own Scheme-based version of Emacs (by way of the JVM).
One of the downsides of TeXmacs is the significant keystroke input latency caused by the extensive amount of page redrawing that is often required when editing "rich text." It's one of the main reasons that many still prefer latex-preview mode inside Emacs instead. Maybe latency would be less of an issue inside a graphics-aware terminal emulator like DomTerm.
Serious question: Why? Is it that hard to alt+tab? Especially, why would you want such distracting features inside your editor, while you are trying to focus and work?
The desire to never leave Emacs isn't about making it slightly easier to view e-mails next to code. It's about making it possible to use the same autocomplete, same syntax highlighting, same recursive regex search, same multicursor editing, same whatever "magle this thing and put it in your calendar" hack you wrote the other day, on anything that's made of mostly text - e-mail, chats, code, prose, process lists, directory listing.
You'd probably have to experience it to believe it, or at least see some Emacs-as-OS user live, but this unification of all computing under a sane, end-user programmable, highly ergonomic interface can boost your productivity and experience in a way that isn't seen anywhere else today, not even during regular Linux use.
incidentally, alt+tab is broken on MacOs. It cycles between programs, not windows - so if you have mutiple terminal windows open, you're screwed. You can use the alternative alt+` to cycle between windows of the same app, but that doesn't go to the least recently used window, but cycles through them in order - which is also useless when having many terminals open. Then you can pay like 15$ to get a tool like witch (just to get basic OS functionality), but that tool is slow and broken.
So on a Mac it can be pretty hard to alt+tab.
I’ll agree it’s not as immediate as a good alt+tab, but it allows you to directly choose a different window from the same application.
System Preferences -> Keyboard -> Shortcuts -> Mission Control:
Set "Move left a space" to: Control + 9
Set "Move right a space" to: Control + 0
System Preferences -> Keyboard -> Keyboard -> Modifier Keys...
Set "Caps Lock" key to: Control
I recommend Emacs to anyone who thinks it would be fun to use Lisp to configure a text editor, even if just a bit. However, that is an "if and only if".
If you choose to go beyond using emacs lisp for configuration, then I would say that emacs-lisp is an extremely fun and productive environment to work in: many programming languages give you a good standard library and package ecosystem, but with Emacs lisp you not only get that, but from the outset your project will be born into a mature and extremely fully-featured text editing environment. It's possible to create useful projects with a very good feel, with relatively few lines of code. If you don't have another excuse to use a lisp in your life, this is a very good one.
I would like it if Emacs would stop distributing itself with the ridiculous splash screen and 1990s menu icons.
If you use a 256-color-enabled terminal, the terminal version can look almost identical to the GUI version, which is very nice.
The alternatives are: run VNC or RDP to get a remote graphical environment for an IDE or use VS Code's proprietary remote extension. Neither of these get me excited for many reasons.
The trick for terminal Emacs is to run Emacs as a daemon and spawn Emacs with the `emacsclient` command.
alias e='emacsclient -nw -a "" -c "$@"'
I hate the trend to proprietary chat apps so much. After years of ventrillo and teamspeak, around 2009 I discovered mumble and was using it for years, but in the last ~1year or so everyone started switching to freaking Discord and it drives me crazy.
If Lisp have make the job from a while it should be nice to keep that solution, but, to had more flexibility for next generations.
A simple example, I works with it every days, IRC, mail, web, source code ... but on Ycombinator, I need to load an html browser to vote ... But yes I works out of Xorg ... and that is an important value that most of editor just don't understand.
Thanks for GNU Emacs, I really love it.
I'm sure it's not what I'll end on (very likely to try doom or vanilla emacs), but emacs + vim keybindings is the best of both worlds.
I think the deeper you're already in one of the ecosystems the harder it becomes to switch and the returns diminish further. In my case I'm very comfortable with Vim combined with a tiling window manager and terminal buffers, and I can't stand Emacs' control scheme. So at this point it's simply not worth it.
I found this video[0] a pretty interesting perspective from a die-hard vim user who switched.
In the end it comes down to this: I don't need Emacs. I've tried to find a feature that I really want and that's worth it to switch for(yes, I also tried org mode). But I'm comfortable with my Vim setup, I don't need an email client or web browser in the text editor.
Any way I could set such an environment up in emacs?
I don't do a lot of code editing in emacs, except for usually dotfiles and other single file operations. I do do a lot of code reading in it, though. Rip-grepping through multiple projects, opening the interesting looking files in Emacs....and then when I think i have what I want, I'll usually open the parent project in VSCode or Rider to do some editing.
Consider working primarily in an editor with LSP support (such as Emacs) and use JetBrains on the side solely for refactoring. Wean yourself off of JetBrains, as LSP improves.
Given that the author is siding with the usability of macOS with something like Emacs over using it in a GNU/Linux distro is somewhat a surprising discovery and perhaps an insight into the falsehood of having a 'consistent' Linux Desktop; even for power-users like the author.
If one has to go through a maze of settings and config files to configure Emacs shortcuts to work 'consistently' on either a GNOME or KDE desktop even for a typical developer, then I would at first question myself if such an endeavour is 'worth it' for something as arcane as Emacs.
While it was a great spectacle to watch the Vi/Emacs wars, I'm afraid that I would favour getting my work done on my MacBook, thank you very much rather than messing around with something that could be easily mistaken as the editor for the prehistoric years.
[0]: https://bitbucket.org/mituharu/emacs-mac/pull-requests/2/add...
Like, where now I use https://insomnia.rest/ to interact with APIs, when I used emacs that could/would be solved with elisp files filled with elisp functions to run those calls interactively...
Also, you can change the keybindings.
eglot is about to ship into emacs core, emasc has pdf reader for decades and remacs is a rewritten of emacs in rust, that had contributiuon from emacs core devs too.
and guile is ready to use into emacs as a alternative to elisp
https://www.emacswiki.org/emacs/CopyingWholeLines#toc3
and then just eval it to get new functionality? And the various implementations I linked to here are trivial to figure out and write yourself with even the most passing familiarity with Emacs Lisp. Even if you're a complete newcomer to the language, Emacs is self-documenting and can teach you everything from inside the editor.
That's simple by Emacs standards. :-)
If you need it simpler, write and save a keyboard macro.
Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line.
You've never had to do that?
The Emacs way of solving a workflow problem is instructing Emacs how to solve it for you. For instance, you mention:
1. Copy the line the cursor (point) is on;
2. Insert the copied line below/above point;
3. Commenting out the line you copied;
By the sound of things you do 1 and 2 with a command in Vim and the 3rd option with another command. In Emacs, I would simply program a function to do all 3 and bind it to a key.
"Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is.
As someone who has spent years using both Emacs in "Emacs mode", and vim/evil-mode, there's no question to me that the modal vim-style editing is superior to Emacs's. That's not to say that "Emacs mode" is bad: it's far superior to most editing styles. Just not evil/vim :)
Don't get me wrong: I adore Emacs, and I use it for hours and hours every day. But if it weren't for evil-mode, I would go back to Vim in a heartbeat.
So write a function for "duplicate line" and use it from now on. It's very easy to do. Just as it's easy to write function for a full edit.
A general algorithm to get one started:
1) Execute the edit you want to reuse.
2) Press C-h l, or M-x view-lossage, to see all the keypresses you made recently, along with elisp commands they executed.
3) You now know all the operations you did. Most of the time, you can recreate the edit by just wrapping them in parens, and then wrapping the whole block with (progn).
4) You're now ready to turn it into a function. Read up on 'defun and 'interactive forms. For best results, check out the documentation for each command you used during edit, via C-h f - some commands are meant for direct usage, and have a (faster, better) variant meant for use from within code; this is usually documented.
5) Tweak your function to make it more general along the dimensions you need, bind it to a key, and now you've just implemented what elsewhere would take a large plugin.
Also, it reads straight from command-history variable (another thing I didn't know about). You can preview and browse it via C-h v command-history. Or, write your own elisp operating on it (perhaps interactively, by IELM - the elisp REPL).
I say that as a Vim user that duplicates lines constantly. Vim definitely changes your coding patterns; for better or worse because it can be soo frictionless.
If you want to bind it to a key you could record that as a macro for e.g., but I find that sequence is simple enough that I don't think hard about it
The first C-k only kills to end-of-line, to capture the line ending (\n) you need another C-k. The first C-y only puts back what you killed, so that needs to be doubled also to actually change the buffer in the desired way.
Subsequent C-y commands will add more copies of the line, but I find that 99% of the time it's only a single duplicate of a line that I want.
C-S-Backspace C-yy does the same thing, btw.
I really like writing Lisp so Emacs has a simple way of doing anything I want, but it’s not for everyone.
And if it's a situation where you really need to make the user define a keyboard shortcut, don't make them do C-c followed by the actual shortcut, let them define single keystroke shortcuts to do what they want. Multiple keystroke shortcuts are so damn annoying.
Generally, the Spacemacs defaults work really well for me, and for many others. Elisp hacking was more relevant in the past. These days, with Spacemacs and other similar community efforts that deliver sane and well thought out settings, not much tinkering is required.
Or ctrl a ctrl k ctrl k ctrl y (move) ctrl y.
Is it really something that’s so common that it needs a command?
The more I use Git the more I've been committing/diffing for similar effect; but it's still much more overhead for smaller checks.
If you've got a vim setup that works for you, great.
And even with vanilla emacs it's probably a one liner in your config to get vi bindings.
Once you create a macro like that you can run it, name it, save it to your config, bind it to a key, whatever suits your workflow.
I never really thought of how much I do this manually, so I just set it up for myself right now. I'll probably rewrite it as an elisp function though.