EmacsConf Live Now
emacsconf.org
emacsconf.org
very nice streaming setup from the team so far
https://github.com/bling/dotemacs
This is particularly useful if you appreciate the Vim (Evil) style of text editing but want to adopt Emacs as your operating system (apps) for everything.
Bailey Ling, the creator of this configuration, transitioned from Visual Studio to Vim to Emacs. He has authored several Vim/Emacs packages, including vim-airline.
Here's a video of him demonstrating Evil mode:
https://www.youtube.com/watch?v=PeVQwYUxYEgu
What makes his configuration stand out is:
He has a multitude of useful packages pre-configured. This is also why people appreciate Spacemacs and Doomemacs (but more on that later).
His codebase is incredibly easy to understand and modify.
I've declared Emacs bankruptcy several times (building from a plain config, Spacemacs, Doomemacs, cloning another high-profile user's config, etc.)
The issue with Spacemacs and Doomemacs is:
They have a massive codebase. You can, of course, just configure the layers and treat everything else as black boxes, but that doesn't truly make Emacs an extension of your own.
There's always some maintenance required to keep up with upstream, especially if you've made a lot of non-surface level changes.
Bling's dotemacs is essentially just one core-boot.el, which sets up a loop to pick up all config/.el and binding/mode/.el files.
To add some features, you simply need to add to config/ and a new binding.
To remove something you don't want, just delete a pair of files (config & binding).
I never realized that my messy config was partly due to having features and key bindings tightly coupled together (like using the use-package macro). Now that these are separated, it's much easier to modify it to my liking.
Also, I don't have to worry about syncing with upstream, since I understand what each and every file does, and I have made massive changes to it.
I have since stolen a lot of features I want from spacesemacs and other users and adapted it to my own config.
- Neovim (the most common)
- IntelliJ
- Emacs
- VS Code
I used to use emacs via spacemacs several years ago, but can’t be bothered trying to wrangle editor configs any more - I’m firmly in the Jetbrains tools camp now with the exception of note taking (Notes.app) and commit messages (neovim with committia).
I have long found my personal emacs config, so I don't have to wrangle configs any more either, but get to still use it.
But also note that the packaging system for Emacs has greatly improved in recent years, and the time spent to configure new modes is certainly orders of magnitudes less than the time spent using that mode later on.
I hit a bug in the IJ Rust support this week, and actually tried Spacemacs again for the rust-analyser plugin! The colours in the status bar didn't match one another though, and although I vaguely recall digging into that in 2015 or so, that wasn't a side quest for 2023.
It's a great situation that broadly speaking, everyone can use what they want at this point - historically (looking at you, Visual Studio), that was not the case.
Just because I'm completely used to it though, I don't use much of what makes Emacs Emacs. It's just the editor I've always used.
My experience using Emacs at work for the past 15 years has been outstanding. I find that when I join a new company, there is sometimes a bit of legwork getting Emacs working with potentially bespoke SSH, tooling, or VPN configs (for remote development), but once it works I don't touch it. I touch a lot of languages at work, including more I didn't mention above, and not having to leave Emacs to learn a new tool is a huge boon to productivity. I get all the niceties of an IDE via LSP and some other Emacs packages, including autocomplete, code navigation, Github Copilot, and more.
I don't ever tell anyone they _should_ learn Emacs at work, but once in a while someone sees me use it while screen sharing and they get interested.
i don’t compel a specific editor for my team; we’re a motley mix of whatever people work well in.
There are dozens of us in the company, but only me in my team. The most popular editor around is VSCode.
There's not a lot of extra friction to use Emacs, the build system is well integrated, the debugger just works, the VCS is weird but the mercurial bridge is pretty good, and I always preferred using it in the CLI anyway.
For the last 4 years I've been using it full time as I changed technologies and moved to a Python/Vue shop. I initially used vanilla python-mode, then elpy, and now I'm currently using LSP for Python development. Everything is setup well, I just write code, commit using Magit, and create Github PRs using Magit/Forge. For major refactors, I do fall back on using PyCharm.
For Vue I just Web-mode because I haven't found LSP to provide me anything useful (maybe code jumping, but nothing else). Maybe it has better integration with TypeScript? I'm not too sure.
My emacs setup is pretty standardized with a dotfile. I use Projectile to jump between projects, and use Eyebrowse to assign each project its own window (I usually have anything from 2-5 open at a time). The pattern I've found useful is to have the same number assigned for Eyebrowse workspace and terminal, so `Alt+n` opens my nth project in terminal and in emacs.
For the features/tickets that I'm working on, I use an org file to note down my thoughts, subtasks, blockers, and also the status (TODO/DONE/IN-PROGRESS) etc. It's synced with my org's Google Drive, while the rest of my personal org files get synced to iCloud. Any topics for 1-1 with my peers/managers also get noted and synced.
There was a time in my previous job where I was using emails for discussions, and back then I had tight integration with Mu4e too. I've dabbled with Jira/Slack modes but they're not worth the hassle.
I'm the only one using Emacs in my org, and I feel fine doing it. Pairing works fine since the driver uses their editor of choice.
I used to work on large Java projects and I used Eclipse for that because language servers were not a thing. These days I reckon I could use Emacs as long as the language server is capable enough.
I still keep eMacs open every single day though and use org mode religiously and I am not opposed to digging through a project with eMacs because the code navigation is ever so slightly preferable. I think if it was just _slightly_ more popular and there were a few more hands on the doom eMacs project it would be no contest.
I've usually been the lone Emacs user, but it's never been an issue. "Oh, we want the code to be Black-formatted and flake8-clean before commits. Here's the VSCode to make that happen." OK. That takes about 5 minutes to configure in Emacs, and now there's no way to tell that I'm using something different from my coworkers based on our commits alone.
I blogged about my annoyance with a boss who insisted that all programmers use 1) IDEs, and 2) his favorite one, because "productivity": https://honeypot.net/post/pianos/
Dude. I'm using Emacs on a Unix. This whole computer is my IDE.
They jump to the worst interpretation of bugs or comments, and reject most contributions from other people. They are also insulting when they do respond, even to people trying to work with them to their requirements or give them useful/relevant information.
That's my personal experience with pre-commit. It's a pity because otherwise the project works well.
I write Python, PHP (Laravel), Clojure, C/C++, TypeScript, and have done Scala too. Most things work well enough (not Scala) and I make an effort to not be the "emacs guy" and use standard IDEs when pairing if the other person prefers that. Most tooling I've used is editor agnostic (pre-commit hooks for formatting/linting, LSPs, etc).
In fact, using Emacs means I'm closer to the underlying tools and so have to set them up in a way that works for multiple editors instead of just relying on everyone using the same editor to enforce things like style and formatting.
- Having nearly 20 years of experience using Emacs, it's just a totally natural fit for me.
- I program primarily in Rust. I use the built-in LSP client, eglot, to communicate with rust-analyzer and have IDE features such as jump-to-def, find-refs, find-impls, auto-import, auto-format, semantic rename, etc. It works just as well as VSCode/Codium (which I tried for about a week to make sure I wasn't missing out; I wasn't.) I also do the odd shell script, Python script, YAML config, Dockerfile, etc. for which Emacs is also well-suited.
- As far as I know, I'm the only person in the company using Emacs. There's a few vim/neovim users, but the vast majority of people are using VSCode. Having paired with many, I don't think that I'm slower for using Emacs; in fact, I think that I am in many cases faster because I am so familiar with the text operations that I don't even think about them, I just do them.
- Overall, I don't see any reason for me to switch away from Emacs at the moment, especially since LSP really blurred the distinction between "text editor" and "IDE".
- I typically don't recommend that programmers try Emacs if they're not already familiar with it. Partly because I don't want them to ask me questions, but mostly because their natural tendency is to try and reproduce their VSCode/JetBrains/Visual Studio workflow. This usually causes frustration, because the way to use Emacs effectively is different from the way to use a product like VSCode that aims to have a good out-of-the-box experience.
I am one of a handful that use Emacs at work, and often people are surprised at what I can do that they can't do with whatever they are doing. For example, I have all my Jira tickets in a org file and can update in bulk, create, and assign tickets all from a simple file in a few key strokes.
I am responsible for writing c++, go, python, C#. On top of that I have syntax hi lighting for all the major formats such as yaml, toml, json, but even have lesser known ones as hcl.
I mostly live in the terminal (vterm) within Emacs that allows me full control over things. For example, I have custom lisp functions that can extract a json blob that was just displayed in a log file and open it in a new buffer and have it formatted ready for me to inspect.
You asked bout work-flows, while emacs can do a lot of things it is not yet responsible for compiling code and many common system tools. In such used with Nix I can produce any dev environment on the fly.
Being sa singleton is not a problem mostly because once you get past the voodoo that other systems use its all the same stuff under the hood, and with Emacs you just so happen to have more control of those systems when something goes wrong.
I got tired of switching editors for different languages (PyCharm was too slow for JSX code) and decided to invest in getting Emacs to behave like a decent editor. That took a while :)
I've programmed in Python, Clojure, Nim, Cython, JS, JSX, and a host of other languages. LSP support is getting REALLY good with three strong contenders: the minimal eglot that is in Emacs core, lsp-mode which is the most complete solution, and lsp-bridge that is super fast.
The single thing I love about Emacs is that everything is text. I can do a project-wide search (find-file-in-project), turn off read-only mode, use delete-non-matching-lines to remove stuff I don't want, turn on read-only mode and peruse the remaining matches. Then I can turn on wgrep-ag mode in the search results buffer, search and replace changes, and commit them to all the files. It's a powerful concept.
We are not a single-editor shop, we have Vim, PyCharm, Sublime, etc.
Extra compatibility is just a package-install away, and the ecosystem is thriving. My must-have utilities are expand-region, iedit, multiple-cursors, whole-line-or-region, pdf-tools, try, find-file-in-project, helm-ag, rg, undo-fu, and the list goes on :)
It has great workflows for compilation, buffer (file) switching, window management, tiling, and SO much more. For me, at least, every new feature requires a lot of tinkering, but the setup has been extremely stable across Emacs versions. Emacs development is very active and in recent years has been going in a great direction.
A great book to get excited about Emacs is https://www.masteringemacs.org/. Oh, let's share configs too, here's mine: https://github.com/runekaagaard/dotfiles/blob/main/.emacs.d/... :)
I do use a Perforce minor mode to simplify checking files out and examining file history.
I have a helper function to paste image from clipboard into org document (save as timestamped png file somewhere sensible document-relative, insert link into document), so it's somewhere safe and I can add per-image notes and so on. I do this when I'm building up sets of screen grabs to later paste into Teams/Jira/Confluence/Slack and the like.
That's about it. Main remaining annoyance that I'd like to fix is a way of exporting an org section as Markdown, so I can paste anything interesting into Slack and have the formatting come out sensible.
For programming, professionally I've never used it all that much. It's much simpler all round to use whatever the rest of the team is using, which these days typically means Visual Studio or Visual Studio Code, and both are workable. I get enough value out of the zero-effort code browsing/code completion/integrated debugger/etc. that I don't mind dealing with the not-quite-as-nice editing experience and ropey UI. I can always (and often do) load a file into Emacs if I have some specific editing task I'd like to do.
(In the past I have used it a bit for working with stuff like MEL/MaxScript and proprietary/in-house stuff that's generally poorly supported by text editors. Not too hard to cobble together something workable in Emacs. I haven't had to do this recently though.)
I also use it to write literate documentation, including glossary terms, drawings, and code. These get stored in a repo along with HTML exports.
My general experience? It's the best software I've ever used. Hands down, bar none. It has the best documentation and the best documentation system. The community is fantastic. Literal greybeards to guide and inspire you, lots of new people to share excitement with, and plenty of interesting people the world over in-between. And, most important, is Freedom. The software respects me. I'll cherish that, and the lessons it has taught me, forever. I simply would not be who I am today without having learned from Emacs and it's community. Thank you!
I'm usually a singleton at work, although occasionally you meet someone else who uses Emacs.
("Languages" (in the "things you edit" sense, rather than the Turing or LLM sense) involved include python, C++, json, yaml, cmake, and arbitrary unix config files.)
I really appreciate Emacs. It’s been wonderful investing in my editor, rather than chasing trends. I’m at a point now in my career where having to use an editor other than Emacs (much like having to use an OS other than Linux or a BSD) would be grounds to refuse an offer or leave a firm.
At this point, to a certain degree Emacs is my OS. I don’t want to imagine using a computer without it.
The JavaScript interview is also really good: https://www.youtube.com/watch?v=Uo3cL4nrGOk
1. Make emacs faster
2. While I dont mind elisp that much, add support for other languages a clojure dialect that compiles to elisp (a la clojurescript) might be niceThe only problem I had was opening very large C++ files with the built-in C++ mode. Using tree-sitter has fixed that problem.
On normal operating systems you can work with magit even in pretty large repositories, and certainly in regular sized repos. Magit even has an FAQ entry about it.