* Too long completion delay time in LISP interaction mode.
@ 2021-10-20 3:11 Hongyi Zhao
2021-10-20 4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-10-20 5:01 ` Tassilo Horn
0 siblings, 2 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 3:11 UTC (permalink / raw)
To: help-gnu-emacs
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git master
version. I find there is a very long completion delay time in LISP
interaction mode. For example, when I type `(map)' in scratch buffer,
there will have 5070 candidates as shown in the attached file, and the
completion delay is about 2-5 seconds.
Any hints to improve this phenomenon?
Regards
--
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
[-- Attachment #2: Selection_004.png --]
[-- Type: image/png, Size: 173009 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 3:11 Too long completion delay time in LISP interaction mode Hongyi Zhao
@ 2021-10-20 4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-10-20 4:27 ` Hongyi Zhao
2021-10-20 5:01 ` Tassilo Horn
1 sibling, 1 reply; 22+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-10-20 4:11 UTC (permalink / raw)
To: help-gnu-emacs
Hongyi Zhao wrote:
> On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git
> master version [...]
You can use C-u M-x emacs-version RET
or (emacs-version t)
^ eval me
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2021-10-04
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-10-20 4:27 ` Hongyi Zhao
0 siblings, 0 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 4:27 UTC (permalink / raw)
To: Emanuel Berg, help-gnu-emacs
On Wed, Oct 20, 2021 at 12:11 PM Emanuel Berg via Users list for the
GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Hongyi Zhao wrote:
>
> > On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git
> > master version [...]
>
> You can use C-u M-x emacs-version RET
>
> or (emacs-version t)
> ^ eval me
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
of 2021-10-11
> GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
> 1.16.0) of 2021-10-04
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
--
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 3:11 Too long completion delay time in LISP interaction mode Hongyi Zhao
2021-10-20 4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-10-20 5:01 ` Tassilo Horn
2021-10-20 5:29 ` Hongyi Zhao
1 sibling, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-20 5:01 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git master
> version. I find there is a very long completion delay time in LISP
> interaction mode. For example, when I type `(map)' in scratch buffer,
> there will have 5070 candidates as shown in the attached file, and the
> completion delay is about 2-5 seconds.
>
> Any hints to improve this phenomenon?
First, I'd try to isolate where the slowdown happens. The screenshots
suggests you are using company-mode with custom hacks to get the
numbering of candidates and you are using some fuzzy completion-style.
So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get the
*Completions* buffer. That will probably be fast but deliver less
results because of the default value of `completion-styles'. Then I'd
try out your settings of `completion-styles' (and
`completion-category-overrides' if you have customized that). Then
again with `company-mode' but first without the numbering hack, and
eventually with it. At which step does it become slow?
Also, using the profiler might shed some light on where the time is
spent, see (info "(elisp) Profiling").
HTH,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 5:01 ` Tassilo Horn
@ 2021-10-20 5:29 ` Hongyi Zhao
2021-10-20 5:49 ` Tassilo Horn
2021-10-20 5:58 ` Hongyi Zhao
0 siblings, 2 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 5:29 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 1:08 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> > On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git master
> > version. I find there is a very long completion delay time in LISP
> > interaction mode. For example, when I type `(map)' in scratch buffer,
> > there will have 5070 candidates as shown in the attached file, and the
> > completion delay is about 2-5 seconds.
> >
> > Any hints to improve this phenomenon?
>
> First, I'd try to isolate where the slowdown happens. The screenshots
> suggests you are using company-mode with custom hacks to get the
> numbering of candidates and you are using some fuzzy completion-style.
>
> So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get the
> *Completions* buffer. That will probably be fast but deliver less
> results because of the default value of `completion-styles'. Then I'd
> try out your settings of `completion-styles' (and
`C-h o completion-styles RET'
completion-styles is a variable defined in ‘minibuffer.el’.
Its value is (hotfuzz)
Original value was
(basic partial-completion emacs22)
> `completion-category-overrides' if you have customized that).
`C-h o completion-category-overrides RET'
completion-category-overrides is a variable defined in ‘minibuffer.el’.
Its value is nil
> Then again with `company-mode' but first without the numbering hack, and
> eventually with it. At which step does it become slow?
>
> Also, using the profiler might shed some light on where the time is
> spent, see (info "(elisp) Profiling").
`M-x profiler-start RET cpu and mem RET'
Typeset (map) in scratch buffer, and then
`M-x profiler-report RET', gives the following results:
262,542,852 87% - command-execute
262,542,852 87% - funcall-interactively
262,538,196 87% - counsel-M-x
262,538,196 87% - let
262,355,940 87% - ivy-read
262,355,940 87% - apply
262,354,884 87% + #<lambda 0x1b9d5ef2eb92a3f2>
182,256 0% + counsel--M-x-externs
4,656 0% + self-insert-command
36,160,744 12% + company-post-command
368,131 0% + redisplay_internal (C function)
135,480 0% + timer-event-handler
7,442 0% + eldoc-pre-command-refresh-echo-area
2,640 0% + highlight-parentheses--initiate-highlight
2,112 0% + jit-lock--antiblink-post-command
1,056 0% + company-pre-command
0 0% ...
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 5:29 ` Hongyi Zhao
@ 2021-10-20 5:49 ` Tassilo Horn
2021-10-20 6:11 ` Hongyi Zhao
2021-10-20 5:58 ` Hongyi Zhao
1 sibling, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-20 5:49 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> First, I'd try to isolate where the slowdown happens. The
>> screenshots suggests you are using company-mode with custom hacks to
>> get the numbering of candidates and you are using some fuzzy
>> completion-style.
>>
>> So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get
>> the *Completions* buffer. That will probably be fast but deliver
>> less results because of the default value of `completion-styles'.
>> Then I'd try out your settings of `completion-styles' (and
>
> `C-h o completion-styles RET'
>
> completion-styles is a variable defined in ‘minibuffer.el’.
>
> Its value is (hotfuzz)
Never heard of it. But is it a suitable catch-all completion style,
i.e., suitable for using it without another more prefix-oriented style
preceeding it? FWIW, when I type "(map", I'm most probably not
interested in having smartparens-mode, or
lsp:document-symbol-capabilities-hierarchical-document-symbol-support?
showing up as the top candidates but more in mapcar, mapc, mapcan, you
name it...
>> Also, using the profiler might shed some light on where the time is
>> spent, see (info "(elisp) Profiling").
>
> `M-x profiler-start RET cpu and mem RET'
I think you only need cpu here.
> Typeset (map) in scratch buffer, and then
>
> `M-x profiler-report RET', gives the following results:
>
> 262,542,852 87% - command-execute
> 262,542,852 87% - funcall-interactively
> 262,538,196 87% - counsel-M-x
> 262,538,196 87% - let
> 262,355,940 87% - ivy-read
> 262,355,940 87% - apply
> 262,354,884 87% + #<lambda 0x1b9d5ef2eb92a3f2>
> 182,256 0% + counsel--M-x-externs
So the bottleneck is in the lambda which you didn't expand. But I'm
also not sure if you are profiling the right thing because I don't think
that in-buffer completion (in terms of `completion-at-point-functions')
starts with M-x (or counsel-M-x).
Bye,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 5:29 ` Hongyi Zhao
2021-10-20 5:49 ` Tassilo Horn
@ 2021-10-20 5:58 ` Hongyi Zhao
2021-10-20 15:30 ` [External] : " Drew Adams
1 sibling, 1 reply; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 5:58 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 1:29 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 1:08 PM Tassilo Horn <tsdh@gnu.org> wrote:
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > > On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git master
> > > version. I find there is a very long completion delay time in LISP
> > > interaction mode. For example, when I type `(map)' in scratch buffer,
> > > there will have 5070 candidates as shown in the attached file, and the
> > > completion delay is about 2-5 seconds.
> > >
> > > Any hints to improve this phenomenon?
> >
> > First, I'd try to isolate where the slowdown happens. The screenshots
> > suggests you are using company-mode with custom hacks to get the
> > numbering of candidates and you are using some fuzzy completion-style.
> >
> > So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get the
> > *Completions* buffer. That will probably be fast but deliver less
> > results because of the default value of `completion-styles'. Then I'd
> > try out your settings of `completion-styles' (and
>
> `C-h o completion-styles RET'
>
> completion-styles is a variable defined in ‘minibuffer.el’.
>
> Its value is (hotfuzz)
> Original value was
> (basic partial-completion emacs22)
I've the following configuration in my `~/.emacs.d/init.el':
(use-package hotfuzz
:init
(setq completion-styles '(hotfuzz)))
And it seems that commented out the above code snippet fixed the
problem discussed here.
HZ
>
> > `completion-category-overrides' if you have customized that).
>
> `C-h o completion-category-overrides RET'
>
> completion-category-overrides is a variable defined in ‘minibuffer.el’.
>
> Its value is nil
>
>
> > Then again with `company-mode' but first without the numbering hack, and
> > eventually with it. At which step does it become slow?
> >
> > Also, using the profiler might shed some light on where the time is
> > spent, see (info "(elisp) Profiling").
>
> `M-x profiler-start RET cpu and mem RET'
>
> Typeset (map) in scratch buffer, and then
>
> `M-x profiler-report RET', gives the following results:
>
>
> 262,542,852 87% - command-execute
> 262,542,852 87% - funcall-interactively
> 262,538,196 87% - counsel-M-x
> 262,538,196 87% - let
> 262,355,940 87% - ivy-read
> 262,355,940 87% - apply
> 262,354,884 87% + #<lambda 0x1b9d5ef2eb92a3f2>
> 182,256 0% + counsel--M-x-externs
> 4,656 0% + self-insert-command
> 36,160,744 12% + company-post-command
> 368,131 0% + redisplay_internal (C function)
> 135,480 0% + timer-event-handler
> 7,442 0% + eldoc-pre-command-refresh-echo-area
> 2,640 0% + highlight-parentheses--initiate-highlight
> 2,112 0% + jit-lock--antiblink-post-command
> 1,056 0% + company-pre-command
> 0 0% ...
>
> HZ
--
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 5:49 ` Tassilo Horn
@ 2021-10-20 6:11 ` Hongyi Zhao
2021-10-20 6:19 ` Tassilo Horn
2021-10-20 6:24 ` Hongyi Zhao
0 siblings, 2 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 6:11 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 1:58 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> First, I'd try to isolate where the slowdown happens. The
> >> screenshots suggests you are using company-mode with custom hacks to
> >> get the numbering of candidates and you are using some fuzzy
> >> completion-style.
> >>
> >> So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get
> >> the *Completions* buffer. That will probably be fast but deliver
> >> less results because of the default value of `completion-styles'.
> >> Then I'd try out your settings of `completion-styles' (and
> >
> > `C-h o completion-styles RET'
> >
> > completion-styles is a variable defined in ‘minibuffer.el’.
> >
> > Its value is (hotfuzz)
>
> Never heard of it.
See here:
https://github.com/axelf4/hotfuzz
> But is it a suitable catch-all completion style,
> i.e., suitable for using it without another more prefix-oriented style
> preceeding it? FWIW, when I type "(map", I'm most probably not
> interested in having smartparens-mode, or
> lsp:document-symbol-capabilities-hierarchical-document-symbol-support?
> showing up as the top candidates but more in mapcar, mapc, mapcan, you
> name it...
Agree with you.
> >> Also, using the profiler might shed some light on where the time is
> >> spent, see (info "(elisp) Profiling").
> >
> > `M-x profiler-start RET cpu and mem RET'
>
> I think you only need cpu here.
Thank you for pointing this out.
> > Typeset (map) in scratch buffer, and then
> >
> > `M-x profiler-report RET', gives the following results:
> >
> > 262,542,852 87% - command-execute
> > 262,542,852 87% - funcall-interactively
> > 262,538,196 87% - counsel-M-x
> > 262,538,196 87% - let
> > 262,355,940 87% - ivy-read
> > 262,355,940 87% - apply
> > 262,354,884 87% + #<lambda 0x1b9d5ef2eb92a3f2>
> > 182,256 0% + counsel--M-x-externs
>
> So the bottleneck is in the lambda which you didn't expand.
I disabled hotfuzz now, and the following result is obtained by
profiling the CPU with the same steps as described above:
472 88% - command-execute
472 88% - funcall-interactively
472 88% - counsel-M-x
472 88% - let
448 84% - ivy-read
448 84% - apply
444 83% + #<lambda 0x1b03f67daa2b12f2>
4 0% + my/company--transform-candidates
24 4% + counsel--M-x-externs
45 8% + ...
15 2% + redisplay_internal (C function)
> But I'm also not sure if you are profiling the right thing because I don't think
> that in-buffer completion (in terms of `completion-at-point-functions')
> starts with M-x (or counsel-M-x).
I'm not sure if it's relevant to the following configuration in my
`~/.emacs.d/init.el':
(use-package counsel
:diminish counsel-mode
:after helpful
:init (setq ivy-use-selectable-prompt t
search-default-mode #'char-fold-to-regexp
counsel-describe-function-function #'helpful-callable
counsel-describe-variable-function #'helpful-variable)
:bind (("M-x" . counsel-M-x)
;; https://github.com/alpha2phi/dotfiles/blob/7c8c2c1ac9cf1cf95d60323f49c19545cfcef555/config/emacs/elisp/completion.el#L21
;; ("C-x C-f" . counsel-fzf)
("C-x C-f" . counsel-find-file)
;;https://github.com/abo-abo/swiper/issues/2888#issuecomment-874893794
("C-x 8 RET" . counsel-unicode-char)
("<f4>" . counsel-bookmark)
("s-4" . counsel-bookmark)
("s-r" . counsel-recentf))
:config (counsel-mode 1)
(defalias 'recent 'counsel-recentf))
(define-key minibuffer-local-map (kbd "C-r") 'counsel-minibuffer-history)
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 6:11 ` Hongyi Zhao
@ 2021-10-20 6:19 ` Tassilo Horn
2021-10-20 6:42 ` Hongyi Zhao
2021-10-20 6:24 ` Hongyi Zhao
1 sibling, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-20 6:19 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> So the bottleneck is in the lambda which you didn't expand.
>
> I disabled hotfuzz now, and the following result is obtained by
> profiling the CPU with the same steps as described above:
>
> 472 88% - command-execute
> 472 88% - funcall-interactively
> 472 88% - counsel-M-x
> 472 88% - let
> 448 84% - ivy-read
> 448 84% - apply
> 444 83% + #<lambda 0x1b03f67daa2b12f2>
> 4 0% + my/company--transform-candidates
> 24 4% + counsel--M-x-externs
> 45 8% + ...
> 15 2% + redisplay_internal (C function)
Well, again you didn't expand the lambda where most of the time is
spent...
>> But I'm also not sure if you are profiling the right thing because I
>> don't think that in-buffer completion (in terms of
>> `completion-at-point-functions') starts with M-x (or counsel-M-x).
>
> I'm not sure if it's relevant to the following configuration in my
> `~/.emacs.d/init.el':
I also use corfu but I think now I know what happens. The thing is that
doing M-x profiler-report RET takes much longer (88% of the profiling
time) than computing the completion candidates. That is done in the
45 8% + ...
part which you should also expand.
When I do your recipe, the first 54% part is also the M-x
profiler-report RET part, and the
327 45% - ...
is the actual completion part (using vertico).
--8<---------------cut here---------------start------------->8---
391 54% - command-execute
391 54% - call-interactively
390 53% - byte-code
390 53% - read-extended-command
390 53% - completing-read
390 53% - completing-read-default
390 53% - apply
390 53% - vertico--advice
390 53% - apply
390 53% - #<compiled 0x8411fe8870440ec>
375 51% - read-from-minibuffer
357 49% + vertico--exhibit
5 0% + command-execute
1 0% + funcall-interactively
327 45% - ...
265 36% - or
265 36% - if
265 36% - let*
260 35% - unwind-protect
260 35% - progn
129 17% + corfu--recompute-candidates
121 16% + let*
10 1% + if
5 0% + if
62 8% Automatic GC
5 0% + timer-event-handler
--8<---------------cut here---------------end--------------->8---
HTH,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 6:11 ` Hongyi Zhao
2021-10-20 6:19 ` Tassilo Horn
@ 2021-10-20 6:24 ` Hongyi Zhao
1 sibling, 0 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 6:24 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 2:11 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 1:58 PM Tassilo Horn <tsdh@gnu.org> wrote:
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > >> First, I'd try to isolate where the slowdown happens. The
> > >> screenshots suggests you are using company-mode with custom hacks to
> > >> get the numbering of candidates and you are using some fuzzy
> > >> completion-style.
> > >>
> > >> So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get
> > >> the *Completions* buffer. That will probably be fast but deliver
> > >> less results because of the default value of `completion-styles'.
> > >> Then I'd try out your settings of `completion-styles' (and
> > >
> > > `C-h o completion-styles RET'
> > >
> > > completion-styles is a variable defined in ‘minibuffer.el’.
> > >
> > > Its value is (hotfuzz)
> >
> > Never heard of it.
>
> See here:
>
> https://github.com/axelf4/hotfuzz
>
> > But is it a suitable catch-all completion style,
> > i.e., suitable for using it without another more prefix-oriented style
> > preceeding it? FWIW, when I type "(map", I'm most probably not
> > interested in having smartparens-mode, or
> > lsp:document-symbol-capabilities-hierarchical-document-symbol-support?
> > showing up as the top candidates but more in mapcar, mapc, mapcan, you
> > name it...
>
> Agree with you.
>
> > >> Also, using the profiler might shed some light on where the time is
> > >> spent, see (info "(elisp) Profiling").
> > >
> > > `M-x profiler-start RET cpu and mem RET'
> >
> > I think you only need cpu here.
>
> Thank you for pointing this out.
>
> > > Typeset (map) in scratch buffer, and then
> > >
> > > `M-x profiler-report RET', gives the following results:
> > >
> > > 262,542,852 87% - command-execute
> > > 262,542,852 87% - funcall-interactively
> > > 262,538,196 87% - counsel-M-x
> > > 262,538,196 87% - let
> > > 262,355,940 87% - ivy-read
> > > 262,355,940 87% - apply
> > > 262,354,884 87% + #<lambda 0x1b9d5ef2eb92a3f2>
> > > 182,256 0% + counsel--M-x-externs
> >
> > So the bottleneck is in the lambda which you didn't expand.
>
> I disabled hotfuzz now, and the following result is obtained by
> profiling the CPU with the same steps as described above:
>
> 472 88% - command-execute
> 472 88% - funcall-interactively
> 472 88% - counsel-M-x
> 472 88% - let
> 448 84% - ivy-read
> 448 84% - apply
> 444 83% + #<lambda 0x1b03f67daa2b12f2>
> 4 0% + my/company--transform-candidates
> 24 4% + counsel--M-x-externs
> 45 8% + ...
> 15 2% + redisplay_internal (C function)
>
>
> > But I'm also not sure if you are profiling the right thing because I don't think
> > that in-buffer completion (in terms of `completion-at-point-functions')
> > starts with M-x (or counsel-M-x).
>
> I'm not sure if it's relevant to the following configuration in my
> `~/.emacs.d/init.el':
>
> (use-package counsel
> :diminish counsel-mode
> :after helpful
> :init (setq ivy-use-selectable-prompt t
> search-default-mode #'char-fold-to-regexp
> counsel-describe-function-function #'helpful-callable
> counsel-describe-variable-function #'helpful-variable)
> :bind (("M-x" . counsel-M-x)
`C-h o counsel-M-x RET' gives the following:
counsel-M-x is an interactive Lisp closure in ‘counsel.el’.
It is bound to <execute>, M-x.
So it is unnecessary to set the above key binding. And the profiling
results are as follows without this keybinding:
3056 55% - command-execute
3056 55% - funcall-interactively
1227 22% - counsel-M-x
1227 22% - let
1132 20% - ivy-read
1132 20% - apply
1132 20% + #<lambda 0x1c18740442433ef2>
95 1% + counsel--M-x-externs
989 18% + next-line
622 11% + counsel-describe-symbol
123 2% + save-buffer
46 0% + recentf-open-most-recent-file-1
30 0% mwheel-scroll
12 0% + swiper
6 0% + kill-whole-line
1 0% #<compiled 0x12193bdf30bd6a1b>
1357 24% + ...
516 9% + redisplay_internal (C function)
500 9% + timer-event-handler
33 0% + substitute-command-keys
> ;; https://github.com/alpha2phi/dotfiles/blob/7c8c2c1ac9cf1cf95d60323f49c19545cfcef555/config/emacs/elisp/completion.el#L21
> ;; ("C-x C-f" . counsel-fzf)
> ("C-x C-f" . counsel-find-file)
> ;;https://github.com/abo-abo/swiper/issues/2888#issuecomment-874893794
> ("C-x 8 RET" . counsel-unicode-char)
> ("<f4>" . counsel-bookmark)
> ("s-4" . counsel-bookmark)
> ("s-r" . counsel-recentf))
> :config (counsel-mode 1)
> (defalias 'recent 'counsel-recentf))
> (define-key minibuffer-local-map (kbd "C-r") 'counsel-minibuffer-history)
>
> HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 6:19 ` Tassilo Horn
@ 2021-10-20 6:42 ` Hongyi Zhao
2021-10-20 7:20 ` Tassilo Horn
2021-10-20 7:24 ` Hongyi Zhao
0 siblings, 2 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 6:42 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 2:25 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> So the bottleneck is in the lambda which you didn't expand.
> >
> > I disabled hotfuzz now, and the following result is obtained by
> > profiling the CPU with the same steps as described above:
> >
> > 472 88% - command-execute
> > 472 88% - funcall-interactively
> > 472 88% - counsel-M-x
> > 472 88% - let
> > 448 84% - ivy-read
> > 448 84% - apply
> > 444 83% + #<lambda 0x1b03f67daa2b12f2>
> > 4 0% + my/company--transform-candidates
> > 24 4% + counsel--M-x-externs
> > 45 8% + ...
> > 15 2% + redisplay_internal (C function)
>
> Well, again you didn't expand the lambda where most of the time is
> spent...
To be frank, I don't know how to expand it.
> >> But I'm also not sure if you are profiling the right thing because I
> >> don't think that in-buffer completion (in terms of
> >> `completion-at-point-functions') starts with M-x (or counsel-M-x).
> >
> > I'm not sure if it's relevant to the following configuration in my
> > `~/.emacs.d/init.el':
>
> I also use corfu but I think now I know what happens. The thing is that
> doing M-x profiler-report RET takes much longer (88% of the profiling
> time) than computing the completion candidates. That is done in the
>
> 45 8% + ...
>
> part which you should also expand.
Again, I don't know how to expand it.
> When I do your recipe, the first 54% part is also the M-x
> profiler-report RET part, and the
>
> 327 45% - ...
>
> is the actual completion part (using vertico).
I don't use corfu [1] and vertico [2], but thank you for letting me
your configuration.
[1] https://github.com/minad/corfu
[2] https://github.com/minad/vertico
> --8<---------------cut here---------------start------------->8---
> 391 54% - command-execute
> 391 54% - call-interactively
> 390 53% - byte-code
> 390 53% - read-extended-command
> 390 53% - completing-read
> 390 53% - completing-read-default
> 390 53% - apply
> 390 53% - vertico--advice
> 390 53% - apply
> 390 53% - #<compiled 0x8411fe8870440ec>
> 375 51% - read-from-minibuffer
> 357 49% + vertico--exhibit
> 5 0% + command-execute
> 1 0% + funcall-interactively
> 327 45% - ...
> 265 36% - or
> 265 36% - if
> 265 36% - let*
> 260 35% - unwind-protect
> 260 35% - progn
> 129 17% + corfu--recompute-candidates
> 121 16% + let*
> 10 1% + if
> 5 0% + if
> 62 8% Automatic GC
> 5 0% + timer-event-handler
> --8<---------------cut here---------------end--------------->8---
Anyway, after disabling the hotfuzz, the completion delay has been
reduced to an acceptable time.
[3] https://github.com/axelf4/hotfuzz
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 6:42 ` Hongyi Zhao
@ 2021-10-20 7:20 ` Tassilo Horn
2021-10-20 7:35 ` Hongyi Zhao
2021-10-21 5:32 ` Hongyi Zhao
2021-10-20 7:24 ` Hongyi Zhao
1 sibling, 2 replies; 22+ messages in thread
From: Tassilo Horn @ 2021-10-20 7:20 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> I also use corfu but I think now I know what happens. The thing is
>> that doing M-x profiler-report RET takes much longer (88% of the
>> profiling time) than computing the completion candidates. That is
>> done in the
>>
>> 45 8% + ...
>>
>> part which you should also expand.
>
> Again, I don't know how to expand it.
You hit RET on the line.
> Anyway, after disabling the hotfuzz, the completion delay has been
> reduced to an acceptable time.
That's what I guessed. It might make sense to have some fuzzy style
(like hotfuzz or the built-in flex) as last entry in
`completion-styles', though. FWIW, I use
(setq completion-styles '(partial-completion substring flex))
and
(setq completion-category-overrides
'((project-file
(styles partial-completion substring initials))
(file
(styles partial-completion substring initials))
(eglot
(styles partial-completion substring))))
Bye,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 6:42 ` Hongyi Zhao
2021-10-20 7:20 ` Tassilo Horn
@ 2021-10-20 7:24 ` Hongyi Zhao
2021-10-20 7:37 ` Tassilo Horn
1 sibling, 1 reply; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 7:24 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 2:42 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 2:25 PM Tassilo Horn <tsdh@gnu.org> wrote:
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > >> So the bottleneck is in the lambda which you didn't expand.
> > >
> > > I disabled hotfuzz now, and the following result is obtained by
> > > profiling the CPU with the same steps as described above:
> > >
> > > 472 88% - command-execute
> > > 472 88% - funcall-interactively
> > > 472 88% - counsel-M-x
> > > 472 88% - let
> > > 448 84% - ivy-read
> > > 448 84% - apply
> > > 444 83% + #<lambda 0x1b03f67daa2b12f2>
> > > 4 0% + my/company--transform-candidates
> > > 24 4% + counsel--M-x-externs
> > > 45 8% + ...
> > > 15 2% + redisplay_internal (C function)
> >
> > Well, again you didn't expand the lambda where most of the time is
> > spent...
>
> To be frank, I don't know how to expand it.
Shame on me. It can be expanded by clicking the + sign again and
again. See the following:
495 86% - command-execute
495 86% - funcall-interactively
487 85% - counsel-M-x
487 85% - let
458 80% - ivy-read
458 80% - apply
454 79% - #<lambda 0x1de0670da47deef2>
454 79% - let*
454 79% - progn
454 79% - progn
454 79% - let*
404 70% - ivy--reset-state
404 70% - let*
404 70% - let
344 60% - if
340 59% - progn
340 59% - setq
336 58% - sort
308 54% - ivy-prescient-sort-function
264 46% - prescient-sort-compare
180 31% - let
172 30% - progn
160 28% - let*
124 21% - or
116 20% - and
64 11% - let*
36 6% - or
32 5% - and
20 3% <
4 0% - if
4 0% and
4 0% - and
4 0% null
60 10% - cond
60 10% - let
60 10% - setq
44 7% - all-completions
36 6% - #<lambda 0x543b56196f44733>
36 6% - and
4 0% - not
4 0% get
39 6% - unwind-protect
39 6% - let
39 6% - unwind-protect
39 6% - progn
39 6% - let*
39 6% - if
39 6% - condition-case
35 6% - read-from-minibuffer
21 3% - ivy--queue-exhibit
21 3% - if
21 3% - ivy--exhibit
21 3% - if
21 3% - progn
21 3% - let
21 3% - ivy--update-minibuffer
21 3% - prog1
21 3% - if
11 1% - save-current-buffer
11 1% + ivy--format
10 1% + progn
3 0% + redisplay_internal (C function)
11 1% + ivy-call
4 0% + posframe-show
29 5% - counsel--M-x-externs
29 5% cond
8 1% - self-insert-command
8 1% - hideshowvis-highlight-hs-regions-in-fringe
8 1% - if
8 1% - progn
8 1% - save-excursion
8 1% - save-restriction
8 1% while
65 11% - ...
44 7% - completion-all-completions
44 7% - completion--nth-completion
44 7% - completion--some
44 7% - #<compiled 0x194abcb52c81cd5e>
44 7% - orderless-all-completions
44 7% - let
44 7% - orderless-filter
44 7% - let
44 7% - unwind-protect
44 7% - progn
44 7% - let*
44 7% - progn
44 7% - let*
44 7% - let
44 7% - let*
44 7% progn
13 2% - window-text-pixel-size
13 2% - jit-lock-function
13 2% - jit-lock-fontify-now
13 2% - jit-lock--run-functions
13 2% - run-hook-wrapped
13 2% - #<compiled 0x19ba2d83e5235cbd>
13 2% - adaptive-wrap-prefix-function
13 2% - while
13 2% - let
5 0% - company-call-backend
5 0% - company--force-sync
5 0% - let
5 0% - apply
5 0% - company-call-backend-raw
5 0% - condition-case
5 0% - if
5 0% - apply
5 0% - company-capf
5 0% - apply
5 0% - company-anywhere-capf
5 0% - if
5 0% - apply
5 0% - #<lambda -0x10ca152207b458d5>
5 0% cond
4 0% - nconc
4 0% - if
4 0% - orderless-highlight-matches
4 0% - let*
4 0% - while
4 0% - setq
4 0% - cons
4 0% - orderless--highlight
4 0% - let*
4 0% - let
4 0% - while
4 0% - if
4 0% - progn
4 0% - let*
4 0% let
4 0% - put-text-property
4 0% - let
4 0% - adaptive-wrap-fill-context-prefix
4 0% - let*
4 0% - or
4 0% - let
4 0% fill-context-prefix
8 1% - ivy--filter
8 1% - let
8 1% - if
8 1% - let*
8 1% - cond
8 1% - ivy--re-filter
8 1% - if
8 1% - condition-case
8 1% - progn
8 1% - let
8 1% - while
8 1% - let
8 1% - let*
8 1% - setq
4 0% + company-calculate-candidates
4 0% + cl-remove
0 0% Automatic GC
10 1% + redisplay_internal (C function)
> > >> But I'm also not sure if you are profiling the right thing because I
> > >> don't think that in-buffer completion (in terms of
> > >> `completion-at-point-functions') starts with M-x (or counsel-M-x).
> > >
> > > I'm not sure if it's relevant to the following configuration in my
> > > `~/.emacs.d/init.el':
> >
> > I also use corfu but I think now I know what happens. The thing is that
> > doing M-x profiler-report RET takes much longer (88% of the profiling
> > time) than computing the completion candidates. That is done in the
> >
> > 45 8% + ...
> >
> > part which you should also expand.
>
> Again, I don't know how to expand it.
>
> > When I do your recipe, the first 54% part is also the M-x
> > profiler-report RET part, and the
> >
> > 327 45% - ...
> >
> > is the actual completion part (using vertico).
>
> I don't use corfu [1] and vertico [2], but thank you for letting me
> your configuration.
>
> [1] https://github.com/minad/corfu
> [2] https://github.com/minad/vertico
>
>
> > --8<---------------cut here---------------start------------->8---
> > 391 54% - command-execute
> > 391 54% - call-interactively
> > 390 53% - byte-code
> > 390 53% - read-extended-command
> > 390 53% - completing-read
> > 390 53% - completing-read-default
> > 390 53% - apply
> > 390 53% - vertico--advice
> > 390 53% - apply
> > 390 53% - #<compiled 0x8411fe8870440ec>
> > 375 51% - read-from-minibuffer
> > 357 49% + vertico--exhibit
> > 5 0% + command-execute
> > 1 0% + funcall-interactively
> > 327 45% - ...
> > 265 36% - or
> > 265 36% - if
> > 265 36% - let*
> > 260 35% - unwind-protect
> > 260 35% - progn
> > 129 17% + corfu--recompute-candidates
> > 121 16% + let*
> > 10 1% + if
> > 5 0% + if
> > 62 8% Automatic GC
> > 5 0% + timer-event-handler
> > --8<---------------cut here---------------end--------------->8---
>
> Anyway, after disabling the hotfuzz, the completion delay has been
> reduced to an acceptable time.
>
> [3] https://github.com/axelf4/hotfuzz
>
> HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 7:20 ` Tassilo Horn
@ 2021-10-20 7:35 ` Hongyi Zhao
2021-10-21 5:32 ` Hongyi Zhao
1 sibling, 0 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 7:35 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 3:24 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> I also use corfu but I think now I know what happens. The thing is
> >> that doing M-x profiler-report RET takes much longer (88% of the
> >> profiling time) than computing the completion candidates. That is
> >> done in the
> >>
> >> 45 8% + ...
> >>
> >> part which you should also expand.
> >
> > Again, I don't know how to expand it.
>
> You hit RET on the line.
>
> > Anyway, after disabling the hotfuzz, the completion delay has been
> > reduced to an acceptable time.
>
> That's what I guessed. It might make sense to have some fuzzy style
> (like hotfuzz or the built-in flex) as last entry in
> `completion-styles', though. FWIW, I use
>
> (setq completion-styles '(partial-completion substring flex))
>
> and
>
> (setq completion-category-overrides
> '((project-file
> (styles partial-completion substring initials))
> (file
> (styles partial-completion substring initials))
> (eglot
> (styles partial-completion substring))))
Thank you for sharing your experience.
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 7:24 ` Hongyi Zhao
@ 2021-10-20 7:37 ` Tassilo Horn
2021-10-20 9:17 ` Hongyi Zhao
0 siblings, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-20 7:37 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> To be frank, I don't know how to expand it.
>
> Shame on me. It can be expanded by clicking the + sign again and
> again.
Hehe. :-)
> See the following:
>
> 495 86% - command-execute
> 495 86% - funcall-interactively
> 487 85% - counsel-M-x
> 487 85% - let
> 458 80% - ivy-read
> 458 80% - apply
> 454 79% - #<lambda 0x1de0670da47deef2>
> 454 79% - let*
> 454 79% - progn
> 454 79% - progn
> 454 79% - let*
> 404 70% - ivy--reset-state
> 404 70% - let*
> 404 70% - let
> 344 60% - if
> 340 59% - progn
> 340 59% - setq
> 336 58% - sort
> 308 54% - ivy-prescient-sort-function
> 264 46% - prescient-sort-compare
So here you can see that prescient seems to have quite some impact on
sorting the candidates for M-x.
> 65 11% - ...
> 44 7% - completion-all-completions
> 44 7% - completion--nth-completion
> 44 7% - completion--some
> 44 7% - #<compiled 0x194abcb52c81cd5e>
> 44 7% - orderless-all-completions
> 44 7% - let
> 44 7% - orderless-filter
> 44 7% - let
> 44 7% - unwind-protect
> 44 7% - progn
> 44 7% - let*
> 44 7% - progn
> 44 7% - let*
> 44 7% - let
> 44 7% - let*
> 44 7% progn
And the above is the actual "(map" completion part which seems to be
dominated by the orderless style. So I guess you've now replaced
hotfuzz with orderless, right?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 7:37 ` Tassilo Horn
@ 2021-10-20 9:17 ` Hongyi Zhao
0 siblings, 0 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-20 9:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 3:42 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> To be frank, I don't know how to expand it.
> >
> > Shame on me. It can be expanded by clicking the + sign again and
> > again.
>
> Hehe. :-)
>
> > See the following:
> >
> > 495 86% - command-execute
> > 495 86% - funcall-interactively
> > 487 85% - counsel-M-x
> > 487 85% - let
> > 458 80% - ivy-read
> > 458 80% - apply
> > 454 79% - #<lambda 0x1de0670da47deef2>
> > 454 79% - let*
> > 454 79% - progn
> > 454 79% - progn
> > 454 79% - let*
> > 404 70% - ivy--reset-state
> > 404 70% - let*
> > 404 70% - let
> > 344 60% - if
> > 340 59% - progn
> > 340 59% - setq
> > 336 58% - sort
> > 308 54% - ivy-prescient-sort-function
> > 264 46% - prescient-sort-compare
>
> So here you can see that prescient seems to have quite some impact on
> sorting the candidates for M-x.
I use the following prescient relevant configuration:
--8<---------------cut here---------------start------------->8---
;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient
(use-package prescient
:diminish
:config
(prescient-persist-mode)
)
;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient-1
(use-package company-prescient
:init (setq ;;https://github.com/company-mode/company-mode/issues/1141#issuecomment-884570548
company-prescient-sort-length-enable nil)
:config
(company-prescient-mode 1)
)
;;https://github.com/abo-abo/swiper/issues/2899#issuecomment-890300284
(use-package ivy-prescient
:init
(setq prescient-filter-method '(literal fuzzy regexp initialism)
;;https://github.com/raxod502/prescient.el#ivy-specific
ivy-prescient-enable-filtering nil)
:config
;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient
(ivy-prescient-mode 1) ; According to my attempt, use this
configuration in :init will defeat swiper
)
--8<---------------cut here---------------end------------->8---
> > 65 11% - ...
> > 44 7% - completion-all-completions
> > 44 7% - completion--nth-completion
> > 44 7% - completion--some
> > 44 7% - #<compiled 0x194abcb52c81cd5e>
> > 44 7% - orderless-all-completions
> > 44 7% - let
> > 44 7% - orderless-filter
> > 44 7% - let
> > 44 7% - unwind-protect
> > 44 7% - progn
> > 44 7% - let*
> > 44 7% - progn
> > 44 7% - let*
> > 44 7% - let
> > 44 7% - let*
> > 44 7% progn
>
> And the above is the actual "(map" completion part which seems to be
> dominated by the orderless style. So I guess you've now replaced
> hotfuzz with orderless, right?
To be frank, due to my negligence, I've set orderless first and then
hotfuzz in the init.el file at the same time. The following is the
configuration of orderless:
(use-package orderless
:init (icomplete-mode)
:custom (completion-styles '(orderless)))
After I disabled the hotfuzz, the orderless comes into play. But
fortunately, it seems that orderless doesn't have so much penalty on
performance. For convenience's sake, I decided to stick with it.
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [External] : Re: Too long completion delay time in LISP interaction mode.
2021-10-20 5:58 ` Hongyi Zhao
@ 2021-10-20 15:30 ` Drew Adams
0 siblings, 0 replies; 22+ messages in thread
From: Drew Adams @ 2021-10-20 15:30 UTC (permalink / raw)
To: Hongyi Zhao, Tassilo Horn; +Cc: help-gnu-emacs
> I've the following configuration in my
> `~/.emacs.d/init.el':
>
> (use-package hotfuzz
> :init
> (setq completion-styles '(hotfuzz)))
>
> And it seems that commented out the above code
> snippet fixed the problem discussed here.
That's often the first thing to try, when
fumbling in the dark. Just bisect your
init file till you find the culprit.
That's quick to do (though at first it
seems not to be quick). You can use
`comment-region' to comment out a block
of code (a prefix arg uncomments). Do
that to 1/2, then 1/4, 1/8, 1/16,... of
your init file.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-20 7:20 ` Tassilo Horn
2021-10-20 7:35 ` Hongyi Zhao
@ 2021-10-21 5:32 ` Hongyi Zhao
2021-10-21 5:45 ` Tassilo Horn
1 sibling, 1 reply; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-21 5:32 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Wed, Oct 20, 2021 at 3:24 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> I also use corfu but I think now I know what happens. The thing is
> >> that doing M-x profiler-report RET takes much longer (88% of the
> >> profiling time) than computing the completion candidates. That is
> >> done in the
> >>
> >> 45 8% + ...
> >>
> >> part which you should also expand.
> >
> > Again, I don't know how to expand it.
>
> You hit RET on the line.
>
> > Anyway, after disabling the hotfuzz, the completion delay has been
> > reduced to an acceptable time.
>
> That's what I guessed. It might make sense to have some fuzzy style
> (like hotfuzz or the built-in flex) as last entry in
> `completion-styles', though. FWIW, I use
>
> (setq completion-styles '(partial-completion substring flex))
>
> and
>
> (setq completion-category-overrides
> '((project-file
> (styles partial-completion substring initials))
> (file
> (styles partial-completion substring initials))
> (eglot
Can the above line be changed into the following?
((eglot lsp)
> (styles partial-completion substring))))
>
> Bye,
> Tassilo
--
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-21 5:32 ` Hongyi Zhao
@ 2021-10-21 5:45 ` Tassilo Horn
2021-10-21 6:14 ` Hongyi Zhao
0 siblings, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-21 5:45 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> (setq completion-category-overrides
>> '((project-file
>> (styles partial-completion substring initials))
>> (file
>> (styles partial-completion substring initials))
>> (eglot
>
> Can the above line be changed into the following?
>
> ((eglot lsp)
The docs suggest that the keys are one CATEGORY, not a list of
categories. But you can duplicate the eglot entry for lsp, assuming
that lsp-mode defines its own completion category which I don't know
(since I use eglot for my LSP interaction).
Bye,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-21 5:45 ` Tassilo Horn
@ 2021-10-21 6:14 ` Hongyi Zhao
2021-10-21 8:50 ` Tassilo Horn
0 siblings, 1 reply; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-21 6:14 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Thu, Oct 21, 2021 at 1:47 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> (setq completion-category-overrides
> >> '((project-file
> >> (styles partial-completion substring initials))
> >> (file
> >> (styles partial-completion substring initials))
> >> (eglot
> >
> > Can the above line be changed into the following?
> >
> > ((eglot lsp)
>
> The docs suggest that the keys are one CATEGORY, not a list of
> categories. But you can duplicate the eglot entry for lsp,
Thank you for pointing this out.
> assuming that lsp-mode defines its own completion category which I don't know
> (since I use eglot for my LSP interaction).
They are defined as follows:
https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745
(make-local-variable 'completion-category-defaults)
(setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
(lsp-passthrough))))
https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L775
(setq-local completion-category-defaults
(cl-remove 'lsp-capf completion-category-defaults :key #'cl-first))
So, I adjusted to the following configuration based on orderless package:
(use-package orderless
:config
;; https://github.com/oantolin/orderless#ivy
(setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
completion-styles '(partial-completion substring flex orderless)
completion-category-overrides
'((project-file
(styles partial-completion substring initials))
(file
(styles partial-completion substring initials))
(eglot
(styles partial-completion substring))
(lsp
(styles partial-completion substring))
)))
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-21 6:14 ` Hongyi Zhao
@ 2021-10-21 8:50 ` Tassilo Horn
2021-10-21 10:38 ` Hongyi Zhao
0 siblings, 1 reply; 22+ messages in thread
From: Tassilo Horn @ 2021-10-21 8:50 UTC (permalink / raw)
To: Hongyi Zhao; +Cc: help-gnu-emacs
Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> assuming that lsp-mode defines its own completion category which I don't know
>> (since I use eglot for my LSP interaction).
>
> They are defined as follows:
>
> https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745
>
> (make-local-variable 'completion-category-defaults)
> (setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
> (lsp-passthrough))))
That might suggest that lsp-mode wants its own `lsp-passthrough' style
and nothing else, not sure.
> So, I adjusted to the following configuration based on orderless package:
>
> (use-package orderless
> :config
> ;; https://github.com/oantolin/orderless#ivy
> (setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
> completion-styles '(partial-completion substring flex orderless)
> completion-category-overrides
> '((project-file
> (styles partial-completion substring initials))
> (file
> (styles partial-completion substring initials))
> (eglot
> (styles partial-completion substring))
> (lsp
> (styles partial-completion substring))
The definition you've cited says `lsp-capf', not just `lsp'.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Too long completion delay time in LISP interaction mode.
2021-10-21 8:50 ` Tassilo Horn
@ 2021-10-21 10:38 ` Hongyi Zhao
0 siblings, 0 replies; 22+ messages in thread
From: Hongyi Zhao @ 2021-10-21 10:38 UTC (permalink / raw)
To: Tassilo Horn; +Cc: help-gnu-emacs
On Thu, Oct 21, 2021 at 4:53 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> assuming that lsp-mode defines its own completion category which I don't know
> >> (since I use eglot for my LSP interaction).
> >
> > They are defined as follows:
> >
> > https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745
> >
> > (make-local-variable 'completion-category-defaults)
> > (setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
> > (lsp-passthrough))))
>
> That might suggest that lsp-mode wants its own `lsp-passthrough' style
> and nothing else, not sure.
>
> > So, I adjusted to the following configuration based on orderless package:
> >
> > (use-package orderless
> > :config
> > ;; https://github.com/oantolin/orderless#ivy
> > (setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
> > completion-styles '(partial-completion substring flex orderless)
> > completion-category-overrides
> > '((project-file
> > (styles partial-completion substring initials))
> > (file
> > (styles partial-completion substring initials))
> > (eglot
> > (styles partial-completion substring))
> > (lsp
> > (styles partial-completion substring))
>
> The definition you've cited says `lsp-capf', not just `lsp'.
Thank you for pointing this out.
HZ
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2021-10-21 10:38 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-10-20 3:11 Too long completion delay time in LISP interaction mode Hongyi Zhao
2021-10-20 4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-10-20 4:27 ` Hongyi Zhao
2021-10-20 5:01 ` Tassilo Horn
2021-10-20 5:29 ` Hongyi Zhao
2021-10-20 5:49 ` Tassilo Horn
2021-10-20 6:11 ` Hongyi Zhao
2021-10-20 6:19 ` Tassilo Horn
2021-10-20 6:42 ` Hongyi Zhao
2021-10-20 7:20 ` Tassilo Horn
2021-10-20 7:35 ` Hongyi Zhao
2021-10-21 5:32 ` Hongyi Zhao
2021-10-21 5:45 ` Tassilo Horn
2021-10-21 6:14 ` Hongyi Zhao
2021-10-21 8:50 ` Tassilo Horn
2021-10-21 10:38 ` Hongyi Zhao
2021-10-20 7:24 ` Hongyi Zhao
2021-10-20 7:37 ` Tassilo Horn
2021-10-20 9:17 ` Hongyi Zhao
2021-10-20 6:24 ` Hongyi Zhao
2021-10-20 5:58 ` Hongyi Zhao
2021-10-20 15:30 ` [External] : " Drew Adams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).