From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Slow completion-at-point was Re: Navigating completions from minibuffer Date: Wed, 8 Nov 2023 14:11:44 -0800 Message-ID: <25932.1952.158726.658192@google.com> References: <25929.50004.710119.599023@google.com> <868r7af3v6.fsf@mail.linkov.net> <25930.31126.454503.607723@google.com> <868r78bsnx.fsf@mail.linkov.net> <25931.49899.219679.933329@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5556"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, juri@linkov.net To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 08 23:13: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 1r0qnR-0001Dv-BB for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Nov 2023 23:13:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0qmN-0005do-He; Wed, 08 Nov 2023 17:12:07 -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 1r0qmL-0005de-Lo for emacs-devel@gnu.org; Wed, 08 Nov 2023 17:12:05 -0500 Original-Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0qm7-0003Uw-DV for emacs-devel@gnu.org; Wed, 08 Nov 2023 17:12:05 -0500 Original-Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-28039ee1587so126223a91.2 for ; Wed, 08 Nov 2023 14:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699481509; x=1700086309; darn=gnu.org; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:from:to:cc:subject:date :message-id:reply-to; bh=Q7BOSu4m9WxDPDXc706LdKu1opZ0CO2OC4fFQmRkwuQ=; b=BjCx08mhKRG81k1ZRgxyw+9rNu/okPdvT2WFfaQHV+tlmHA13foraPC7HnKPYplXqZ 9dwbsCvZliGKxMFYtxUgxki53X9rTbMnsiWwI8QdyLetPrUPPsYP/r1wB5XkUQUgAxiS ji6+OWxisVGrFjJDN5Z54OnOvZxM5wcXDeEmSMZNHhuitPGgLcjfG5YgMlyvyGDd2uIj 0U9uCvXwRtw3dRkAUxmXrSNHWJy6K+csru5CZwsDFJm0KJgY+MnZeby5ZVLsjTFzNLai 1cFcP6I5kHoz27KBwmDXNm7O0X9lEhH9K84TZWlG7D4LojYgpZfJATCZKvS8J3ljhgmh 6IGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699481509; x=1700086309; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Q7BOSu4m9WxDPDXc706LdKu1opZ0CO2OC4fFQmRkwuQ=; b=TSNh/Y+8wJ+PLkqcP4evW7dlYqh+Z97+49Mt/0Dlf+UzHQX1I9eoPWJbZNp4xg3zmo n6gHFSmLjKCF09TrvNEGe2SF21YchQre6GgaCfztdWclDoLUzknSAJa11TheCeL/j2Xu sik/IzaO3eKBfvCJDtn7LGiO1yEPcAua5gTWx+YXaX5jaFYmwSlWP4i05K5AVN5Hfhmv yIu1dArrhcHQUOgUV+91DLhuIf4x/SR+ea/+DxkiwZtXacExsHL7OAHzIDlB1GlsbiA/ B+agcgMXMnB9C2LmRbACOAKGUpzR8khbW0ij3FkYZWhliwMFTZFkWV2q8ISEl4b7auEJ WKbw== X-Gm-Message-State: AOJu0YzgZIKjqg8VMbQcKTQsVPoBWgkaIXXl83l7qFV/+ugpQEaSFl7S e0Uetws65FGHuuUhmPXDnsTB0kvBYamHyiNZ37L8MQ== X-Google-Smtp-Source: AGHT+IFtytlrK+WPZB06GnSyuqU1jKg1GlEWSdZi+kKHqe+O6ddYhPkXDk4WVzoAUsb1cusZFfpcQA== X-Received: by 2002:a17:90b:3ec4:b0:274:8949:d834 with SMTP id rm4-20020a17090b3ec400b002748949d834mr2398375pjb.49.1699481509244; Wed, 08 Nov 2023 14:11:49 -0800 (PST) Original-Received: from raman9 ([2601:646:9e02:3290:b4a:dfa7:9983:d34c]) by smtp.gmail.com with ESMTPSA id o18-20020a17090ac09200b002609cadc56esm18277pjs.11.2023.11.08.14.11.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 14:11:48 -0800 (PST) In-Reply-To: <25931.49899.219679.933329@google.com> X-Mailer: VM 8.1.1 under 30.0.50 (x86_64-pc-linux-gnu) Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=raman@google.com; helo=mail-pj1-x1029.google.com X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 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:312364 Archived-At: Here is some timing information for this issue: I added the following around advice fragment to completion-at-point debug: (let ((start (current-time))) ad-do-it (message "<%.4f %d gcs %.4f>" (float-time (time-subtract (current-time) start)) gcs-done gc-elapsed)) Then I went to a shell buffer, and from my home directory (it contains a subdir text) typed cd te Messages buffer shows the following: ~/ Making completion list... Sole completion <2.0219 14 gcs 1.2927> --Raman T.V Raman writes: > Adding emacs-devel after verifying slowness: > > 1. completion-at-point appears to have gotten very slow -- from memory > in the last week (emacs built against Git @HEAD) > The slowness is not present in a build from October 4. > > > > T.V Raman writes: > > Juri Linkov writes: > > > > > > Agreed. And somewhat related and something that has been causing me > > trouble: > > > > Q: Why is completion-at-point *soo much* slower than > > hippie-expand? > > > > I tried to understand why by looking at the code for completion-at-point > > but failed miserably. > > > > Hope you could look at this since you're working on completion related > > bits. > > > > > > Also, how and when completions are displayed can now be controlled by > > multiple custom knobs, but it's hard to map the combinatorial explosion > > of the available possibilities to different user experiences without > > trying all possible settings; a higher level overview with a couple of > > recipes that describe common combinations would help. > > > > > > >> everything works, now that I actually applied the complete patch:-) > > > > > > Thanks for confirming and for suggesting this change, now pushed. > > > > > > Probably we have to make RET more smart, so that when more editing > > > was performed in the minibuffer after the completions were displayed, > > > then to use the minibuffer contents with exit-minibuffer, > > > not an obsolete completion candidate that remains selected. > > > > > > > -- > > -- > > -- -- --