From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Observe Slowness In minibuffer-next-completion and friends Date: Fri, 10 Nov 2023 09:49:36 +0200 Organization: LINKOV.NET Message-ID: <86cywiqhlr.fsf@mail.linkov.net> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11639"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel@gnu.org To: "T.V Raman" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 08:52:13 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r1MJJ-0002tQ-SJ for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 08:52:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1MIV-0008Rv-Hr; Fri, 10 Nov 2023 02:51:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1MIS-0008Rj-Hi for emacs-devel@gnu.org; Fri, 10 Nov 2023 02:51:20 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1MIO-00028G-ES for emacs-devel@gnu.org; Fri, 10 Nov 2023 02:51:20 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id D8B71FF80E; Fri, 10 Nov 2023 07:51:12 +0000 (UTC) In-Reply-To: (T. V. Raman's message of "Thu, 09 Nov 2023 20:08:10 -0800") X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=217.70.183.199; envelope-from=juri@linkov.net; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312463 Archived-At: > This appears to be new as of this afternoon's update on Git: > > Type: > C-h f next- > Then press down-arrow to move to next completion; the completion list > appears to be not active for about a second. I already tried setting > completion-highlight-face to nil, but the slowness remains; from > memory this feels new compared to yesterday The first time I tried it was very slow, it took about 3 seconds. Then on next attempts it was instantaneous. This means only one thing that you have to wait a little until asynchronous native compilation finishes its job. That said, I think there are more opportunities for optimization. What I don't like is that it checks the presence of the completions window for the every key pressed. A possible optimization would be to set a minibuffer-local variable when the completions window is displayed, and unset it when the window disappears. However, still can't handle the case when the user closes the completions window manually with e.g. 'C-x 0'.