lsp-interface generates a lot of noise in pcase documentation about lsp-mode HOT 10 OPEN

I'm recently experiencing performance issues in Emacs every time generating a documentation for pcase is needed. I've narrowed the issue down to when calling (documentation 'pcase), which can easily take tens of seconds, and eventually causes issues in code completion or searching documentation via helpful functions. I don't have a final proof, but I highly suspect lsp-mode adding so many pcases there is contributing a lot to it.

Running emacs master branch on 2024-07-15 eae1104f97ef944127eb5c977129b55f137e0830 and I see couple of changes in pcase recently, so it might be contributing to this.

from lsp-mode.

I like your proposal especially when it has the precedent of cl-struct.
Would you be willing to provide a PR for that? This will be a breaking change, but it would gear toward a better functionality as well documentation readability for pcase.
@leungbk as well.

from lsp-mode.

@kiennq Yeah! I started looking into it a bit last week. I can say that there doesn't seem to be any way to deprecate a pcase form defined with pcase-defmacro, like one would a normal function or macro, so that's something that would need to be communicated separately.

(I tried using (declare (obsolete …)), and also make-obsolete on the NAME--pcase-macroexpander function it generates. Unfortunately the byte compiler never actually sees a (NAME--pcase-macroexpander …) form when compiling (pcase … ((NAME …))—the NAME--pcase-macroexpander function is called directly while expanding the pcase macro—so there's no deprecation warning. Also, the way that pcase builds its docstring means it won't generate a deprecation warning there either.)

from lsp-mode.

Maybe deprecating is not much as issue, if the macros are only used in the same package.

from lsp-mode.

That's actually something I'm unclear on: are these pcase forms part of lsp-mode's public interface? Or are they only an internal implementation detail? I'm only an lsp-mode end user, so I'm not familiar with the conventions.

I was planning to keep the old pcase forms around in this PR, delegating to the new one—then they could be dropped in the next major version. If they are only meant to be used internally, then maybe we can just drop them now. (Though, of course, Hyrum's Law might apply…)

from lsp-mode.

I just opened #4559 as a draft. It currently adds the new (lsp-interface INTERFACE ...) pcase form and preserves the old per-interface forms as well. I'll start replacing uses of the old pcase forms in lsp-mode next.

from lsp-mode.

@yyoncho @leungbk, is it okay to drop support for the old pcase form? It makes Emacs slower (might be due to a bug in the new version) and also pollute the pcase docs so more relevant forms are hidden.
We can announce this as a breaking change in the CHANGELOG so broken packages that depends on the old behaviors can fix it if they want.

from lsp-mode.

from lsp-mode.

I'm OK with dropping the old form.

That does simplify things. 🎉

from lsp-mode.

Sorry for all the commit noise. I think that PR is ready for review. 👍

from lsp-mode.