My biggest concern about this is that now it is in Emacs, there's no easy way to contribute to it, or follow development. Previously it was on GitHub and there was zero friction to contributing other than figuring out your elisp changes. But now, I think that Issues in the github site are discouraged, and so there will be no convenient way of watching issues and feature requests raised against the project, or of following discussion of proposed patches and code review. In principle of course, these things are possible by using old issue tracking applications and following often dysfunctional/cantankerous discussions in a email list, both of whose scope is the whole of emacs.
Just thinking out loud. Github is great. It is also a proprietary, centralized, Microsoft owned service. The "problem" with Github and the enormous popularity of Github is that by not using it, an open source project is perceived to be harder to contribute to.
You don't use GitHub/GitLab/SourceHut/Codeberg by "replying to emails". You use them by:
- pushing branches to your own fork so that others can see your work while it's in draft form
- opening PRs against the main project, and writing a nice PR introduction describing the changes that you've made, their background, and motivation, drawbacks and hesitations, etc.
- participating in a feedback conversation with the maintainers and other developers with comments attached to specific lines in the code (at a specific revision), as well as attached at diff level
- having the project CI run against your branch to check that all tests pass, across a collection of different OSs and architectures. (You can also run their CI in your own fork to check it works there before even opening a PR).
- opening Issues, and discussing with other developers
- having the ability to write your text comments along with images, videos, and syntax-highlighted code fragments.
No, you can do all of that on the mailing list too.
- Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing.
- Send an email to the development mailing list, making sure to write a nice introduction describing the changes that you’ve made, their background, motivation, drawbacks, hesitations, and so on.
- participate in feedback conversations with the maintainers and other developers with comments situated next to quotations of specific lines of code from specific revisions or specific diff hunks.
- Just run “make check”. 99% of all of the code in Emacs is written in Emacs Lisp, which is platform–independent. If the tests pass on your own computer you can rest assured that they will pass on everyone else’s too.
- sending emails to ask questions and discuss them with other developers
- feel free to include any type of media in your emails, all but one participant in the mailing list can view them
> - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing.
This is the 'we have PRs at home' point of view.
It's not WRONG, but I think it does miss the point. 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer.
The project is well within it's rights to do so, but, there's a reason GitHub specifically is super popular, and it's mostly to provide structure and avoid the pain in the neck that the 'do it by email' and 'just use these different things' approach while collaborating.
Everyone already has email. Not everyone wants to sign up for yet another web service. Email _is_ the low–friction option. Emacs even has a built–in way for any user to report a bug: just run `M-x report-emacs-bug` and it will give you an email template to fill out right there in your editor. No need to even open a separate program.
Everyone has email. Yet less than 5% of developers have set up email workflows so that they're not drowning in patch/mailing list emails. Organizing one's email does take a fair amount of effort - an effort that you don't have to make using services like Github.
Configuring your email client to sort and categorize your emails for you should be easy. If it’s not easy for you, then I suggest that you are using the wrong email client. Also, I note that Github emails you every time anyone interacts with your pull request, just the same as if it were a mailing list.
I recommend a client called Gnus, which can score messages based on their content, and then sort by that score. That way messages about things you are interested in (such as your own patches, features that you care about, etc) float to the top.
Would you enlighten us what email clients are so amazingly good, because everything other than Mail.app is a traumatizing experience that I'm trying to avoid.
I really only know Gnus; it’s been a decade or two since I used anything else. I am also not really sure how to judge user–friendliness in this case. Now that I have customized it to my liking, Gnus displays exactly the information I want and has exactly the operations I want bound to keys that I like. That makes it very friendly to me, the only user I _really_ care about.
I think the design goals of Gnus were not about allowing the user to get started quickly by having the same buttons as every other email client, but instead empowering the users to extend Gnus so that it does what they want. As a result, it may take longer to learn how to use Gnus but the ceiling is much, much higher.
However, for bulk sorting of email I should actually have mentioned Sieve. It’s a standardized configuration language you can use to tell your server how to sort your mail, so that it is already done before your email client even logs in. Most IMAP servers support it, and it is pretty easy for email provide access to it.
and so on until all of your mail is sorted how you want it. It’s not a full programming language, so it cannot do everything, but it’s quite capable and pretty well standardized so you can take your filter rules with you if you change email providers. I use it even for simple rules like this so that all I need to do is paste them in when I move to a new provider. One doesn’t need to do that very often, but it only takes seconds to do instead of minutes or hours to reenter every filtering rule in a new UI.
My current email provider is Fastmail. I discovered after I signed up that most of their mail–filtering settings get turned into Sieve rules that are shown to you when you go to add your own rules. I really like this because you can see exactly how spam is handled, how your vacation responders are implemented, how email from blocked senders is discarded, etc, etc.
GitHub flow: sign up and provide a username/password, magic happens and collaboration is easy
Gnus flow: signup for mail service that lets you use a bunch of other gnu tools and client side software you have to install on every machine you want to do any kind of collaborative work from, write some code to filter your email, etc., etc. and then figure out the individual mailing list nuances (patches go here, discussion here, etc. - they're all potentially unique and beautiful snowflakes!).
I'm not trying to yuck anyone's yum, but you being the only user you care about is specifically why GitHub has become what it has. They care about all the potential users :)
I would argue that Github does not care about individual users. They treat everyone exactly the same, and not well at all. Any project relying on Github faces existential risks that simply don’t exist otherwise.
Pushing Gnus is immediately losing 99% of developers.
I've used Gnus. It's crazy powerful. But it is not simple to configure. Using notmuch + Python scripts for filtering is way easier, and even that is more than what 95% of developers are willing to do.
I can only recommend Gnus, because I don’t know any other email clients. I agree that it isn’t for everyone. In this case I recommended it because someone claimed that they couldn’t use email for development because they would end up spending all of their time managing their email. I’m confident that Gnus’ scoring feature would fix that, but at the same time I don’t really believe that the complaint was a genuine one; all email clients have some form of filtering that can do 90% of the work for the user. And most servers support Sieve, which works regardless of what client you use.
BTW, Sieve beats an ad–hoc Python script any day of the week :)
The friction there and the lack of discoverability is enough of an annoyance to me that I don't bother trying to get any of my modifications merged. I feel like plenty of other people feel the same and I'm just hoping Neovim eventually reaches feature parity because the community feels so much more inviting.
You can still do that with your fork on a forge. And all that other stuff relating to communication (commenting on specific lines of a change set, writing a nice introduction describing the changes you've made, discussing with other developers, etc.) is possible just as well with a patch-via-email workflow.
I’m trying to think: is there a package that was added to Emacs core that’s continued to have good development? Does bundling eglot mean that eglot releases are now tied to Emacs releases?
Eh, I find GNU Savannah easy enough to navigate and to track changes through it. It may not have an integrated issue tracker, but that's what the mailing list and GNU debbugs are for.
I don’t understand how this comment actually responds to any of the issues the parent raises? I think they would have made a perfectly good comment if they hadn’t spelled out the issues with the non-GitHub system but they seem to have taken the time to address many of the things you write about in advance (unless they edited that part in after your comment).
Fwiw I also think you’re missing the point about the increased barrier to entry. I suppose one could make arguments from first principles about which platform has the higher barrier to entry but actual people don’t start from first principles – they are much more likely to be familiar with GitHub (I have weaker priors for eglot contributors but I still expect potential new contributors to be more familiar with GitHub).
Interesting, I've been using "the other one": lsp-mode, and have been quite happy with the results. Will see how eglot has progressed and if I can slim my config a bit.
Same here. Anyone know if eglot is "better" than lsp-mode? Or was it just picked because of some licensing reason? I was under the impression, but I may be wrong, that lsp-mode was somehow better than eglot.
Also I wonder: if eglot is now part of Emacs, is there any incentive for the lsp-mode devs to keep working on lsp-mode?
Having alternate implementations is never a bad thing.
I spent some time to get lsp-mode working earlier this year. It took me more time to declutter the amount of stuff it put on screen than what it took to setup. In fact they have a page about this https://emacs-lsp.github.io/lsp-mode/tutorials/how-to-turn-o...
After turning off 2/3 of these, the experience has been stable and supports almost everything. I experienced clangd crashes, but lsp-mode was always able to recover. I'm not too fond of the reliance of treemacs (don't particularly like treemacs behavior in general).
I just tried briefly eglot. It worked right out of the box, and the default "output" on screen seems to match what I left enabled for lsp-mode, which seems sane to me. xref integration seems to highlight methods with cc-mode (lsp-mode doesn't).
Some lsp features are missing. For example I couldn't find an equivalent for "incoming call hierarchy". Not a show stopper.
I would need to spend some good time to see which one provides less overhead, for example.
> It took me more time to declutter the amount of stuff it put on screen than what it took to setup.
Same.
lsp-mode is great if you want to use a distraction-filled UI that doesn't integrate with anything else in the Emacs world. My first thought on trying it was "you're showing me three epitexts by default and yet none of them are running through eldoc." A large number of people seem to want that, god help them.
lsp-mode does integrate with eldoc, you just need to configure what it shows in the minibuffer, eg. to turn of the excessive clutter, set these to nil
lsp-signature-render-documentation nil ;ridiculously shows entire doc in mini
lsp-eldoc-render-all nil ; if t, shows all hover info in eldoc - too much
At least for web development I believe eglot is strictly worse. It does not support running multiple servers (e.g. tsserver and eslint-ls) (https://github.com/joaotavora/eglot/issues/976) which is supported by lsp-mode and neovim's built-in lsp client. Also, it does not have any equivalent to dap-mode which is lsp-mode only. Although worth noting dap-mode is currently useless for js (https://github.com/emacs-lsp/dap-mode/issues/369).
Why wouldn't you want the lint error to be highlighted right as you type the code?
gopls has staticcheck and govet warnings; they are quite useful as you're typing in your code. (Though sometimes a little aggressive. My favorite is highlighting an if statement as an "empty branch" before I've had time to type in any code. I'm working as fast as I can, Mr. Linter!)
> Why wouldn't you want the lint error to be highlighted right as you type the code?
eslint's flymake integration can do this without any language server commitments. LSP maybe offers some performance advantage - but IMO that says more about eslint than LSP or flymake.
> Why wouldn't you want the lint error to be highlighted right as you type the code?
Why do you think you need to involve an LSP for that?. ESLint, as most linters, can take their input from stdin. That is exactly how the eslint-flymake[0] works. Lint on buffer contents, not file on disk. No JSON RPC involved.
Presumably eglot was picked because it's by far the more emacsy LSP client. It does most of its user-visible job by integrating with other built-in packages, like Flymake, ElDoc, project.el, and most importantly xref. Integrating lsp-mode would make much less sense, since you'd be integrating an alternative universe of packages that already have built-in analogs.
Are you sure? I could have sworn my lsp-mode uses at least flymake, xref, and projectile (which I use over project.el) as well, and I don’t remember making a custom setup in that regard? Not in front of emacs right now, but very sure. Maybe that was different in the past?
I switched from eglot back to lsp-mode a while ago, but I don’t quite remember why unfortunately. I think lsp-mode “did more” or something like that, and seemed to have changed for the better.
I just remember a zillion weird popups with lsp-mode, which is all UI that isn't built in to Emacs. But also: Projectile isn't built into Emacs. Project.el is. The lsp-mode hovers are bespoke; eglot just uses ElDoc. lsp-mode wants you to use flycheck; flycheck isn't built into Emacs. lsp-mode can use xref, but it also has its own thing. lsp-mode has its own header and modeline goo. It goes on like that.
None of this is bad. These aren't critiques of lsp-mode. But they're definitely reasons why it would make sense to integrate Eglot, which prioritizes integrating with Emacs built-in libraries.
The actual critique of lsp-mode I would make is that I bounced from lsp-mode at least 3 times trying to get things working, and things would always be ok for like a couple days and then I'd lose 30 minutes to debugging and ultimately just turn it all off so I could get on with my day. I enabled Eglot once, with like 10 lines of use-package, and haven't touched it since.
Yes I had exactly the same experience, maybe 3 years ago? Installing lsp-mode resulted in an overblown UI with all sorts of gadgets; it looked like an attempt to create an "IDE experience" in Emacs, and so I ran away, used eglot for a few months, and then ended my 20-year Emacs run and switched to VSCode. (Apart from magit -- of course I do still have an Emacs instance running.) But it does sound like people are saying that lsp-mode got rid of the tasteless stuff. And since Eglot development has now moved away from GitHub to a combination of unpleasant mailing lists and unfashionable issue-tracking apps, I wonder whether it will stand a chance in the future competition.
Sorry, I’m just not sure most of that is true anymore. How long ago was your experience? I remember bouncing off lsp-mode into eglot years ago as well for similar reasons, but nowadays it just seems totally different to me.
I’ve never used anything but xref in lsp-mode, I rely on xref a lot. I wasn’t even aware that lsp-mode has, or had, something bespoke there.
I use flymake, not flycheck, I don’t think I had to configure that.
projectile is just my personal preference because I'm used to it, the manual says it integrates with either project.el or projectile.
I remember the weird popups you mention from my first lsp-mode trial. I don’t know where they’re gone, nowadays it’s just text in the buffer. (But I don’t know whether that’s ElDoc or not.)
I thought this would annoy me, since I had a custom flycheck setup for years and years prior to eglot, but I haven't noticed any differences in my workflow; it just works.
It's been an issue since before it was the latest stable version, and if the packages needed that version they should be declaring dependencies on it. And project.el is still today marked experimental, so this will probably happen again.
Version management in Emacs is hard but a) lots of the community runs Emacs versions much older than 1y old and at least few years of compatibility is (used to be?) a strong cultural norm, b) it's common to offer fallbacks to e.g. `locate-dominating-file` or similar primitive cases especially when using relatively new features, c) I don't think project.el is very good in general.
The main difference is that eglot doesn't support the complete set of LSP features yet, but those it does support are better integrated with the existing Emacs codebase and featureset. It's very much a work in progress, not aiming to be a self-contained thing like lsp-mode.
I used lsp-mode for a while and then switched to eglot. The reason was that lsp-mode has quite a lot of dependencies including helm and hydra. This can be inconvenient when you use their alternatives likes the vertico-corfu stack. I didn't want more than one extension of the same type in my configuration. eglot uses native emacs APIs for completions and tooltips. This integrates very well with vertico and corfu.
> Also I wonder: if eglot is now part of Emacs, is there any incentive for the lsp-mode devs to keep working on lsp-mode?
I'm pretty sure that some people will stick to lsp-mode. There are a few builtin extensions which I replaced with more popular external packages (eg: projectile vs project.el). So, I think the lsp-mode devs should keep at it.
lsp-mode does not depend on helm or hydra, or anything else really. There are optional packages that allow it to work better with those systems though.
Lsp mode depends on neither helm, nor hydra. I think there are some utility things that can use helm, but as far as I remember it that didn’t require that helm was set up for anything else and it has never conflicted with anything else I use.
I've used both, or rather, tried using both - lsp-mode never quite worked for me, whereas eglot is rather simple in comparison and easy to set up.
lsp-mode does 'more' (and there's also an auxiliary package, dap-mode, for debugging), but I guess is somewhat more brittle because of this. dap-mode I do use, by the way (for python mainly) - functionality-wise it's my favourite debugger available in Emacs.
eglot further has a single developer who already assigns copyright to the FSF (and developed other packages, like flymake, which are already part of emacs), so it has that going for it as well.
> Same here. Anyone know if eglot is "better" than lsp-mode? Or was it just picked because of some licensing reason?
I just checked, and both are licensed as GPLv3. I guess it could be this copyright-assignment thing?
Either way because of this move, I decided to try eglot over lsp-mode.
First thing which happens is that eglot complains its can't find a language-server for the major-mode I'm working in now... And it does *not* offer to automatically install one.
Based on this alone, I would say for OOB experience lsp-mode still seems leaps and bounds better.
> First thing which happens is that eglot complains its can't find a language-server for the major-mode I'm working in now
That was also my experience. Eglot wasn't able to use the installed vscode-json-languageserver for editing JSON instead insisted that typescript is is not installed.
lsp-mode worked worked without any configuration out of the box
If Eglot is the Emacs blessed package I'll probably start using it over lsp-mode, but seriously how do I pronounce "Eglot"? Egg Lot? Ah-lot? A-lot? Ehh-lot? Eh-glot?
I never tried Eglot simply because the name made me think it was less serious.
And major difference is eglot is slimmer compared to lsp-mode, integrates with and relies on built-ins more (xref etc) rather than inventing its own paradigm, is less cluttered by default and IME less buggier than lsp-mode cludge and now comes with emacs so doesn't need any other packages (other than language servers themselves, of course).
OTOH lsp-mode supports more than 1 active language server per buffer, generally support more features of the protocol than eglot and installs servers automatically (which may be a feature or bug depending on your system).
It comes down to utility and personal preference, but I've used lsp-mode before, found it quite buggy and cluttered, moved to eglot and have near zero LSP config now.
I wish I knew more of the LSP surface area in order to know whether a "meta LSP" was feasible. IJ has something similar with "embedded languages" that it either ships knowing about, or a user can annotate an AST section with a comment (in the outer language's syntax) indicating the inner language; SQL language support in Java is the most recent example I can think of -- both of these situations allow inspection of the inner language:
// IJ knows that "executeQuery" only accepts SQL string literals
// and the string is both highlighted and checked that "count" and "thing" are legal
statement.executeQuery("SELECT count(1) FROM thing");
// the following line designates the inner language
// language=SQL
String someSql = "WITH thing AS (SELECT whatever) SELECT * FROM thing";
With a language server, I'm guessing it would have to take the 2nd route, since I don't think language servers get into the business of knowing the semantics of the libraries against which they are completing
My (limited, from trying to hack a language server for a custom C preprocessor I have and reading a few others) experience is that language servers are not very good at true arbitrary composition but even the most monolithic ones are at least somewhat "wrappable". So a normal Java LSP wrapped in something that recognizes `executeQuery` and knows how to run additional checks on its string argument is possible. However, that thing running the additional checks on the string could not itself easily be an arbitrary SQL language server unless it was expressly designed for doing so.
The bigger issue is that you usually want some kind of semantic knowledge to cross the boundary! For example in HTML If I look for the definition of a string '#foo' in JS I want to jump to the element with ID foo; if I want to find uses of a .foo CSS selector I want to find the HTML documents with class="foo" and the JSX components with className="foo", etc. Isolating the servers misses most of the potential. You need a language-server-protocol-server protocol that can pass typed identifiers between each other; and now you've got not just programming problems but ontological problems which are the worst kind to have.
For the ontological problem, I presume you're referring to how there are so many differing ideas of how to represent ASTs (apologies for mixing languages, these URLs were just handy):
which makes it hard for ls1 to ask ls2 about "the for-of iteration variable Node" because ls2 could be using UglifyJS or ESTree or their own(!) AST nomenclature?
And all of this is made worse by (e.g.) Java1.3 versus Java19 because languages are rarely static
> egloty ... now comes with emacs so doesn't need any other packages (other than language servers themselves, of course).
One of the things I love about lsp-mode is how it automatically installs any language server I need, when I need it.
I would rather install one package and be done, than use one built-in package, and have to manually hunt, download, and manually maintain language-servers for all the different languages I'm using in my programs, on all the machines I do programming on.
If eglot wants to become the defacto standard, it will need to solve this sooner rather than later.
But I suspect RMS will be opposed to having Emacs automatically download "non-free" (not GPLed) code?
I understand where you are coming from, but in my case having anything be auto-installed is just a pain. My distro of choice is NixOS where installing stuff works fundamentally different from most other distros. When I tried it, lsp-mode just wasn't aware of it (not sure if it does now, but considering this space is vast, it is simply impossible to support every distro out there). Which means automated installation simply didn't work and I had to spend lot of time finding issues. For Emacs newbie it was a terrible pain.
Compared to that, I was done setting up Eglot + language server in 2 minutes flat, there was no config needed and it Just Worked!
The idea of my lsp mode installing servers for me fills me with dread. I'm fine with, like, `brew install whatever-server` or `go get golang.org/x/tools/gopls` or whatever. But if lsp-mode's deal for installing a new language server happens not to work on my machine, I'm in for 45 minutes of elisp debugging to figure out what the hell is going wrong. Most languages we work in have more tooling than just a language server; we don't expect Emacs to install our debugger or code generator. It's weird that we expect it to install the lsp server.
It has language servers for lots of things. Things you may not even consider languages! HTML, CSS, JSON (and all its different usages and schemas), etc.
What tooling would you install for that? What tooling does your system package-manager offer for that?
LSP-mode offering a “vertical” form of integration here (these major modes have been tested with these servers, and here’s how to install and invoke them) makes perfect sense to me as a user.
These two terms are not synonymous. Only proprietary software is "non-free". Software under free software licenses other than the GPL (whether copyleft or pushover/"permissive") is never considered "non-free".
No, they are not considered "non-free". Not even by RMS. Please provide evidence.
Unsurprisingly RMS prefers GPL over pushover licenses, especially when it comes to Emacs and GCC, which he considers strategic tools in a fight against proprietary software. He has been opposed to depending on Clang when GCC is not suitable (again due to his fears that GCC would be used to build proprietary compilers), but this does not mean that he considers Clang to be non-free software.
On the other hand, "manually" installing LSP servers for me has consistently been running a single liner, with the huge benefit of being packaged in a predictable manner and updated alongside my system.
Eglot is a bit of a smaller implementation and from my experience tends to require a bit less configuration than lsp-mode. I think eglot was settled on as the developer of eglot specifically put in the effort to make sure people did copyright assignment so it could be easily merged into the emacs master
Aside from what has been said, it is possible that whoever is behind lsp-mode may have never actually suggested to merge it into master. I haven't checked if this is the case, though, but if it is, then the decision is a lot simpler.
I use eglot (via doom emacs) and it works but configuration always feels like a slog--the language server it wants to start is often not in the PATH, or is configured incorrectly or something. Javascript's eslint/prettier/tsc are particularly finicky. I'd love to have some method to denote that the presence of .eslintrc/eslint in package.json means run format-on-save, otherwise don't. But I also can't really see how it could be _that_ much better on any other editor?
I've had a good experience with direnv[1] and emacs-direnv[2].
Direnv can automatically load an environment when you enter a directory, so it automatically "opens" virtualenvs/nix shells/etc. The Emacs direnv mode ensures that each buffer sees the direnv mode for its project directory.
I've found this to be a great compromise between automatic behavior on the one hand and transparency + control on the other—I get the right environment loaded automatically very consistently and, if something goes wrong, I can open a shell and poke around to see what's going on (is my nix shell messed up? is the right tool not loaded via direnv? etc). The only time I need to do anything manually is if I make a change to the environment and need to update Emacs about it, in which case I just run M-x direnv-update-environment.
Once I got this set up, I can just rely on executable-find to check for (and find) exactly the right tool on a per-project basis—no more worrying about global or seeing the wrong version of a tool. This also made it easy to do stuff like only run formatting if the corresponding tool is available: I add hooks to various programming language modes that only turn on lsp/formatting/etc if executable-find sees the corresponding executable.
Compared to the hassle I've had to go through helping my colleagues debug VSCode not seeing the right conda environment, virtualenv or the right version of various tools, Emacs + direnv has been a far nicer and more consistent experience.
Yeah, I've been doing the same thing. direnv is such a KISS tool, and is language agnostic as well. My prior experience with LSP wasn't exactly pain free, so it's definitely smoothing a rough patch. Having Elgot in master is great if makes the out of box experience work.
I use VS code for a couple days and I will already want to go back to Emacs, and having a good LSP experience is pretty important for either.
I use lsp-mode and got a usable Typescript environment without too much work. I use prettier for formatting everything, so use prettier-js-mode regardless of LSP support, and it works fine. (I have pretter-js-command set to "npx" and pretter-js-args set to "prettier"; this is for our internal components library which I guess has a customized version of prettier for our internal conventions in certain project. I don't really know; I didn't set it up, but it works.)
lsp-mode pretty much seems to do the right thing for Typescript projects without any configuration. At work we use React/TSX, for personal projects I use Svelte, and Emacs can find all the symbols, provide correct completions, and point out obvious mistakes. My only complaint is that I can never get Emacs's indentation to match what Prettier wants to do, so I'll type a bunch of code, prettier-on-save, and everything gets moved around. Not a big deal, but something I'd look into more deeply if I actually did Typescript full time. (I just occasionally change frontend stuff, but mostly program Go. gofmt and Emacs agree on formatting, but I think that's because Go is opinionated about formatting and so it's easier for multiple tools to have the same opinion. With Typescript, anything goes.)
TL;DR: despite the eglot marketing campaign and its overall cleaner design, lsp-mode might be the thing for you. I try eglot every 6 months and always switch back to lsp-mode. It has its quirks and WTFs, but doesn't get in my way too much.
> My only complaint is that I can never get Emacs's indentation to match what Prettier wants to do, so I'll type a bunch of code, prettier-on-save, and everything gets moved around.
The next major release of Emacs is going to be awesome, because among other things the so-called PureGTK work was also merged, which means that it will support HiDPI screens properly on Wayland.
Do not use pgtk if you're not on Wayland. Its maintainer on the mailing list has been pretty adamant in stressing that the old gtk3 code is the better choice if you're on x11, while pgtk is targeting wayland (so they'd rather break x11 compatibility if it fixes a wayland bug)
That said, I've been running pgtk on GNOME Wayland on a hidpi screen and it's been great.
With eglot and lsp-mode emacs, for me, has feature parity with vscode for c++ local development. Unfortunately for remote work tramp is still a nightmare and vscode far ahead.
I'd like to be wrong about this, but after some investigation I've conclused that this is not the case. The Emacs client/server model assumes that the client and server are on the same host. It doesn't work over the network.
I think the protocol between emacsclient and the server basically just allows for instructing the server which file to open and passing around things like which X display to open an x window on. I’m not sure how it works for the terminal interface (does it pass the fd over a Unix display socket or have Emacs send bytes over the protocol to the emacsclient?)
I once tried to set up some hacked bash script instead of ssh which would set up environment variables and forward the Emacs daemon socket over ssh so that if I remotely attempted to edit a file, my local Emacs would open that remote file over tramp. But the whole thing was kinda nasty.
I do want a ‘thicker’ emacsclient though but mostly because of the end of X windows as I currently use Emacs remotely with X forwarding over ssh.
Emacs is a fun long-term ride. A gift of sorts that keeps on giving... and by that, I mean no matter how experienced you are, you'll continue learning something new at all times. I often write about things I discover or build myself at https://xenodium.com.
Get yourself a copy of „Mastering Emacs“ and jump straight in. Learning by doing. Turns out you don’t actually need to install a lot of packages these days to get started. Use js2-mode and/or web-mode (?) worked great with React projects with me together with „compile mode“ („C-c C-l“) built-in) running build and tests in package.json for you. Later you can add lsp-mode or eglot if you really need to.
Once you‘re comfortable with installing packages using Emacs‘ UI try watching the „Emacs from scratch“ series on YouTube and familiarize yourself with „use-package.el“ to build a clean, version controlled custom config.
If you do a lot of technical writing org-mode.el is pretty cool and also built-in. I am using it for live coding sessions.
This is great, thanks. I’ve used Emacs since 1988 but feel like a complete newb as it’s crazy hard to keep up with the development and much of what google will turn up is seems out of data already.
I love emacs, but I really wish the out-of-the-box experience was better (eg. IIUC, even the default package repository is known obsolete, so why is it still the default?)
The thing is that you can learn it very incrementally. I've been using it for years and don't know more than a tiny bit. My knowledge of elisp is abysmal. But, you get to learn how to add little things to your config here and there when you find something worth trying or improving.
Meanwhile I recommend just learning the vanilla defaults as best as possible. As long as you know how to open files, save things, switch between buffers, and quit, you're kind of good to go as far as immediate usability goes. Eventually you learn a few more key bindings to make navigation easier and faster, how to use macros, shell commands, etc. But you can learn these things on an as-needed basis.
One of the offputting things about emacs is the enthusiasm directed to beginners to customize, pick a "distro" and basically overwhelm people when starting. It's a shame because what's wrong with enthusiasm?
But you can start using emacs with a handful of commands. Just typing puts characters into your buffer; c-f goes forward a character, c-b back a character, c-p goes the previous line, c-n goes to the next. c-x c-s saves the buffer into a file while c-x c-f finds a file by name and makes a buffer containing its contents. These commands have existed since I started using Emacs about 45 years ago!
Emacs is full of help. Press c-h for help -- it will prompt you for what you want help on. Every keystroke, every command, even "how did I get here" is in your help.
Over time you'll learn more commands, perhaps put something in your init file...and eventually it will be like a comfortable glove designed to fit your hands (which will stay on the keyboard, right?)
I get this. But on the other hand, there is a reason people customize Emacs, both by writing elisp, and loading packages. Vanilla emacs is usable, but its really not great, from a usability perspective. So the endless recommendations on what you should do to start.
Yeah, you can do what I did: open Emacs, see "help" in the menubar (best thing since sliced bread), click it, click "tutorial", and we're off to the races.
I've been using Emacs the way most people use Notepad++, just for quick text edits. Been doing that since the 1990s. The other thing I use Emacs for is the regular expression modes for search and replace. Unlike Notepad++ Emacs is available on most systems.
The on thing I would caution is Emacs creates backup files that can clutter. I find it is worth creating a dedicated back up folder. This does require configuration and there are tutorials on Youtube for this. I'd say about once or twice per year the backup files on every save have saved my bacon.
Finally, I prefer Emacs key binds to vi modes but that's just personal taste.
Yes, with caveats. Give yourself a goal you want to accomplish in Emacs -- just one -- and then start with that. Do not try to overload your learning by doing everything in Emacs from day one.
I don’t particularly know why this would motivate you to learn it. Yes you can use Lisp in Emacs - I frequently use it just to do math using Polish notation. But even though I know how to write Lisp, and have written my own functions, I rarely use it.
Your comment makes it sound like RMS tried to stop it from getting merged into core.
Whereas the mail in your link just shows that RMS wanted to discuss whether it should have a generic "LSP" name or not (i.e. retain the original eglot name), which is a valid concern.
I actually feel the name is the worst part of eglot, it's not like it's a generic polyglot thing, it's really an lsp mode, it'll be one more of those hard to discover Emacs features because of this.
Again, it's because of naming consistency, which one can agree with or not.
My issue was your comment just pointed at RMS without specifying what he was being boneheaded about this time, which I thought was a little flamebaity.
For those who don't follow the mailing list, it was actually Stefan who proposed renaming it. RMS agreed, saying that 'eglot-mode' didn't tell him anything about what it does (and that's even after recognizing the root "glot", which not everyone gets).
