4 ms·

> instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, I am using lsp-mode enhanced autocompletio

> instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, I am using lsp-mode enhanced autocompletion (using company.el) and I have never observed such a problem. I set the autcompletion delay to 0.0 in my case and work on 1k LOC modules. If you enjoy VS code, I am glad for you. It is certainly a good editor. But don't post generalized slurs against Emacs if you obviously haven't used it for long. Performance issues can happen but that highly depends on the context. What combination of language server, language server client and what language is causing this? Edit: If you are new to "lsp-mode" and you have performance issues, take a look here: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-native-serializationdeserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#json-... Also consider trying other LSP servers if available. For popular languages there are usually several alternatives to choose from: https://langserver.org/ https://langserver.org/

BaculumMeumEst 3y ago
I mentioned that bringing up performance issues will bring you insults and dismissal, and you saw fit to reply with: > I have never observed such a problem > don't post generalized slurs against Emacs > If you enjoy VS code, I am glad for you. > you obviously haven't used it for long I guess it did not occur to you that you are immediately proving my point. To answer your question, the context is literally every single language server. Not only with autocompletion delay to 0.0, but also setting the minimum prefix to 1, so that it activates on every keystroke; the default is 3. The fuzzy completion cannot be configured out of the box, of course, it requires another extension. I posted a thread with much detail on why it occurs. You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.
- G3rn0ti 3y ago
  Well, Emacs has indeed a problem with blocking because it is single-threaded. To resolve that issue internally it also maintains an event loop being used to drive async. functions calls. But not all extensions leverage that yet. But I doubt the problem described in that reddit thread you cited is really caused by that. It sounds more likely the author of that Emacs fork experienced an issue with inter process communication. Who knows because there is no detailed context given. I am using "lsp-mode" for Javascript, Typescript (including React) and even on a huge Perl repository and I don't find it to be too slow for me. I am running a five year old mediocre laptop using Ubuntu. But perhaps I don't have the same standards as the author of that Emacs fork. > You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations. Well, it's an impressive feat, for sure. But I don't know anyone actually using that person's fork. So I wonder whether that really is such a huge problem as the author implies. And -- why do you care anyway since you seem to be happy using VSCode?
  - antoineMoPa 3y ago
    I'm not the one you are directly replying to, but I love other aspects of emacs too much to switch (magit, org-mode, macros, code navigation, eshell, etc.) But everything can and should be improved.
- G3rn0ti 3y ago
  > Not only with autocompletion delay to 0.0, but also setting the > minimum prefix to 1, so that it activates on every keystroke; > the default is 3. There, from my config: (use-package company :after lsp-mode :hook (lsp-mode . company-mode) :bind (:map company-active-map ("<tab>" . company-complete-selection)) (:map lsp-mode-map ("<tab>" . company-indent-or-complete-common)) :custom (company-minimum-prefix-length 1) (company-idle-delay 0.0)) I had no performance issues whatsoever with it. The suggestions tend to be better in quality when coding in Typescript due to the type hints compared to, say, Perl being designed around dynamic typing. But that's a limitation of the language.
antoineMoPa 3y ago
Thanks for pointing out the lsp performance page. I'll definitely be trying all of that today. If it works, then I wonder why these adjustments are not in default emacs.

BaculumMeumEst 3y ago

I mentioned that bringing up performance issues will bring you insults and dismissal, and you saw fit to reply with: > I have never observed such a problem > don't post generalized slurs against Emacs > If you enjoy VS code, I am glad for you. > you obviously haven't used it for long I guess it did not occur to you that you are immediately proving my point. To answer your question, the context is literally every single language server. Not only with autocompletion delay to 0.0, but also setting the minimum prefix to 1, so that it activates on every keystroke; the default is 3. The fuzzy completion cannot be configured out of the box, of course, it requires another extension. I posted a thread with much detail on why it occurs. You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.

G3rn0ti 3y ago
Well, Emacs has indeed a problem with blocking because it is single-threaded. To resolve that issue internally it also maintains an event loop being used to drive async. functions calls. But not all extensions leverage that yet. But I doubt the problem described in that reddit thread you cited is really caused by that. It sounds more likely the author of that Emacs fork experienced an issue with inter process communication. Who knows because there is no detailed context given. I am using "lsp-mode" for Javascript, Typescript (including React) and even on a huge Perl repository and I don't find it to be too slow for me. I am running a five year old mediocre laptop using Ubuntu. But perhaps I don't have the same standards as the author of that Emacs fork. > You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations. Well, it's an impressive feat, for sure. But I don't know anyone actually using that person's fork. So I wonder whether that really is such a huge problem as the author implies. And -- why do you care anyway since you seem to be happy using VSCode?
- antoineMoPa 3y ago
  I'm not the one you are directly replying to, but I love other aspects of emacs too much to switch (magit, org-mode, macros, code navigation, eshell, etc.) But everything can and should be improved.
G3rn0ti 3y ago
> Not only with autocompletion delay to 0.0, but also setting the > minimum prefix to 1, so that it activates on every keystroke; > the default is 3. There, from my config: (use-package company :after lsp-mode :hook (lsp-mode . company-mode) :bind (:map company-active-map ("<tab>" . company-complete-selection)) (:map lsp-mode-map ("<tab>" . company-indent-or-complete-common)) :custom (company-minimum-prefix-length 1) (company-idle-delay 0.0)) I had no performance issues whatsoever with it. The suggestions tend to be better in quality when coding in Typescript due to the type hints compared to, say, Perl being designed around dynamic typing. But that's a limitation of the language.

antoineMoPa 3y ago

Thanks for pointing out the lsp performance page. I'll definitely be trying all of that today. If it works, then I wonder why these adjustments are not in default emacs.