Hacker News new | past | comments | ask | show | jobs | submit login
Emacs Bedrock: A minimal Emacs starter kit (sr.ht)
263 points by ashton314 on Sept 4, 2023 | hide | past | favorite | 129 comments



If you’re running emacs 29+ I posit you get less value out of a starter kit or framework than beforehand.

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


> If you’re running emacs 29+ I posit you get less value out of a starter kit or framework than beforehand.

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.


I agree! But some of those things don’t come turned on/easily set up by default, hence this starter kit using only one 3rd-party package (which-key) by default and just focused on configuring built-ins to better defaults. Stock Emacs can be so comfy these days. Just still got dumpy defaults.


treesitter is not exactly "baked in" too well at the moment. There isn't really auto-install/configuration of the grammars and as far as I can tell there isn't even a list of URLs for grammars, you have to supply those manually. There is treesit-auto which isn't quite there yet (why isn't treesit-language-source-alist populated automatically?)

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)


Yeah, the tree-sitter situation needs some work for sure. I considered adding the treesit-auto [1] package, but that's not in /(non)?GNU-ELPA/, so I left it out.

> 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.

[1]: https://github.com/renzmann/treesit-auto


Second that. In detail - IMO the decision of making of every mode a <mode>-ts variant is a very bad one and will hurt the ecosystem a lot. Now you have to remap all the major-mods and hooks and god knows what. There is also a huge mess - e.g. go-mode has nothing to do with go-ts-mode, they are completely unrelated and differ in functionality, other that one could assume based on name alone. What if the author of go-mod will decide to support ts, how should he name it, go-ts-ts-mode?

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.


Makes me want to try out a config from scratch again.. but.. need.. to.. get.. work.. done....


The --init-directory flag with 29.1 makes this easy. :)


still won't prevent me from wasting time on configuring from scratch though. I think I'll wait... LOL. Maybe.


I spent one day doing this a few months ago and I’m so happy now.


Haha. That's been my status for about 4 years. I switched to doom emacs and I keep saying, "as soon as things slow down, I'll build this from scratch..."


I use a mostly vanilla Emacs on macOS from emacsforosx.com, and I am definitely a laggard when it comes to adopting some of these modern features. I'd love to use eglot to make Emacs as smart as VS Code, but it takes some doing, so I'm still leaning on a TAGS file for navigation.

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.


On macOS try emacs-mac-port, it has many goodies comparing to emacsformacos.com: - The only Emacs that works with window managers, I use Magnet.app to resize windows using shortcuts - Integration with other macOS apps, like Tip.app[1], so selection (region) in Emacs is recognised by macOS and sent to Tip.app as stdin

From downsides, it won't compile with xwidgets support (webkit).

[1]: https://github.com/tanin47/tip


> Treesitter is baked in for syntax, eglot is baked in for language servers (intellisense),

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).


I've just moved to emacs 29 and was able to remove half of the stuff I had from my init file! Specially using eglot instead of buggy and ugly lsp-ui made a lot of difference. eglot does things the emacs way, not the vs-code ripoff that is lsp-ui, and it is much easier to setup.


Typo, I think you meant 29+. 28 doesn't have treesitter and all the goodies you mentioned.


You’re right; updated.


Thanks for the pointer to modus-theme. Vivendi-tinted is very close to what I normally run. Time to update to 29 and get rid of more customisation!


Emacs 29 is bundled with version of modus-themes that doesn't include tinted variants, you need to install them from Elpa.


Indeed! A bit annoying.


Oh wow thanks for this. Just deleted a bunch of config and packages.


tab-bar is what I've wanted for so long without knowing it!


tab-bar and project.el are fantastic. Projectile of course gives you a load more functionality, but I prefer to use out of the box options when I can. The risk is always pulling in too much and then nuking performance with bloat, or not applying fancy packages consistently (hydra for some things, not for others, for example).

My config is pretty threadbare these days, which is a relief when I plan to rewrite it in literate format.


Is there code-completion/intellisense baked-in as of Emacs 29? I think not.

Why can't something that is built into IDEs like Intellij be built into Emacs even after 30+ years of development?


You don’t understand how Emacs works. It is not supposed to be an IDE from the get-go. But there are extensions that together can turn it into one. For whatever language you program with.


I understand that, my point was that the LSP server which is required for code completion to work is not built in/packaged together with Emacs.


There are hundreds of language servers out there. Even VScode does not ship all of those. Emacs‘ LSP client „lsp-mode“ tries to download them for you if possible. For example, in case of JavaScript and TypeScript you don’t have to provide it yourself.


It is built in, and it’s better with eglot. It’s just not enabled by default because emacs isn’t used exclusively for programming.


It's not built in, eglot is only an LSP client, it requires a LSP server to function which is not included with Emacs.


See my comment above. LSP servers are complicated beasts coming with a lot of specific dependencies. It is simply impossible to ship all available language servers together with Emacs. Even VSCode does not do it. For popular languages it downloads them automatically for you. But this is exactly what "lsp-mode" (the alternative to "eglot.el") does, too [1]. If you are an expert in a specific language it also should not be too difficult for you to install and setup one yourself.

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.

[1] https://emacs-lsp.github.io/lsp-mode/page/languages/


Yes it can be set up, but my point was precisely that it(LSP servers for popular languages) is not baked into Emacs, instead making them complicated external dependencies necessary to be set up to get a basic IDE functionality of code completion working.

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.


Did you ask why does JetBrains have so many IDEs, each for different language? PyCharm, WebStorm, RubyMine, CLion, Idea.

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'.


It seems like a list of nice, but most are kinda opinionated non-essential tweaks

    (cua-mode)
Well this will have the greybeards frothing at the mouth :)

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?


> most are kinda opinionated non-essential tweaks

"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.

[1]: http://xahlee.info/emacs/emacs/modernization.html


yeah Xah Lee's ergoemacs. You should give it a try.

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:

http://xahlee.info/emacs/emacs/modernization_cua-mode.html


Ah, ok. Thanks for the link—I'll take a look at this and see if I can make it better. Thank you again!


> I'd love to see what you're referring to

There is Google, you know.

https://ergoemacs.github.io/

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.


> All late-era DOS stuff, and Windows >= 3.x, Mac OS X and ~all Linux GUIs are compliant.

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.


Oh, yes, absolutely.

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.


On the Mac its easy. Command-A selects all text. Control-a moves to the beginning of a line. Both in Apple's Textedit and in Emacs on the Mac.

> 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 .


>It's the biggest thing to happen to Emacs in 30 years. That is presumably why all the beardies ignore it.

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.


The millions of unknowing CUA users don't know or use any keybindings - they just click, scroll and select with a mouse. Arguably, it is also what made CUA the worst option - there is just no selection pressure from users, no complains is something is not working properly. Vim keybindings are so well supported compared to the share of users because vim users care.

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".


Something which is the default for basically every keyboard-driven GUI in the world isn't dead by any reckoning.


shrug same story as with POSIX - something so minimal in features and inconsistent between implementations can only work as a lowest common denominator and is without any practical meaning. Call it a victim of own success, it won't change much in practice.


I disagree.

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.


Why die, vim is thriving and in a much better shape than CUA(I wont repeat myself). And no, there is no standard for CUA, only very loose conventions which are largely inconsistent. On macos in editors and text entry fields I have a better luck with readline keybindings than with CUA and it says a lot about how much of a “standard” it is.

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.


Thanks for the ergoemacs hint. I was looking for a linux notepad++ replacement, and kate notepadqq vscode nano all have downsides.

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.


When creating a starter kit, one must choose defaults. Choosing the default emacs defaults is still a choice.

What is the simpler choice? Choosing the defaults that are built-in already, or the defaults new users will expect?


> When I started learning Emacs, my dad gave me his .emacs file

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


I would probably recommend this to new users. I don't generally recommend starter kits because it defeats the real purpose of emacs which is to hack it. But this one seems to just get over the initial barrier of it looking ugly by default which enables happy hacking more quickly. I like it! (And isn't Emacs 29 great?!)

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.


bbatsov's prelude is another nice kit to get started with and learn from:

https://github.com/bbatsov/prelude

https://prelude.emacsredux.com/en/latest/


I'm a casual emacs user for 30 years. Decided to give prelude a try after reading this... 2 minutes in: ""<down> keybinding is discouraged! Use <C-n> instead."

Ok, well, then. Time to uninstall.


I used to have my own (rather extensive) config, and switched to prelude a bit more than a year ago. I think the whole key to prelude is that it promotes useful packages, with an eye on beginners. I did change a whole bunch of things, but there's less I need to get rid of in prelude (like disabling guru-mode, what you mention - too patronising for me) than I'd have to add to vanilla Emacs, so I stuck with it. I can recommend investing some time and giving it a chance - I think most people won't be entirely happy if they just go for the out of the box behaviour.

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.


The thing is about emacs, it makes you self-sufficient. You can always change any behaviour you want to, including this.

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.


Fair enough, though that notice can easily be disabled.

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.


Lack of support for my perfectly useful arrow keys is one of the key reasons I didn't pick up vi back in 1990/1991 (when I first started Unixing) and did Emacs instead.


So I tried again and disabled guru mode (had to hunt for how and had to read the author's opinionated nonsense about the "one true way to use Emacs is by using it the way it was intended to be used " (phbtbt... nonsense... have you looked at the Space Cadet keyboard?).

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.


Maybe there's been a recent change, but I use C-g all the time every day to get out of prompts, etc.

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.


Yeah I don't want an undo-tree bound like that, because when I'm hitting undo, I just want a quick response. Default emacs behaviour is what I want.

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 feel you. I am using both cua mode and arrow keys proudly even after a decade of using emacs. Sometimes convenience is more important than keyboard efficiency. I learned to avoid (or even turn off) cua-mode where necessary (e.g. when recording key board macros).


It's very much worth taking it as true.

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.


the keys prelude pushes you towards with guru-mode are not the ones on the home row (hjkl, which is justifiable) but keys originally chosen for english words: n(ext), p(revious), f(orward), b(ack). It's mystifying, these aren't ergonomic at all, but just memnomics to help teach navigation _in the absence of clearly marked arrow keys_. So if anything, rather than being for gurus, these are keys for beginners.

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.
(from Peter Siebel's Coders At Work, quoted here https://classiccmp.org/pipermail/cctech/2015-August/008498.h...)


Plus those keys work in bash shells (anything that uses readline) and a lot of other places too.

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.


Amazingly... arrow keys also work in bash/zsh etc. shells, back to the late 80s. :-)

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.


In all the web browsers I've tried on Windows, Mac and Linux, up and down arrow scroll a little (roughly a twelfth of a page) and people spend more time in browsers than in editors.

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.


I find them incredibly ergonomic, at least compared to the arrow keys, but that's just me. My newest keyboard doesn't even have arrows keys due to how little I would use them.


It interferes with my thinking mode - right hand on the mouse and probably scrolling in docs on the other screen, left hand stroking my beard.

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.


I’ve been running this on one of my desktops in an effort to wean myself from spacemacs and doom.

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?


I don't.

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.


Didn’t know that evil has leader key support built in, this seems to be a big piece of the puzzle. Thanks!


I can vouch for general.el[1]. It's easy to use and it integrates with use-package clauses, which-key and evil states. You can look at my config[2] for examples.

1. https://github.com/noctuid/general.el

2. https://github.com/gekoke/dotfiles/blob/main/modules/program...


As another commenter pointed out, what you're probably looking for is general.el: https://github.com/noctuid/general.el


Why do you want to wean yourself off them?


not OP, so personal opinion here:

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...


Mostly to force myself into learning emacs more deeply. I’ve been using them since 2016 but I feel like I’ve hit a wall with how well I know emacs and elisp.


Yep, prelude is great. I finally have a common config across all my machines thanks to prelude, for some reason I never got everything consistent enough before.


yes But can someone please tell me how to get typescript auto complete like vscode (eg auto import, linting) that also works for jsx. running tests. oh and simple auto complete.

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 :))


For good autocompletion you‘ll need both an autocompletion framework and a language server client.

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.


First, for every IDE experience you definitely need flycheck mode:

  (use-package flycheck
    :diminish flycheck-mode
    :init
    (global-flycheck-mode))
This will underline syntax errors for you. (It'll use the language server as a backend once lsp-mode runs.)

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))
This stuff is for basic JSX/TSX support you'll need to work on React projects. "web-mode" is old-school but it still works for me quite well. Since Emacs 29 you can use "typescript-ts-mode" instead but I haven't tried it out yet:

  (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)))
The next stuff is for setting up lsp mode integrating the various language modes and company mode in a single user experience:

  (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))
At first startup it'll download and run the default js/ts language server. It seems to be working well for me.

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))


Sounds great, I love time-consumingly setting up a bunch of fragile config for a less-than-fully-functional result instead of a 1-click installation of any number of IDEs that require none of that and work better and more completely in every way


Well, Emacs is all about choice and flexibility -- not 1-click convenience. If you do not want to spend some time learning your tool, it's definitely not for you. I respect that.

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))
That's about it.

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.


Lol at the arrogance of thinking I do not take the time to learn or customize my tools while you advocate usage of a development environment that objectively lacks essential features for efficient professional programming such as functional semantic code search and navigation


Not sure why you're going so hard at OP. Just don't use the tool and move on, man :) Its totally OK if you like different tools. The acerbic response is totally unnecessary.


I am not even an emacs user yet know it has semantic code search and navigations. Sure you gottu install a couple of packages, but whats the big deal ?


omg you may be the most helpful answer i ever got on hn.

will check this out this week thank you!


I use tide-mode for Typescript/TSX and it works perfectly. All it needs is a package.json file to find the ts server.


This is really great, thank you for sharing it!

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!


Well, I haven't updated my configuration in many years... I've never heard of any of the extra packages this kit installs outside of Avy (but I use ace-jump). Some do look nice though.

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?


Because people outside the Emacs world generally launch an editor from scratch almost every time they want to edit a particular file. Even such monstrosities like VisuatStudio, MS Office and LibreOffice take just some seconds to start on my very old PC. If Emacs takes longer that's a serious turn-off for anybody who doesn't live in Emacs already.


Well... I don't think closing all Emacs windows terminates Emacs server... or does it? If not, then only the first start takes time, subsequent starts don't even execute the init file, or do they?


Totally curious: is anyone using Emacs seriously on Windows, especially with stuff like LSP?

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?


I use it for Java and Scala and it is great. The LSP support is good as long as the LSP implementation is good. I imagine it works well for most programming languages nowadays. I have Intellij Ultimate, but I have not needed or wanted to use it in ages.


I use Emacs on Windows all day long. LSP tooling works flawlessly, it would be kinda funny if it didn't given that Microsoft originally developed it for VS Code.

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 switched last year from custom configuration to Doom Emacs. I liked the framework, but over time, I think this makes me rely on external people too much and some of the stuff is too overengineered (but the good design makes it easy to tweak). I would prefer to keep things lean and I am pondering using Doom Emacs without any builtin modules as the framework itself is very good.

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 went Doom a few years back after declaring init file bankrupcy. I haven't looked back. I now just run pretty bare doom config with a couple extra modules for org-journal, etc.... I've even embraced the VIM bindings. I definitely love the leader key access to the options.


What issues you had with your custom configuration?


How does Emacs (and most addons) run on Windows?

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.


One of the lead maintainers (Eli Zaretskii) develops mostly on Windows IIRC. I think you'll be fine.


I've been using it for years on windows. Magit is much slower but still great. Some people run emacs inside wsl, and I've done that once or twice to try out unix-only modes, but they were never good enough to convince me to use them.

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.


Magit is unusably slow on windows, I never tried it on Linux, but on windows its slow to the point of making it unusable

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


I haven't used Windows since around Windows 7, and that would be probably the last time I used Emacs on Windows, so, obviously, not an up-to-day response.

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.


I am trying to learn and use Emacs, but I am not an expert. Surprisingly, Emacs 29 runs very good on Windows. I am happy with eshell, dired, trying to use emacs more for some simple tasks. I am experimenting with sharing emacs init.el configuration via local git + symlinks between 3 machines: 2 Windows and 1 Linux. Package configuration is challenging; sometimes, it works on Windows but breaks on Linux. Only nyan-cat never caused any issues ;)


I own no windows machines but afaik it should run OK on windows. Emacs is a pretty good application platform that glosses over lots of OS inconsistencies. :)


I heard that some addons (like magit and vterm) run much worse on Windows than on Unix-like. That's my main concern. Maybe it's an outdated view tho.


The big issue here is that spawning processes is (was?) much slower on windows. There’s also wsl2 where I think Emacs will work fine.


I run it inside windows terminal on WSL2 and it's smooth as butter. Despite losing out on some GUI-specific features I think I prefer it.


Still is but it works pretty well under wsl.


From what I remember magit is only slow on WSL, when interacting with a repository that is not located in the Linux subsystem i.e. laying in the windows user directory. But that might be wrong or also depend on other factors.


Magit worked perfectly fine when I was using Emacs on Windows, but nowadays I run it with gWSL on the only windows machine I own.


Wow - the at-least the landing page from vim counterparts look ages ahead.


I have two comments, that I think also apply to any other HN post on emacs:

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


> 2. Why are 90% of emacs frameworks trying to make it into vi??

A lot of people want the power of emacs without the RSI that so often goes with it :)


> 2. Why are 90% of emacs frameworks trying to make it into vi??

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).


Have you ever done any software development? One does not simply change defaults... Who cares about defaults anyway? Just change them.


Emacs is a relic, it can take weeks of configuring to get it anywhere near as productive as something like VS Code or Jetbrains IDEs. If you want to procrastinate for a few months it's the perfect tool.


> Emacs is a relic

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.


Processing text is like 10% of time and 5% of effort of software development. emacs fails at basic core IDE features like semantic location of variable declaration and usage out of the box


> semantic location of variable declaration

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.


Unfortunately for the estimated 0.18%-language-share's worth of Raku devs it does not appear that finding references is supported: https://langserver.org/#implementations-server. So not even a great solution for the ~5% of languages that don't have dedicated commercial editors that actually just work instead of requiring devs to do extensive proprietary meta-programming to achieve a half-functioning IDE facsimile


> for the ... Raku devs it does not appear that finding references

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)
if you use "lsp-mode.el" or equivalently

  (remove-hook 'xref-backend-functions 'eglot-xref-backend t)
if you happen to use "eglot.el". (There are two major language server clients available for Emacs.)

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 not happy hacking to have to think about the internal configuration of how broken my IDE's language support is. Emacs is cool for what it is but it's objectively deficient for modern professional development


You seem to have a peculiar definition of "professional development", that does some lifting there and that you are not sharing with us. There are many people here, who do use Emacs when developing in their profession.


That's why the gods of Unix created ctags.


> Emacs is a relic

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.


I agree but also feel like there is so much to improve in editor spaces but current “defaults” are just good enough. I like the keyboard example - current staggered keyboard layout is only used because we had physical typewriters that needed staggered keys because of physical constraints. But our fingers aren’t really good at going left and right, even slight movement means that you need to move your whole wrist left or right. Also keeping your wrists so close to each other is painful and not natural, definitely less comfortable than keeping them at shoulder distance. But the default is just good enough and too strong. We have split ortho keyboard but they are niche. So any revolution in editors will be stopped by the fact that too many people are comfortable enough with current default. And I’m honestly hungry for some revolution here


> And I’m honestly hungry for some revolution here

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...


It's not exactly correct to compare Emacs to an IDE. I'm not a coder (even though I write some scripts from time to time), but still Emacs is my working instrument. The main use cases are org-mode and knowledge base with org-roam. You can't get it with VS Code.


2 weeks for 20+ years of use doesn't seem to bad!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: