Does eglot work with third party packages?

Reading through the eglot docs, it talks about how a lot of its functionality is exposed through the default emacs packages, and that's one of the reasons why eglot is also built in, so it can work better with the defaults. So my question is - if I use flycheck, am I gimping myself? Does eglot also seamlessly work with flycheck, ivy, etc. because they all secretly use the same data sources or something? It's also got me thinking, is flycheck way better than flymake? I kind of cargo culted my current set of packages.

> Does eglot work with third party packages? Some of them yes, for example company or yasnippet. > Does eglot also seamlessly work with flycheck, ivy, etc. AFAIK, no. You may have those installed but eglot won't use them. > It's also got me thinking, is flycheck way better than flymake? It used to be, but then João Tavóra (who later on wrote eglot) improved flymake so that it became as good as flycheck (IMHO). What I do is make flycheck and flymake use the same bindings for the same functionality, so it doesn't matter much which one a mode is using.

Care to share your bindings?

I'm afraid that won't be very useful since I only use jump to previous/next error, but I'm sure you can find other functionality offered by both libraries which you can then harmonize under a single keybinding (not necessarily a user-reserved one like the one I use). (use-package flymake-mode :custom ((flymake-no-changes-timeout nil)) :bind (:map flymake-mode-map ("M-n" . flymake-goto-next-error) ("M-p" . flymake-goto-prev-error))) (use-package flycheck-mode :bind (:map flycheck-mode-map ("M-n" . flycheck-next-error) ("M-p" . flycheck-previous-error)))

If the third party packages in question integrate with default Emacs functionality then I imagine eglot will work with them as well. If they instead provide their own custom APIs such that other packages need to know about them to do anything with them, I suspect eglot won't know about them.

>If the third party packages in question integrate with default Emacs functionality then I imagine eglot will work with them as well. Which is an excellent synopsis of why the recent trend of improving on and targeting default Emacs capabilities, vs. creating standalone islands, is such a good thing.

I just recently swapped from helm/flycheck/lsp/projectile to vertico/flymake/eglot/project - I think there are two main ecosystems in Emacs (and this is not exactly a new revelation). Those packages that have FSF assignment and are part of GNU Elpa/Emacs core (in this case Eglot and friends) and those packages which are unassigned/MELPA/independently developed and collaborative (usually because the authors prefer the least friction and develop via Github/GH Issues, and not the mailing list). I notice the trend tends to be Emacs adds something into core that is a bit lacking - it gets re-implemented/greatly improved (flycheck over flymake for instance, lsp-mode over <nothing>, helm over ido-mode), then with enough time the GNU Emacs offerings tend to catch up (exception being vc-mode vs magit - magit remains untouchable). I wouldn't say that I feel flymake is better than flycheck (or Eglot better than lsp) - in a lot of ways, it just feels like coke vs pepsi at this point (but for the most part, you'll be better served by sticking with one ecosystem or the other, instead of trying to blend them). You can see this in some of the github issues surrounding Eglot/Flymake and how the author makes some tight coupling between the two, with little regard for other solutions (flycheck).

How do you like vertigo and project, do you feel like your missing anything critical?

If you want to use flycheck instead, may be you can have look the [flymake-flycheck](https://github.com/purcell/flymake-flycheck) , and the author's Emacs configuration: [https://github.com/purcell/emacs.d/blob/master/lisp/init-flymake.el](https://github.com/purcell/emacs.d/blob/master/lisp/init-flymake.el) Personally, I just use the built-in flymake with eglot.

I'm liking it - I really only used projectile for swapping to projects and the project specific file open dialog - I just use project-find-file for that now (the file picker) and project-switch-project for opening my saved projects. To make vertico really work for me required a minor configuration of "orderless" for the helm like space separated regex filter/narrowing, and some consult configuration for the more contextual narrowing for things like flymake diagnostics.

If you used projectile for project type specifics such as configure or compile than projectile is still better. For example projectile can work with cmake project types.

>I notice the trend tends to be Emacs adds something into core that is a bit lacking - it gets re-implemented/greatly improved (flycheck over flymake for instance, lsp-mode over <nothing>, helm over ido-mode), then with enough time the GNU Emacs offerings tend to catch up (exception being vc-mode vs magit - magit remains untouchable). I noticed that too. The issue I see with that some of the core Emacs authors don't even try melpa packages when the re-implement things or try to get them into core. Like the author of package-vc never used Borg or Straight but from my point of view copies the functionality into package.el. From that or just from being in this bubble the two types of cycles implement things in their needs but not necessarily in a way that they are useful for the broad amount of people. Core packages often feel very baren from my pov. It feels like their this political barrier between them where at least one side doesn't acknowledge the other. One of the issues that creates this barrier is the copyright assignment into the FSF, you have to sign in into them to contribute which comes with all the issues with dealing with the FSF, RMS and co. In some way the FSF, RMS and co hurt their own mission by being this way. Not that RMS as a person is easy to deal with anyway. The next "issue" is the mailinglist and the bugtracking. Emacs has a bug tracker which is comparable to Bugzilla, Debian bugs or even to issues of Forges such as Github, Gitlab, Gitea etc. The bugtracker is ok is really not as easy to use outside of Email, you have to use email to be able to interact with it besides viewing a bug. If the ui would be a little bit better and users wouldn't have to use email it would help greatly. Not that email is bad but for most people their email programs aren't as capable for dealing with large sums of mails and mainglists (threats etc) in general. The next issue is the way that people contribute. For people that don't like to deal with Email sending in patches is hard. Both ways to contribute have their downsides e.g. for example with Forges you have to rebase usually. I read this blog post recently that summaries the difference quite good: [https://blog.brixit.nl/git-email-flow-versus-github-flow/](https://blog.brixit.nl/git-email-flow-versus-github-flow/) Maybe setting something like GitGitGadget would help: [https://gitgitgadget.github.io/](https://gitgitgadget.github.io/) Wine did switch to Gitlab recently and managed to bridge their mailinglist based process to Gitlab. This post went kinda overboard but the issue is a general problem with Emacs that only gets worse in time when there are these two cycles.