Emacs Bedrock: A minimal Emacs starter kit
sr.ht
sr.ht
Treesitter is baked in for syntax, eglot is baked in for language servers (intellisense), project and tab-bar give you scoped workspaces. use-package is baked in for downloading and configuring dependencies.
Modus-themes are also built in now, so you can use modus-operandi and modus-vivendi out of the box. Two incredible themes with a lot of research invested in them.
My config is a few hundred lines of unadulterated elisp now and most of the code is around completion and fuzzy searching.
The point being, modern emacs is a lot more viable from a vanilla config now than it ever has been.
Edit: changed emacs 28 to emacs 29
This was actually the motivating factor for the creation of this framework. The creator posted this to reddit:
> Hi, author here. I created this in response to a few of my lab mates wanting to get started with Emacs. Additionally, Emacs 29 has so much awesome stuff out-of-the box (use-package, eglot, tree-sitter, minibuffer completion improvements, etc.) that I wanted to see how nice I could make Emacs using just the defaults. I failed a little bit (gotta have which-key—best package for discoverability IMO, wish it were built-in) but by and large I think this project is a success. :) I've gotten several people started by just pointing them to this repository.
Compare with Mason on Neovim which is much closer to "everything just works" (and niche treesitter modes seem to be available there long before they are available on Emacs)
> Isn't even a list of URLs for grammars
Actually there is: if you run `treesit-install-language-grammar` and answer, say, `python`, it will auto-populate with the right URL. This doesn't work with every language, (e.g. Elixir isn't on the list) but it's a start.
Again: definitely needs some more work.
Similar to evil, people will figure it out over time, producing packages similar to evil-collection, but it is again a half-assed step from emacs where I can only applaud to neovim for making right, if brave, decisions. If you have decided that TS is the future, go all-in.
It is also cool how much emacs29 supports, but the quality is often meh. Project.el is an arcane mode, which updates the cache of projects very unreliably and also what it considers a project is a bit magic. Eglot is cool, but again, as everything in emacs, has big tradeoffs - DAP is bound to lsp, which brings in something like 30 packages, including treemacs - why?
In short: I gave my custom config a good run, and the good stuff is good: vertico, marginalia, embark(!!), corfu are pretty cool packages. Elpaca is also very good, doing for emacs the same stuff lazy.nvim is doing for neovim. But once I've descended a level deeper into configuring it for non-lisp programming, I was clearly in for a huge yak shaving. Neovim is for me a better editor for programming, sorry for the rant.
Meanwhile, each new version seems to break something in my crusty old .emacs file. My latest frustration is that drag and drop stopped working after upgrading from 28 to 29.
I don't know if a starter kit is necessarily the answer, but there's something to be said for a batteries included approach.
From downsides, it won't compile with xwidgets support (webkit).
My config is pretty threadbare these days, which is a relief when I plan to rewrite it in literate format.
Sadly the two of them don't seem to mix well together (eg rust-mode works well with eglot but rust-ts-mode makes eglot ask for LSP server binary and then still does not connect).
Looks like it's early toothing problems but it's not that straightforward (at least yet).
Why can't something that is built into IDEs like Intellij be built into Emacs even after 30+ years of development?
My personal prediction, however, is this: Thanks to the advent of the static parser framework "treesitter" we will see language servers becoming obsolete in the long run. Treesitter enables an editor to load a parser backend as a plugin and on top of that provides a powerful query API to semantically analyse your code. This should be sufficient to implement all of what an external language server does already but inside the editor's process.
Code completion works out of the box for example in IntelliJ for example without needing to download and install further packages.
The tree sitter approach does sound something along in that direction, that should bode well if it works out.
Emacs has LSP client that works will all LSP servers. It's your responsibility to bring an LSP server or implement your own, not Emacs'.
(cua-mode)
that said, `cua-mode` is kinda terrible/half-assed b/c it implements a tiny fraction of what I think most people would consider "CUA". If you want a real CUA-mode use `ergoemacs`. Then Emacs will start to behave like every other GUI since the last mass extinction. It comes with a nice illustration of all the keybindings which leads to good discoverability of features. The only downside I saw was it had really slow launch times. Once you're comfortable with ELisp you can just rolled your own keybindings though
Is there some reason ergoemacs has never caught on?
"That's just like uh… your opinion man." —"The Big Lebowski", I think ;-)
I'm mostly of the opinion that vanilla Emacs has some bad opinions with regards to discoverability and ease-of-use-for-newbies, which is what this starter kit is targeting.
CUA-mode is on because without it you're gonna have newbies footgunning themselves super hard right out the gate, and that's the biggest thing I want to avoid.
If you consider this setup opinionated, then great—I'll embrace that. :) I think they're the kind of opinions that help newbies.
> ergoemacs
Are you referring to Xah Lee's stuff? Or something else? I'd love to see what you're referring to—please send me a link here or on my contact page. That said, Xah himself said at one point that `cua-mode` should be on by default,[1] so I think it's good enough for this kit.
I don't think we disagree. cua-mode is better than nothing.. but just enabling CUA feels kinda lazy bc it's easily improved
from Xah Lee himself：
There is Google, you know.
It's the biggest thing to happen to Emacs in 30 years. That is presumably why all the beardies ignore it.
I used to know 20-30 totally different editors. That all went away circa 1990 when the CUA UI swept the world.
https://en.wikipedia.org/wiki/IBM_Common_User_Access
All late-era DOS stuff, and Windows >= 3.x, Mac OS X and ~all Linux GUIs are compliant.
I refuse to learn any other editor UI. Life is too short. Comply with CUA, or die in a fire.
Clearly bearing the costs of a wrong decision - learn vim keybindings 30 years ago, and use it in every popular editor and ide, including emacs, ever since. Only half-joking.
That's sort of the point.
I learned all those editors (VMS EDT and RPED and LocoScript and Edlin and WordStar and WordPerfect and DisplayWrite and MultiMate and loads of BASIC editors, including the very strange RISC OS one, with two independent cursors) before I ever saw Vi for the first time, which was on SCO Xenix in about 1989 or so.
Vi was just another weird editor to me, a supercharged Edlin and you'd have to be mad to love Edlin.
So I learned the bare rudiments and moved on. Then a wave of standardisation happened across the industry, and I surfed it and it was great. Suddenly all mainstream editors used the same UI and it was so much easier.
Then [record scratch, fast forward] in 2014 I got a job in a Linux vendor and discovered all these rabid Vim enthusiasts in the 21st century. I was amazed. Later I got a job in a _different_ Linux vendor, where we had a significant presences of Emacs fans.
I never thought I'd meet keen Vi(m) users who weren't born yet when MS-DOS 5 got a full screen editor. I thought all that nastiness had gone away.
So, yes, there are these 2 camps who learned one set of UI, way back when, and love it: Vi users and Emacs users. I am not saying either is wrong. But there is another camp that doesn't know it's a camp: the millions of unknowing CUA users.
Emacs is meant to be the ultimate in configurability. Well configure it to look like an editor from the 1990s instead of the 1970s, and I'll try it.
But I'm not learning another new 1970s editor now, after 40 years of this stuff. Hard no.
I am not a programmer. I don't care how good it is for programmers. I write human language. I need an editor for that: Markdown, these days, mainly.
I would also agree, that vim keybindings shine for programming, less for prose where one would be all the time in insert mode anyway. Emacs, oh, readline keybindings are less supported in general, but can be found in the most unexpected places - text fields and editors in macOS, console terminals. Now, CUA - I would not even know which editor I should use it with - some amount is supported everywhere, but there is not a lot overlap between let's say windows and macOS, so I would put this idea into a box with a label "Had some clear influence on things we use, but is mostly dead".
Also, POSIX is from some 30+ years ago now. It's been replaced with the Single Unix Specification and even now there are a dozen odd certified compliant OSes, and hundreds more that could be but haven't bothered. Several Linux distros have passed, meaning that Linux is UNIX now.
POSIX/the SUS is very useful. There are more OSes that can pass now than when the commercial stuff was at its peak.
And there are de facto standards that are more use. A mate of mine jokes that the stable Linux app API is Win32 because WINE on Linux is now more compatible across more versions than any 1 distro's own packages over decades, and more compatible on more platforms than Windows itself.
But saying that, Linux itself is an ABI now, and you can successfully run Linux binaries, without Linux itself being present, on Windows, on FreeBSD, on Solaris/Illumos and I suspect on other OSes as well.
So, you are free to mock POSIX and Linux compatibility, but in real life, it's true and it is valid and it works and people pay for this. It is real and it is useful.
Similarly, stick J Random Punter in front of a text editor on Windows, macOS, or any xNix with a GUI, and they will be able to edit some text, cut and paste, and save it.
Put them in front of Vim or Emacs, and they won't.
For me, I don't give an electronic sausage how much use they are for a skilled programmer. That 2-para definition there is the acid test. Any editor that fails it can GTFO and DIAF.
This, to Vim heads and Emacs gurus, is a weird and heretical thought.
Tough. I have nearly 40 years experience in this stuff, across more OSes than just about any other living human I know could even _name_, and I absolutely stand by it.
There is a standard. Meet it, or die.
So, why again should emacs care about it? There is no heresy, vim and emacs gurus just do not care, this ship has sailed long time ago. Today across every editor I have used in past 20 years (vim, Idea, emacs, VSCode) and across 3 operating systems vim keybindings are the most consistent thing. CUA is laughable, not only does the overlap not allow to work with text effectively, it is also completely inconsistent, such as usage of cmd as modificator in macos. You may stomp with your feet about it, but people will not care more. If anything, these highly specialized editors in their niches will survive any mouse-driven fad (and let is be honest here, CUA-influenced editors are all mouse-driven). So, go emacs, go vim, you are doing everything right.
CUA was "influenced" by the old Mac OS Human Interface Guide mid/end 80s.
The influence on macOS (as it is called now) is tiny. macOS is mostly not compliant.
CUA was 100% clearly IBM's response to the Apple HIG. But it was a good one and mostly it's won. It did adopt Apple's Ctrl-X/C/V for cut/copy/paste, but that's about all.
Mac OS X isn't very compliant, no, but it's quite a bit closer than Classic MacOS was, and I find that very welcome. The menus, the hotkeys, the editing keys and so on mostly just work. All you do is use Cmd instead of Ctrl and it becomes invisible.
> Cmd instead of Ctrl
For half of the keys this won't work. For example the Function keys. Search something is Command-F. On Windows next search is F3. On the Mac it is Command-G. F3 for search does not work on the Mac. Worse, to type F3 on a Macbook keyboard I need to press World-F3.
My personal favorite would be to have a modern clone of the Symbolics keyboard... the "keymacs" keyboard, in the version with the original Symbolics keyboard layout.
https://www.youtube.com/watch?v=Zl8CGGOrxXE
Available from https://keymacs.com .
What is the simpler choice? Choosing the defaults that are built-in already, or the defaults new users will expect?
While I used to like xemacs back in the day, neither emacs nor vim really clicked, the basics are just to alien.
This brings emacs back to the list of usable options.
This is the first time I'm hearing of digital tooling used as legacy in the actual meaning of the word. I can't really be surprised that Emacs is the one that pops up, but I'm wondering if anybody has had (or heard) similar experiences
Btw, one thing that probably all starter kits should do is disable JIT compilation warnings:
`(setq native-comp-async-report-warnings-errors 'silent)`
Maybe JIT-enabled builds aren't generally available right now, but once they are this default would scare a lot of new users right off the bat.
I generally like it but the one thing I’m really missing is the spacebar concept from spacemacs / doom. Anyone know a way to shoehorn that in? Or any tips for how to do without it?
but I think the things you want to look for, if you start from scratch, are 1. evil mode https://evil.readthedocs.io/en/latest/overview.html#installa... 2. the leader key https://github.com/noctuid/evil-guide#leader-key
these are random search results that may or may not be authoritative, but they should be a good start.
Starter kits are usually opinionated, have too much in them that I may not want, I may want to do things differently, and like was said in a sibling reply, I would also want to understand my own config better...
1. https://github.com/noctuid/general.el
2. https://github.com/gekoke/dotfiles/blob/main/modules/program...
Ok, well, then. Time to uninstall.
For what it's worth, I happened across bbatsov/prelude in 2011, not long after it started being developed, having no prior emacs experience. The notice you mentioned was one of several that nudged me to learn and use the various key combinations, so I'm grateful for the notices, but I understand that not everyone would be.
So far I like the bundling of lsp and so on, it worked nicely out of the box to bring in my Rust projects ... it's nice to have it all set up.
But there's more... opinionated stuff in here that's frustrating. C-x u for undo is wonky, and C-g does not appear to be working to abort/get out of prompts. My fingers were tripping all over the place.
I feel like by the time I'd unpeeled enough of this guy's opinions and undone all the non-standard stuff in here, I'd be best to just start over.
For me, C-x u opens a buffer for undo-tree, not sure if that's what you meant or not.
It's possible I customized for C-g and or C-x u; I haven't changed much in .emacs.d/personal recently, except for adding a few scripts.
In any case, glad you gave it another shot, but perhaps it isn't your cup of tea. It's great that Emacs is (and has long been) able to adapted to a variety of needs and preferences.
And C-g, yeah, I don't know what it was doing. It got really weird.
In general this thing seems to want to open buffers all over the place. It's... visually confusing and I kept losing cursor focus in the task I was trying to focus on.
I was in the same position as you initially and it took a week or two to get the muscle memory but it's so smooth to navigate using keys near the home row compared to arrow keys.
Not only that but, the basic forward/back char, up/down line are caveman style navigation. Obviously they come in useful, but emacs has a much richer set of navigation options: M-f, M-b move forward/back by words, M-}, M-{ by paragraphs etc.
Actually back then I used tcsh first because it was the one that commonly had niceties like.. arrow keys.
In shell, I use the emacs bindings for kill-buffer, incremental search, and end of line jump, etc. but arrow keys for cursor movement. I suspect most people who aren't using vi bindings are much the same.
To me the ctrl-n/ctrl-p thing is a piece of ideology, not practicality; as sibling comment pointed out, they are not really ergonomic, and really just date to the fact that various terminals did not have consistent arrow navigations at various point.
Actually I did get used to ctrl-p/ctrl-n in the context of an old MUD client I used to use (TinyFugue, actually I still use it sometimes). It used those bindings for history cycling. And the MOO client I used in emacs also used ESC-p for similar purposes, I recall.
I'm no exception, which is why I customized my editor to make the up and down arrow keys behave like they do in browsers. That means I would like to use some other pair of keys in my editor to move to the next line or previous line. Since there does not seem to be any convention for the choice of those 2 keys more entrenched than Emacs's convention of using ctrl-n and ctrl-p, that is what I use.
Like you, I am annoyed by comments that gush about how great it is for programs other than Emacs to interpret Emacs-specific keyboard shortcuts because in VSCode, the editor used by about 70% of the world's programmers, none of the Emacs-specific shortcuts work: e.g., ctrl-n / ctrl-p don't move to the next / previous line.
More seriously, I'm just the same with hjkl and vim - cool if it works for you, when I am scrolling through I don't need to be efficient (which is highly subjective anyway), I need to have it how I like it.
Dug out a quote from Guy Steele on why the key bindings in emacs got this way:
[...] not being a human-factors guy at all, I
didn't think at all about convenience for touch typists. I was
principally concerned with mnemonic value. And so that's why Meta-C and
Meta-L and Meta-U stand for capitalize and lowercase and uppercase.
My additions/removals are just a few lines now and I find the whole setup a lot more maintainable than rolling my own: https://github.com/fhd/prelude/tree/personal/personal
But yeah, all I can say is that it works for me (with a little investment), YMMV.
I've never used prelude before. I just ran it for the very first time and this is what I did to discover what to change:
C-h k <down>
Help buffer comes up for that key. It looks like it's bound to a lambda, which is actually a bit annoying as you can't jump to the definition or anything, but it's enough to see that it's in `guru-mode-map'.
Then I grepped the project for "guru" (I used C-c p s g because I figured out it was using Projectile and familiar with its default key bindings, but you could use M-x grep, M-x rgrep or just grep in whatever way you are familiar with).
I found this in the docs: https://prelude.emacsredux.com/en/latest/troubleshooting/#wa... (Note, I found and read this in emacs, in docs/troubleshooting.md, I'm just giving the web link here for convenience).
Basically just add `(setq prelude-guru nil)` to your init file.
Btw, for anyone wondering, to run these kind of starter kits "standalone", clone the repo and from within the repo run `emacs -Q --load init.el --init-directory=$(pwd)`. Otherwise it will try to use your actual init dir by default.
i couldn’t get that to work with
https://github.com/viksit/prelude/blob/master/init.el
as someone else said - need to get work done :))
I am still using „lsp-mode“ as a language server client which works well for me and it comes with „company-mode“ integration for good autocompletion:
https://emacs-lsp.github.io/lsp-mode/page/lsp-typescript/
Later that day I can paste you the relevant lines out of my init.el.
Starting with Emacs 29 you can also use the treesitter mode „typescript-ts-mode“ for better syntax highlighting an navigation.
(use-package flycheck
:diminish flycheck-mode
:init
(global-flycheck-mode))
Next we install and set up "company-mode" for simple autocompletion. Basically, it starts the (minor) company mode after starting "lsp-mode", sets up key bindings and reduces the delay to zero:
(use-package company
:after lsp-mode
:hook (lsp-mode . company-mode)
:bind
(:map company-active-map
("<tab>" . company-complete-selection))
(:map lsp-mode-map
("<tab>" . company-indent-or-complete-common))
:custom
(company-minimum-prefix-length 1)
(company-idle-delay 0.0))
(use-package web-mode
:config
;; plain HTML may also contain JS
(add-to-list 'auto-mode-alist '("\\.html?\\'" . web-mode))
;; JSX
(add-to-list 'auto-mode-alist '("\\.jsx\\'" . web-mode))
; TSX
(add-to-list 'auto-mode-alist '("\\.tsx\\'" . web-mode))
;; web-mode overrides these key strokes with "link" and "reload"
;; which I *never* needed. But I love compile mode:
:bind (:map web-mode-map
("C-c C-l" . 'compile)
("C-c C-r" . 'recompile)))
(defun gernoti/lsp-mode-setup ()
"Gernot's Emacs: My personal modifications to lsp mode."
(setq lsp-headerline-breadcrumb-segments '(path-up-to-project file symbols))
(lsp-headerline-breadcrumb-mode)
(lsp-treemacs-sync-mode 1))
;; I am still using "web-mode" for react projects. The function
;; activates lsp mode only if the file actually contains
;; javascript/typescript (IIRC it'll also work for TSX):
(defun gernoti/lsp-deferred-maybe-jsx ()
(if (string= web-mode-content-type "jsx")
(lsp-deferred)))
(use-package lsp-mode
:commands (lsp lsp-deferred)
:hook
(lsp-mode . gernoti/lsp-mode-setup)
(js-mode . lsp-deferred)
(typescript-mode . lsp-deferred)
;; We only turn lsp-mode on if web-mode runs in JSX or TSX mode.
(web-mode . gernoti/lsp-deferred-maybe-jsx)
:init
(setq lsp-keymap-prefix "C-c l") ;; Or 'C-l', 's-l'
:config
;; You want this if you want to discover all lsp mode's goodies.
;; Though I found I actually don't use many features, really.
(lsp-enable-which-key-integration t))
You definitely want the "lsp-ui" extensions for jumping around in definitions, too:
(use-package lsp-ui
:after lsp-mode
:hook (lsp-mode . lsp-ui-mode)
:custom
(lsp-ui-doc-position 'bottom)
;; remap "M-." and "M-?" to point to the nice looking lsp-ui
;; replacements
:config
(define-key lsp-ui-mode-map [remap xref-find-definitions] #'lsp-ui-peek-find-definitions)
(define-key lsp-ui-mode-map [remap xref-find-references] #'lsp-ui-peek-find-references))See, if you hate "lsp-mode" and "lsp-ui" you can go for the more minimal "eglot.el". Similarly, you can exchange "company.el" with "corfu.el" if you prefer the latter. It's all about freedom of choice. Emacs means to many people different things.
The code I pasted, however, are standard "use-package" expressions that work the same for every Emacs extension. And all of the configuration options you've got for an extension are usually well documented on the corresponding project page (at least for matured ones). And if you look closely, I haven't actually made a lot of modifications -- so the lines actually boil down to just installing five extensions.
While language ecosystems evolve so is Emacs and correspondingly my Emacs configuration. Sometimes you'll need to look into new alternatives. Especially in web development I'll probably need to switch over to "javascript-ts-mode" for JS and "typescript-ts-mode" for TS soon. For my configuration this will mean I'll remove the lines corresponding to "web-mode" and modify my language server client like this:
(use-package lsp-mode
:commands (lsp lsp-deferred)
:hook
(lsp-mode . gernoti/lsp-mode-setup)
- (js-mode . lsp-deferred)
- (typescript-mode . lsp-deferred)
- ;; We only turn lsp-mode on if web-mode runs in JSX or TSX mode.
- (web-mode . gernoti/lsp-deferred-maybe-jsx)
+ (js-ts-mode . lsp-deferred)
+ (typescript-ts-mode . lsp-deferred)
:init
(setq lsp-keymap-prefix "C-c l") ;; Or 'C-l', 's-l'
:config
;; You want this if you want to discover all lsp mode's goodies.
;; Though I found I actually don't use many features, really.
(lsp-enable-which-key-integration t))
So it's not like I have to trash all of my configuration every other week. But it certainly looks a bit obscure to someone who is not familiar with ELISP. For me learning that to some extent has certainly has paid off as I did not have to relearn a new editor every couple of years.
will check this out this week thank you!
Good, clear comments on sensible defaults. I've already copied some into my init.el. Plus I've started using early-init.el too.
Thank you!
One thing I feel is a strange one to optimize for: startup times. Typical Emacs use is to start it once when the graphical interface of the system starts, and never turn it off. What's even the point of this optimization?
My personal experience is that most of the new dev tooling is Linux/MacOS only, and maaaaybe sometimes it's ported badly to Windows.
Are people using Emacs with LSPs for Java, Python, for example? Are they solid? Would you be able to use them day to day for software engineering work?
The one thing in Emacs that does not really work for me are these fancier new completion frameworks (Vertico, Orderless etc) as the performance is abysmal. So I switched back to Helm.
I have looked at other starter kits to find leaner things, but they don't seem to bring much to seasoned Emacs users like me.
I'm tempted to try it out, but knowing the community is (righteously) Unix-fist I'm not so sure it's worth the trouble.
My life improved a lot when I switched to Doom emacs, which takes care of a lot of emacs stuff I don't know that well.
Part of Git appeal is speed, because it works locally, magit on windows take that away
I hope on Linux it is actually fast, otherwise I would not know how to explain its fame and reputation
Here's what I recall were the major pain points then:
* You need to choose between MSYS2 and "native" Windows binaries (add WSL today for more choices).
* The choice above will influence how you interact with various shells. Getting shell encoding right and filtering out escape sequences that don't render well in Emacs terminal emulator of choice was a headache.
* All interactions with filesystem are slower. If a mode depends on interaction with filesystem a lot, like Magit, you are going to have a bad time. At the time CEDET was still a thing, but on Windows it was absolutely unusable. (Very infrequently I need to look at wife's laptop which runs some more modern Windows, and that's usually because she has some problems with Git or other infra, and I installed Emacs there to make dealing with this stuff easier: Maigt is awfully slow there).
* I don't know if Tramp has any kind of support for the convoluted and bizarre Windows user permission management -- I never had enough time to figure that out. On Linux, if I need to edit files owned by root, I do C-x f /sudo::/..., but there doesn't seem to be anything like that for Windows.
* In general, you will be missing stuff that you could easily accomplish in Emacs by pressing "!" in Dired buffer -- because there's nothing / very little of useful stuff you can call on files. If you don't install emacs with other MSYS2 utilities, your search options in Dired will be bad (default Windows find), similarly bad is the find in files that normally relies on grep to work. Same situation with spellchecker which relies on an external program.
I'd still take it over something like VSCode, but I would have to invest a lot of effort into bringing it up to the possible / desired level of comfort. It's definitely not the best place to use Emacs. Luckily, today, I'm in the place where I can, for the most part, forget MS Windows exists.
1. We are on version 30. By this time emacs should have come with some better defaults. It's 2023, not 1960 people.
2. Why are 90% of emacs frameworks trying to make it into vi?? I choose emacs, if I wanted vi-ish I would have used vi from the beginning
A lot of people want the power of emacs without the RSI that so often goes with it :)
Idk, I can navigate in Emacs using native bindings, though I like vi modal editing more, it just feels more natural when working with text. Also I can't say about 90%, but in Doom Emacs you can easily switch between native and vi bindings (even on the fly, via the keyboard chord), it's not forced in any way.
(I just checked - you can disable evil mode in spacemacs too).
People were saying that when I started using it, over 20 years ago. Apparently I was supposed to be using Notepad++ or some MS program du jour which no one remembers now. I wouldn't be surprised if I keep using it for the rest of my career.
> it can take weeks of configuring
More like decades ;)
> to get it anywhere near as productive as something like VS Code or Jetbrains IDE
Nope - it's significantly more productive. At least for me - I can't speak for you, but I do seem to be much faster at processing text than any of my colleagues who are using those other editors.
All the configuring is by design. You can set up the editor to take advantage of your strengths and paper over your weaknesses.
This can only work if the editor internalizes the corresponding language. That does not scale for all languages available.
That’s exactly what the language server protocol is all about (and certainly what parsers like tree sitter are there for). Emacs can connect to those and acquire semantic analysis capabilities. The degree to which such a semantic language features will work for you will also depend strongly on the language, of course.
If you use a commercial editor it’ll jump start you for the popular languages. But, say, you wanted to program in Raku or Scheme you’ll also going to need to fiddle around.
So the Raku server has a deficiency, currently. Too bad. But in Emacs you can work around that by writing into your config file:
(remove-hook 'xref-backend-functions #'lsp--xref-backend t)
(remove-hook 'xref-backend-functions 'eglot-xref-backend t)
This will not turn off "finding references" completely because Emacs happens to have a default backend called "etags-xref-backend" based on a reverse index file. You can easily generate that in your project directory using a shell tool shipped with Emacs or even execute that automatically from inside a git commit hook. So Emacs can stand in until Raku's language server is fixed.
So ... while you would be in trouble with a commercial editor now, you can continue hacking happily thanks to Emacs' flexibility.
It's true.
The thing is, so is Unix.
And yet we use it.
So is macOS because it's a Unix™. So is Windows, it's just a newer relic (from 1993 instead of ~1973).
We don't have anything left that are not relics any more. The relics got good enough that we stopped trying.
Nicely put.
Yes, I think there is room for a lot of innovation yet in many areas: OS design, programming language design, input devices, GUIs, and much more besides.
Saying that, when implemented well, there's a lot of stuff that's pretty good.
I think one aspect that's neglected is that yes, some tech we all use is very old and legacy-inspired. But often, it's not that we use some ancient thing because it's ancient and it hasn't changed. It's because it had lots of competitors but it beat them all.
For instance, QWERTY. Yes it is very old and yes it came from typewriters.
But I own 2 computers with
ABCDEF
GHIJKL
MNOPQR
STUVWX
YZ
... layouts. There are also QWERTZ and AZERTY used by millions. Dvorak failed to its inventors' deep misery. (No, not Dvořák, although Dvorak was a descendant of Dvořák.)
There have been tonnes of others tried.
The survivors are the ones that beat out the competition.
And in some instances, the competition survives and does OK in its little niche, and that is fine, too...