Fork me on GitHub

re: I'd say I've heard of indentation-related freezing for much of the year, whether it's around #emacs or at a couple workplaces. I'm not intimately familiar with the feature but it reminds me of electric-indent-mode (or aggressive-indent-mode) which is also known to be a source of freezing/slowness - has been for years. With which I mean perhaps lsp is trying to solve bit of a hard problem by default? Perhaps interested people can opt in instead. Otherwise we contribute to bit of a hard-to-debug landscape with many participants / moving pieces (e.g. doom, cider, clojure-lsp, N more packages), in that sense the more conservative the defaults are, the fewer problems are experienced and the fewer problems are reported. Food for thought perhaps. Either way, happy new year! clojure-lsp


99% of the time is conflicts between modes and is easily solved with the profiler + disabling one of the offenders. In my experience it's not exclusive to lsp


aggressive-mode is also one of the usual suspects


But it works great with lsp with the right configuration


I have to turn off aggressive-indent bc it was causing unbearable lag with files > 1-2k LOC. What was your configuration like @mpenet?


Some stuff might be emacs 28+ & nativecomp specific.


Yeah that's fine, I use 28 + pgtk What's the reason for: (remove-hook 'before-save-hook #'aggressive-indent--process-changed-list-and-indent 'local)?


On save aggressive-indent would conflict with a lsp hook and stall


Can't remember the exact details tbh


(on my phone right now)


Ah ok, hmm, yea the lag I experience is during editing (not saving) 😞


> . In my experience it's not exclusive to lsp Sure, it's not anyone's fault but the nature of a conflict (since as you say, this looks like a conflict between modes) is precisely to add things that might compose badly with others. So while there's no single specific member at fault, holistically they create a buggy system. I think that's somewhat common in Emacs packages, they try to stuff N features in them, then funny behaviors arise. It would be better, as a trend, to provide code mostly as libs, maybe I get a few core features and then N opt-in features via defcustoms. IMO Emacs users are best treated as discerning programmers that can understand what's offered, and what can be eventually enabled.


For all editors this default setting making sense as enabled IMO, I'm not a fan of disabling only on emacs because of other packages issues :/


Anyway, we do have some performance issue on that feature indeed because of cljfmt unfortunately


We already tried improvements that helped a lot, but it seems it was not enough on cljfmt side


> For all editors this default setting making sense as enabled IMO, I'm not a fan of disabling only on emacs because of other packages issues We're not sure if this is the case for all related problems. One thing that I know is that various people I know end up disabling lsp's formatting, not other packages' settings. So it's the common denominator, for the simple reason that lsp is trying something that is pretty hard to achieve (which also deserves kudos of course), and other packages typically aren't


Also I'm not sure if you're aware that clojure-mode can match 1:1 with cljfmt formatting? (assuming both are sensibly tuned) So cljfmt as-you-type would be largely redundant for Emacs. Admittedly not everything is perfect, there are a few parties involved (cljfmt, cider, lsp, clojure-mode) so getting them to agree isn't guaranteedly automatic. I think a great approach would be to trying the authors to agree on what can be done. Else if us authors each do their own thing, we get a) a proliferation of formatting standards, and b) suboptimal implementations of whatever formatting we're going for, because the Emacs packages in question will compose badly.


when you stop using cljfmt from clojure-lsp and use only for emacs, you follow the rules that clojure-mode use, if a project/team use a common lsp/cljfmt config, that won't be used, right? Also, I already saw lots of LSPs that have the automaitc format feature (even when saving files, like Flutter/dart), and for a IDE UX seems to work/makes really sense.


I think we just have a performance issue that if fixed users would not complain about that


maybe just a little more effort on lsp/cljfmt side to improve that


> if a project/team use a common lsp/cljfmt config, that won't be used, right? This shouldn't be a problem, provided that there's a 1:1 mapping between cljfmt and clojure-mode that can be translated in both directions. So, for example, one could create a simple parser written in .el that would tweak clojure-mode, out of a lsp config file. ...Or, the config file could be some standard file that isn't specific to lsp or Emacs. (Yay standards! 🌀)


we already follow a standard that checks for a file on project root level .cljfmt.edn :)

🙂 1

My point is, seems odd to me handle emacs as a Editor that should have formatting disabled just because there is a package that do the same, but user needs to use other preferences (configure in a cljfmt file instead of .lsp/config.edn for example)


just because of a performance issue (that happens for specific cases)


> but user needs to use other preferences (configure in a cljfmt file instead of .lsp/config.edn for example) Doesn't this assume that lsp is "the standard"? There's no standard as for how to define a project's intended formatting. Not everyone uses lsp, and plenty of lsp users use cider, for example. So there's room for improvement/agreement, and said improvement wouldn't be some sort of workaround, but rather something that would be pretty sensible in face of diverse tooling preferences


Yes, but I see no reason why one would want to use LSP but not the formatting feature for example, we have options to disable that though


I do see a reason why a user wouldn't want the formatter: because the workplace standard might not be lsp or cljfmt at all Leaving IDE's formatting setup aside is a pretty common practice. Say I'm using Cursive, maybe the first thing I would do would be to disable autoformatting, while certainly enjoying all other features


Another perspective is that while clojure-lsp might have a holistic purpose, users don't necessarily want that all-in-one experience because they already are using clojure-mode and cider. So as 'good citizens', one can try to leave software as composable as possible, at least by default.


A practical example is, default nil, even if atm generally works, and is much desirable, has months of work behind, etc. Sometimes stuff just needs time, that's my humble input


I see your point, I'm not a fan of disabling formatting for a specific editor but if it makes sense for community we could give a try


disabling as a whole for all editors would probably be a bad idea as there are other editors that doesn't have any other formmatting rule besides lsp (also kind of breaking change)


Cheers, hammocking appreciated Emacs is probably 'special' but yeah for the other editors it probably makes much sense. (thanks for bringing the parens to them!)


thank you for the discussion! hammocking makes sense indeed


Could/should lsp be capable to move functions to other namespaces and adjust call sites?


There is an open issue for that feature afaik.


Thanks, I will look for it.


@U05094X3J could you confirm in the issue if the rename suggestion would be enough?


Ok, will write over there.