[HN Gopher] Eglot has landed on master: Emacs now has a built-in...
___________________________________________________________________
Eglot has landed on master: Emacs now has a built-in LSP client
Author : todsacerdoti
Score : 323 points
Date : 2022-10-20 17:33 UTC (3 days ago)
(HTM) web link (lists.gnu.org)
(TXT) w3m dump (lists.gnu.org)
| frou_dh wrote:
| 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.
| josteink wrote:
| Emacs 29 also aims to introduce experimental support for tree-
| sitter[1], although it will probably be hidden behind a
| configure-flag.
|
| This should enable us to create better, faster parsers for
| popular languages where the Emacs-support so far has not been
| that great.
|
| So yeah I second that. Emacs 29 is going to be a great release!
|
| [1] https://github.com/tree-sitter/tree-sitter
| mickeyp wrote:
| I wrote about the importance of tree sitter a while back, for
| people who don't know why Emacs would adopt it:
|
| https://www.masteringemacs.org/article/tree-sitter-
| complicat...
| bloopernova wrote:
| Thank you for a clear and informative article!
|
| (And thank you for your wonderful book and website, they've
| both made my life in DevOps more enjoyable and effective)
| mickeyp wrote:
| Thank you :) I'm glad you like the book and site! That
| makes me very happy.
| NeutralForest wrote:
| I'm using it right now!
| sph wrote:
| 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.
| ghosty141 wrote:
| PGTK is also needed for proper gnome window borders on WSL 2
| zarkov99 wrote:
| 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.
| nine_k wrote:
| But VSCode has a very different model than Tramp: a remote
| server part, not just remote file access.
|
| Technically you can run an Emacs server remotely, and connect
| to it with the UI client. But the setup is going to be much
| more involved.
| spudlyo wrote:
| 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.
| [deleted]
| nequo wrote:
| I haven't tried this myself but would it be possible with
| ssh port forwarding? Here is someone who seems to have done
| it:
|
| https://mina86.com/2021/emacs-remote/
| dan-robertson wrote:
| 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.
| [deleted]
| zora_goron wrote:
| > Technically you can run an Emacs server remotely, and
| connect to it with the UI client. But the setup is going to
| be much more involved.
|
| Any pointers on how to get started with this?
| hendrikrassmann wrote:
| 2023 will be the year of emacs on the desktop.
| fooker wrote:
| * desktop on emacs.
|
| FTFY
| omnicognate wrote:
| With EXWM, Emacs has been my desktop for years.
| mnutt wrote:
| 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?
| tikhonj wrote:
| 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.
|
| [1]: https://direnv.net/
|
| [2]: https://github.com/wbolster/emacs-direnv
| mcbuilder wrote:
| 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.
| jrockway wrote:
| 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.
| rwilson4 wrote:
| Exciting! I've happily used elpy [0] for years but it seems to be
| unsupported now. Might be time to switch!
|
| [0]: https://github.com/jorgenschaefer/elpy
| 098799 wrote:
| elpy+jedi has been my main environment. LSP was really slow
| every time I tried it.
| donatzsky wrote:
| Emacs used to have poor json support, which is why lsp was
| slow. That got fixed a version or two ago, and now lsp works
| great.
| bigbillheck wrote:
| Despite the last-minute efforts of RMS:
| https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00...
| sph wrote:
| 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.
| bigbillheck wrote:
| Here's him suggesting delaying the release until January:
| https://lists.gnu.org/archive/html/emacs-
| devel/2022-10/msg00...
| sph wrote:
| 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.
| vfclists wrote:
| There only two hard things in computer science:
|
| This first is naming things
|
| The second is getting emacs-lisp to hold hands with the
| rest of the world
| didibus wrote:
| 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.
| tgerdin wrote:
| Awesome
| chungus wrote:
| 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.
| eddieh wrote:
| 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.
| rogual wrote:
| E as in Emacs, glot as in polyglot?
| eddieh wrote:
| That sounds too close to EGOT
| https://en.wikipedia.org/wiki/List_of_EGOT_winners
| frou_dh wrote:
| The clever thing is that it's also eglot as in polyglot.
| FPGAhacker wrote:
| That makes sense, and never occurred to me. I was in the
| egg-lot camp
| TacticalCoder wrote:
| 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?
| sreevisakh wrote:
| 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.
| aardvark179 wrote:
| 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.
| jacobsenscott wrote:
| 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.
|
| https://emacs-lsp.github.io/lsp-
| mode/page/installation/#vani...
| wakeupcall wrote:
| > (eg: projectile vs project.el).
|
| Always curious of why you prefer one of the other. Any
| major thing you prefer projectile? (only ever used
| project.el here and was satisfied)
|
| Similarly, I'm using ivy, first time I see vertico which
| looks similar.
| ghosty141 wrote:
| It has a working switch to cpp/hpp function that you cant
| really get otherwise. Thats the only thing I miss from
| projectile.
| mickeyp wrote:
| This is actually a builtin feature of Emacs, and is
| available regardless of whether you use projectile or
| project.
|
| Try `M-x ffap' whilst point is on an include directive's
| filename, or `M-x ff-find-other-file' to jump between C/H
| header files.
| timlod wrote:
| 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.
| tptacek wrote:
| 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.
| ghosty141 wrote:
| Flymake is my biggest gripe with eglot. Sadly you cant
| really switch it out with flycheck
| tptacek wrote:
| 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.
| morelisp wrote:
| Was `flycheck-list-errors` not part of your workflow, or
| do you have a decent replacement for it? Its lack is my
| one gripe with flymake.
| mickeyp wrote:
| Have you tried `M-x flymake-show-project-diagnostics'?
| morelisp wrote:
| Yes; as far as I can tell it runs afoul of unresolvable
| project.el incompatibilities unless you're using at least
| Emacs 28.
| BaculumMeumEst wrote:
| It seems odd to complain about an issue that doesn't
| exist in the latest stable version.
| josteink wrote:
| Some people run Emacs from their local system package-
| managers instead of building from source.
|
| They _will_ be stuck on older versions and experience
| those problems as current problems.
| morelisp wrote:
| 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.
| anyfoo wrote:
| 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.
| tptacek wrote:
| 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.
| Myrmornis wrote:
| 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.
| anyfoo wrote:
| 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.)
| [deleted]
| josteink wrote:
| > I just remember a zillion weird popups with lsp-mode
|
| I think that may be lsp-ui, not lsp-mode, but I might be
| mistaken.
| josteink wrote:
| > 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.
| [deleted]
| jhoechtl wrote:
| > 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
| zozbot234 wrote:
| 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.
| PuercoPop wrote:
| Eglot was written with the explicit goal of landing into
| Emacs. Which is why from the start it required copyright
| assignment for non trivial changes.
|
| Landing into Emacs core was never a goal for lsp. So it wasnt
| a choice between eglot vs lsp. It was eglot, yay or nay.
| oehtXRwMkIs wrote:
| 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).
| PuercoPop wrote:
| Why would one want to run eslint through an LSP? Using
| flymake it call the CLI works just fine and is more direct.
| jrockway wrote:
| 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!)
| morelisp wrote:
| > 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.
| wakeupcall wrote:
| 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.
| morelisp wrote:
| > 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.
| nverno wrote:
| 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
| pdimitar wrote:
| I forgot the details but several months ago I had a lot of
| trouble just having Rust and Elixir LSPs to even start.
|
| I got quite weary of hacking on my Emacs so I switched to
| eglot and had zero trouble since.
|
| Sorry for lack of context, I am not shilling for eglot at
| all, it's just that I have a huge "make it your own by
| hacking!" fatigue these days.
| codeflo wrote:
| I've been wanting to learn Emacs for 20 years. Is now finally the
| time?
| radarsat1 wrote:
| 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.
| margarina72 wrote:
| honestly i tried the vanilla default many time to start with
| and it was the reason I waited so long to adopt emacs.
|
| Since I tried Doom Emacs, I am really enjoying the
| experience, and it has seriously improved my workflow.
|
| Now I can gradually learn things, improve my lisp, or try new
| work flows, etc.
|
| Pre made distribution are a real improvement to the emacs
| ecosystem.
| mickeyp wrote:
| Agreed. This is really good advice.
| gumby wrote:
| 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?)
| tmtvl wrote:
| 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.
| jonnycomputer wrote:
| 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.
| bloopernova wrote:
| A lot like a minimal Linux distro. Both scratch the itch
| of "I wish I could do this when that happens."
| mybrid wrote:
| 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.
| mickeyp wrote:
| 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.
| julianeon wrote:
| 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.
| xenodium wrote:
| 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.
|
| https://planet.emacslife.com is a great aggregator.
| https://reddit.com/r/emacs is handy too.
| https://www.youtube.com/c/SystemCrafters is an awesome channel.
| https://emacsrocks.com has some awesome demos.
| https://emacsrocks.com/e13.html is one of my all-time favorites
| (watch until the end, has a worthy finale).
| G3rn0ti wrote:
| 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.
| FullyFunctional wrote:
| 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?)
| noelwelsh wrote:
| I put the question to the Emacs magic eight ball
| (https://github.com/RyanMatlock/eight-ball) and the answer was
| yes!
| tsuru wrote:
| Yes.
| Myrmornis wrote:
| 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.
| rout39574 wrote:
| How many contributions did you have to eglot before it was
| included?
| Myrmornis wrote:
| 4 PRs and 3 Issues
| tgerdin wrote:
| Probably says more about the Emacs development process than
| Eglot itself. But as it stands, the copyright assignment is
| non-negotiable I guess.
| db48x wrote:
| Email is Email. Either you reply to an email from Github or an
| email from the mailing list.
| Myrmornis wrote:
| 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.
|
| - and many other things
| rekado wrote:
| 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.
| db48x wrote:
| 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
|
| - and many other things
| count wrote:
| > - 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.
| db48x wrote:
| > 'Just do everything different from what tons of other
| folks are doing day in and day out' is not the best
| answer.
|
| Following the herd is definitely the wrong answer.
| st3fan wrote:
| tmtvl wrote:
| 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.
| dan-robertson wrote:
| 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).
| fithisux wrote:
| Huge
| j_m_b wrote:
| What's the difference between egplot and lsp-mode? Why was it
| what the emacs devs settled on?
| dleslie wrote:
| As a primarily C# developer, these days, both are unusable
| because their interaction with omnisharp is slow, brittle, and
| prone to indefinite hangs.
|
| It's odd, because vscode uses omnisharp over lsp and it is
| fast, powerful and reliable.
| zasdffaa wrote:
| I tried using omnisharp with emacs and it was as crappy as
| you say. I gave up with it and went back to Vis. studio, with
| regrets.
| honkob wrote:
| 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
| e3bc54b2 wrote:
| *eglot (short for Emacs polyGLOT)
|
| 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.
| amake wrote:
| lsp-mode also uses xref.
| tptacek wrote:
| It has its own thingy, too, in lsp-ui, right?
| morelisp wrote:
| > OTOH lsp-mode supports more than 1 active language server
| per buffer
|
| If LSP survives, I'm certain solving this in the editor
| rather than the server this will come to be seen as an anti-
| pattern.
| mdaniel wrote:
| 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
| morelisp wrote:
| It's a somewhat-supported thing;
| https://code.visualstudio.com/api/language-
| extensions/embedd... has some introduction to how it's
| often done.
|
| 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.
| mdaniel wrote:
| That was a super interesting link, thank you.
|
| 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)_ :
|
| * https://lisperator.net/uglifyjs/ast#nodes
|
| * https://github.com/estree/estree#the-estree-spec
|
| * ... likely others
|
| 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
| josteink wrote:
| > 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?
| e3bc54b2 wrote:
| 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!
| rekado wrote:
| > "non-free" (not GPLed)
|
| 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".
| lvass wrote:
| 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.
| tptacek wrote:
| 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.
| josteink wrote:
| 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.
| jhoechtl wrote:
| > OTOH lsp-mode supports more than 1 active language server
| per buffer
|
| for those editing html fes with css and javascript all in one
| file this is a showstopper
| luispauloml wrote:
| 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.
| clircle wrote:
| Eglot has copyright assigned to FSF and has been targeting a
| master branch merge since its development started.
| NeutralForest wrote:
| So glad, there's a branch for tree-sitter as well =)
___________________________________________________________________
(page generated 2022-10-23 23:00 UTC)