From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness Date: Wed, 20 Mar 2019 21:00:53 +0000 Message-ID: References: <20190213212413.868.40960@vcs0.savannah.gnu.org> <20190213212415.148B9209D7@vcs0.savannah.gnu.org> <0ba3ca47-c7d6-a608-536e-94784ba3384b@yandex.ru> <4f4e9ccd-b152-2b37-cad2-6c96b0a64d84@yandex.ru> <646c8d35-89a7-b12f-8a78-b05e6d8f781c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="232021"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin) Cc: emacs-devel , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 22:17:36 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6iae-000yIy-Bq for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 22:17:36 +0100 Original-Received: from localhost ([127.0.0.1]:53290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6iad-0005C0-AN for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 17:17:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6iZS-0004kx-CR for emacs-devel@gnu.org; Wed, 20 Mar 2019 17:16:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6iKZ-0004zc-JT for emacs-devel@gnu.org; Wed, 20 Mar 2019 17:01:00 -0400 Original-Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:35613) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6iKZ-0004xh-8j for emacs-devel@gnu.org; Wed, 20 Mar 2019 17:00:59 -0400 Original-Received: by mail-wm1-x343.google.com with SMTP id y197so628245wmd.0 for ; Wed, 20 Mar 2019 14:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=0npdpxj4FOEVqdQk84hLXeqqX4UXDegOBvfCJjlJu0k=; b=gHCuXdlJ/Q9boFSvw394lFht7u5cMHAndiZzAdLjsbEk/pvKg+s6zDy4zQbyL/tWYS Pas1KKvMkrSmLewzboWNXuLgjqqTP1UMMg2N++kSDovgE1nu/W/kQmMqSApbWSXECw/G sCUgSlzX199N4pL6SfoU2768STuJ8Uon8WGEygewcw9lMLm+3iTgYs0EkiA9P2dJSe36 gYX/Dreu8y97IFATPGe1q4YE7s7MgFwZ/LwSmVsu7aM3NhXL2OnyfEKBFDNQ5F7AJopo 1YjPq8oSv9wEsThK2DWH5Q3axvwGnDsckaKKd6GJV0Vidj/ogtDwFJz1yKkq50tNXSzu gVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=0npdpxj4FOEVqdQk84hLXeqqX4UXDegOBvfCJjlJu0k=; b=ApCs2zVNXjihL7IYB15aYrEdq8gMTk3pbtvLL3MZUbqGRP1Ylc86DdVMvT9YVUdJLd Es9aH3eqqMS74MULiFTjFmdbL9amCmbbTtk2grXH+7Enq64GUDbAGNpU683Nyyzif99e kLSARnyFgkbV0lCNDpERAYeZYVR/mL4hYf3EWFxWwu1uE9/89D9oKWSAsaalHUaW68Xg bR3UNTCOWHjkm1Iny24LQe8VAps0byTEvtHfnUSRvIH9em7G5fmGxXCwXoXffrwKGOfZ j8vueCcYV9txCUFmjRDC6XJqt7WsGcNgztRMGr/j4sjVbnupFEevUQmaFRf5cbUvVnUb 4Emg== X-Gm-Message-State: APjAAAXMIIcVEU6vakW+wjpz+g3gVO2UJ4Wppb5nT9Qar1WMquqSi/yw YS9vvGf/Ri2vSu664V/pQGw2HYRT X-Google-Smtp-Source: APXvYqxX3x5XCIbk5uJ3V2qV6rdTcgl9XIAxnbpiPCz+02xmLMQvUidsqjGTxeUWWt4uvtjd6uDWIQ== X-Received: by 2002:a7b:ce1a:: with SMTP id m26mr169873wmc.131.1553115656994; Wed, 20 Mar 2019 14:00:56 -0700 (PDT) Original-Received: from kitaj.local.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id l8sm3196289wrv.45.2019.03.20.14.00.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 20 Mar 2019 14:00:55 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 20 Mar 2019 08:09:51 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::343 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234426 Archived-At: Stefan Monnier writes: > FWIW, I think if basic is fast enough and flex is 2x slower, then flex > is likely fast enough as well (or the contrapositive: if flex is too > slow and basic is only 2x faster, then basic is also too slow). Hmmm, slightly confused, but I think we're currently in the "contrapositive" side (at least given the UI problems that I describe below). Anyway, this is orthogonal, but I do think that flex can be made faster so that it is only, say 1.2x, slower than basic in the worst case. I'd say it's worth a shot. Depending on the "basic" implementation, it could even be faster. >>> It's worth a try. But if filtering will happen right away after the >>> user has stopped typing, that might mean higher CPU usage and lower >>> battery life on a laptop. Just something to be on a lookout for. >> You're absolutely right. And anyway I noticed icomplete _already_ has a >> while-no-input there, so that technique has already been tried. > > Not really: the while-no-input was added long after the rest of the code > was written and was mostly designed for the case where the completion > data takes a *very* long time to get, the main purpose being to be able > to enable icomplete for *all* completion tables rather than only for > those we know to be fast enough. I don't understand: while-no-input _is_ there, at least it is doing that which I was going to attempt. Or do you have some better use of it in mind that I am not aware of? Anyway, with the current approach, the problem seems to be that throw-on-input is not being checked often enough. I.e in this block: (let* (... (text (while-no-input (icomplete-completions field-string (icomplete--completion-table) (icomplete--completion-predicate) (if (window-minibuffer-p) (not minibuffer-completion-confirm))))) (buffer-undo-list t) deactivate-mark) ;; Do nothing if while-no-input was aborted. (when (stringp text) ... )) =20=20=20=20=20=20=20=20=20=20=20=20 text will often be t, meaning the call _was_ interrupted by while-no-input, but icomplete-completions was still allowed to run to completion (and that takes about one or two seconds with empty input). If somehow while-no-input were able to detect interruptions at a more finer grained level, I think icomplete-completions would be interrupted earlier. A (dumb) way to fix this is by simply adding a call to input-pending-p to one of the critical sections: diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index c5d7148..37d1d91 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3049,7 +3049,9 @@ completion-pcm--all-completions compl (let ((poss ())) (dolist (c compl) - (when (string-match-p regex c) (push c poss))) + (when (string-match-p regex c) + (input-pending-p) + (push c poss))) (nreverse poss)))))) =20 (defvar flex-score-match-tightness 100 =20 If one tries C-h f after evaluating this, shows almost immediately after the user typed it. Now, this is quite ugly and it still doesn't fix the C-h f RET delay for some reason (but that shouldn't be very hard to fix, hopefully) Furthermore, I think the problem pointed to by Dmitry regarding power consumption is mostly unrelated to this, and targeted effectively by the existing icomplete-compute-delay variable, which menas battery-wary users should just set that to a higher value. Jo=C3=A3o