From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Date: Sun, 6 Jun 2021 19:37:05 +0100 Message-ID: References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fd8ce305c41d365f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="355"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 48841@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 06 20:39:40 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpxgR-000AQA-QO for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Jun 2021 20:39:39 +0200 Original-Received: from localhost ([::1]:54100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpxgQ-0000TL-Ra for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Jun 2021 14:39:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56968) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpxes-0008VW-Uj for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 14:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42335) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpxes-0007eT-NU for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 14:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lpxes-0002Zg-J9 for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 14:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16230046499857 (code B ref 48841); Sun, 06 Jun 2021 18:38:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 18:37:29 +0000 Original-Received: from localhost ([127.0.0.1]:53881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpxeL-0002Yv-23 for submit@debbugs.gnu.org; Sun, 06 Jun 2021 14:37:29 -0400 Original-Received: from mail-pg1-f170.google.com ([209.85.215.170]:43905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpxeH-0002Yg-BD for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 14:37:27 -0400 Original-Received: by mail-pg1-f170.google.com with SMTP id e22so12096118pgv.10 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 11:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UayIdd/Hmwygy0E2HCpjkNrLxmEM9NXMmDfmmL2aajU=; b=BMNjqeEQZdYXqcjbcm8Zod9A7qO4zTps07KMJhftuQn+JKG0yFwmz2QXkTBG0OnRUY /vGK9SxawMe6VSywEUy2sueO9c1LQvI9VLVHw70ItskrwVHWHChN3442P/kyPYTfVaYm pfFCq+UJEpelkj+muVBGEN6xt9c0kxJddaVHCDGF+lFhzo0D4p1UMMSD0hQ5J0QQkS3o mbLz4S2x4+vE3iaw5L67BIoohc/uzge3otwBuxeMY9mkXkzBoyPSWJPfcIpqXYSe+4sL HF2KLaTVxXiqPLKbznCPGLjGMoD7rXKB1kyusn41ULVLBKS6PSJA7XBg7ZoqRBs65ReV KEzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UayIdd/Hmwygy0E2HCpjkNrLxmEM9NXMmDfmmL2aajU=; b=Lz8H80plUwjHK7LfECuCJ6ptHy7uJe8gmp0VY2J7Q3JZqlQRjGesUOIz5dt38Ezza8 4JVvCnU9aaBpa1ffOphyI6T22qU94DQm4R9lENAj7EkcgHurB6JhC8q/pASYkzfwKkx4 lLg9xFl34lKnylR8z01+LjokGr8LCYOTXYj2f8lvdqqmmQPbzcrW3H8IptpDwp4Jvcis QJ/h+wEr7Y3K7LTEiY79tBmFwdc8Nrb7AQC+N7lEdaBVn7wt7tkfjReTRZD8v9e2ST6n G1Gk/ipTa2JhV91qIOGlhJluNgtBExj2LVqV8leoH8Q2IXXwvSvEBbD9wHgpZIgPzOuU 3cQg== X-Gm-Message-State: AOAM532MDgShfDkz5N8mWKmAzDMcLZN/wA0VE0k0dSzo31uMwF2jthVv ++9C/4NK/dxDzZqltXzgyjI9ypg4BZtamDI2Z+8= X-Google-Smtp-Source: ABdhPJz41XdKUlX0GgmTlPGJ83qQkJUwTPsfFZNzXPI6tygAlsXvU79h1t9+vCXmvB7Ba0Rt1p5ZRgrRDV18EfJW5yg= X-Received: by 2002:a62:5547:0:b029:2ec:8f20:4e2 with SMTP id j68-20020a6255470000b02902ec8f2004e2mr12011622pfb.71.1623004639234; Sun, 06 Jun 2021 11:37:19 -0700 (PDT) In-Reply-To: <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208151 Archived-At: --000000000000fd8ce305c41d365f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 6, 2021, 17:55 Dmitry Gutov wrote: > On 06.06.2021 09:59, Jo=C3=A3o T=C3=A1vora wrote: > > Very true, but here's the suprise: In the flex style, there are a_lot_ > > of "possible completions" for the null or very short patterns. So thos= e > > calculations -- which were more than certainly thought up for prefix-is= h > > styles -- are quite slow (and also quite useless for flex). At least > > that's my theory. > > try-completion doesn't trigger any completion style machinery; only > completion-try-completion does. > I have no idea if completion style stuff b is related. Just that else branch is there to calculate some 'determ' thing and a cursory look revealed try-completion calls being passed 'comps', or 'completions'. Presumably lots of data given short flex style patterns. No idea what it accomplishes, as I said. Bottom line is that something (TM) happened to speed up the whole thing when I skipped over that whole part. I had vertical mode basically visually equivalent to vertical, but quite slower. After skipping that part they became practically equivalent. And you yourself witnessed this when switching yo vertical mode, which is when the skip is made. I'll check later in the week, away from my computer now. And are we talking about the 'try-completion' call which is guarded with > (when icomplete-hide-common-prefix ...)? > No idea > > icomplete--fido-mode-setup sets that variable to nil. > May be. Jo=C3=A3o > --000000000000fd8ce305c41d365f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 6, 2021, 17:55 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 06.06.2021 09:59, Jo=C3=A3o T=C3=A1vora wrote:
> Very true, but here's the suprise: In the flex style, there are a_= lot_
> of "possible completions" for the null or very short pattern= s.=C2=A0 So those
> calculations -- which were more than certainly thought up for prefix-i= sh
> styles -- are quite slow (and also quite useless for flex).=C2=A0 At l= east
> that's my theory.

try-completion doesn't trigger any completion style machinery; only completion-try-completion does.

I have no idea if completion style stuff b i= s related. Just that else branch is there to calculate some 'determ'= ; thing and a cursory look revealed try-completion calls being passed '= comps', or 'completions'. Presumably lots of data given short f= lex style patterns. No idea what it accomplishes, as I said.

Bottom line is that something (TM) ha= ppened to speed up the whole thing when I skipped over that whole part. I h= ad vertical mode basically visually equivalent to vertical, but quite slowe= r.=C2=A0 After skipping that part they became practically equivalent. And y= ou yourself witnessed this when switching yo vertical mode, which is when t= he skip is made.

=C2=A0I= 'll check later in the week, away from my computer now.

And are we talking about the 'try-completion' = call which is guarded with
(when icomplete-hide-common-prefix ...)?

No idea

icomplete--fido-mode-setup sets that variable to nil.

May be.

Jo=C3=A3o
--000000000000fd8ce305c41d365f--