unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: Add user customization fido-completion-styles
Date: Tue, 02 Jun 2020 18:51:31 +0100	[thread overview]
Message-ID: <87sgfdl5jw.fsf@gmail.com> (raw)
In-Reply-To: <3483a8d9-1474-45cf-afad-8d276b96ef3f@default> (Drew Adams's message of "Tue, 2 Jun 2020 09:14:42 -0700 (PDT)")

Drew Adams <drew.adams@oracle.com> writes:

> As for performance, for `M-x' there certainly is
> no problem.  `M-x' with no input pattern to match
> shows the 6000-some candidates immediately.

Certainly it doesn't _show_ 6000 candidates, right? You must mean it
calculates them quickly and shows the top-sorting set quickly.  That's
great, I guess, and I join in asking if Emacs shouldn't do that.

I didnt' dig down very intensively, but my naive profiling shows the
bulk of the work to be in `all-completions' or thereabouts to be the
main sink of cpu time:

       - icomplete-post-command-hook                             2032  86%
        - icomplete-exhibit                                      2032  86%
         - icomplete-completions                                 2009  85%
          - icomplete--sorted-completions                        1986  84%
           - completion-all-sorted-completions                   1986  84%
            - completion-all-completions                         1982  84%
             - completion--nth-completion                        1982  84%
              - completion--some                                 1982  84%
               - #<compiled 0x15809f8924ad>                      1982  84%
                - completion-flex-all-completions                1965  84%
                 - completion-substring--all-completions         1935  82%
                  - completion-pcm--all-completions              1932  82%
                   - all-completions                             1929  82%
                    - #<compiled 0x1fe57a0ac19d>                 1929  82%
                     - complete-with-action                      1929  82%
                      - all-completions                            37   1%

As you know, all-completions is a C function.  The 1% is suspicious, I
don't know if I should trust it.

Anyway, I'm curious how Icycles evades this.

Anyway2, I wasn't trying this in an Emacs -Q.  When I do, and I set
icomplete-compute-delay to 0, then M-x is practically instantaneous.

Maybe the default 0.3 value of that variable is excessively
conservative.

So, to summarize: I do believe could be some shortcuts for the notable
case of no input pattern to give a speed boost, maybe showing them them
their relevant minibuffer history.  I don't believe there's some kind of
magical speed pickup to be had.

Even the C rewrite of parts of completion-pcm--all-completions
now seems dubious.

> This way of combining yes-no-maybe predicates is
> described here:
>
> https://www.emacswiki.org/emacs/ApplesAndOranges

Have you tried `fido-mode` and/or flex?  Can you think of specific ways
to improve it?  If so, patches are very welcome.

It's a bit harder, I admit, to try to learn Icicles and decide which
features to migrate.  But if you can point some laser-targeted
improvement to the flex algorithm (in efficiency of functionality) are
very welcome.

João



  reply	other threads:[~2020-06-02 17:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 21:02 Add user customization fido-completion-styles Andrew Schwartzmeyer
2020-05-31 23:43 ` João Távora
2020-05-31 23:59   ` Dmitry Gutov
2020-06-01  0:21     ` João Távora
2020-06-01  0:37   ` Andrew Schwartzmeyer
2020-06-01  4:37     ` Andrew Schwartzmeyer
2020-06-02 11:14       ` João Távora
2020-06-02 16:14         ` Drew Adams
2020-06-02 17:51           ` João Távora [this message]
2020-06-02 18:11             ` Eli Zaretskii
2020-06-02 18:24               ` João Távora
2020-06-02 18:35                 ` Eli Zaretskii
2020-06-02 19:11                   ` João Távora
2020-06-02 19:25                     ` Eli Zaretskii
2020-06-02 20:00                       ` João Távora
2020-06-02 20:51             ` Drew Adams
2020-06-02 15:40   ` Tassilo Horn
2020-06-02 15:55     ` João Távora
2020-06-02 16:47       ` Tassilo Horn
2020-06-02 17:03         ` João Távora
2020-06-02 18:05           ` Tassilo Horn
2020-06-02 17:10         ` Tassilo Horn
2020-06-02 19:28           ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgfdl5jw.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).