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.
> 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.
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.
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).
> 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.
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.
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.
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.
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.
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.
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?
"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.
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.
>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.
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".
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.
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.
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.
> 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:
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."
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.
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).
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).
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.
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 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.
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.
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:
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 ?
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.
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.
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. :)
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.
> 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).
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.
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
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
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.
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.
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