From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Allowing completion sources to customize completion display Date: Fri, 24 Nov 2023 09:15:43 +0200 Message-ID: <83il5rfwps.fsf@gnu.org> References: <831qcghn52.fsf@gnu.org> <08c7660f-ee16-7159-581c-c8b2526a6035@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22761"; mail-complaints-to="usenet@ciao.gmane.io" Cc: me@eshelyaron.com, sbaugh@janestreet.com, emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 24 08:16:44 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 1r6QQd-0005jI-T9 for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Nov 2023 08:16:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6QPr-0001NU-JY; Fri, 24 Nov 2023 02:15:55 -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 1r6QPn-0001Ly-PR for emacs-devel@gnu.org; Fri, 24 Nov 2023 02:15:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r6QPm-0001N3-Oq; Fri, 24 Nov 2023 02:15:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TezdDZTqJ68D1ET+xEDWSYc5YFi6vHkEb1UxAI9hbMo=; b=gNqSya7LmIgF OYVLa6wBfPa3gwWQ+iRIPhheuyJcL04przmIJeyLV1T5Bs+q8YCrabhOoriGeqLm0S/1Mp9sKdX0r OQmfZfYk8VlT9fPJitwKVGFp1OEavi/qRVzwLFsVIXlhpuvRVQkvKSUDO/ffrkctOfSaWRFymE/8r EsdLmmcV2WhknecPayyxUbrv/FG+71EyOoMwFMx5RRp8rC4mImpDxZ0YXOejAQ8kl3QFr9Zxvao60 m7ODxBeUPl6wUSrleqi2SikxDtzEIaKn7ZRzlcnQ5id7HaGtszQAvTe37thMY1Ux2e7NU8uDo+V6v tklZTLbwWAfC+sktLIJ1cA==; In-Reply-To: <08c7660f-ee16-7159-581c-c8b2526a6035@gmail.com> (message from Jim Porter on Thu, 23 Nov 2023 13:20:27 -0800) 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:313170 Archived-At: > Date: Thu, 23 Nov 2023 13:20:27 -0800 > Cc: sbaugh@janestreet.com, emacs-devel@gnu.org > From: Jim Porter > > On 11/23/2023 12:47 AM, Eli Zaretskii wrote: > > IMNSHO, it will be a sad day when different completion sources will > > present different completion UI. There will be no end to user > > confusion. > > I think Spencer's suggestion below would be ok (assuming it actually > works). Then it's up to the users themselves to opt-in to different UI > for different sources: > > On 11/22/2023 3:05 PM, Spencer Baugh wrote: > > - Maybe completion-category-overrides could change > > completion-in-region-function based on the category? I don't see how this resolves the issue I had in mind, which is that users should NOT be presented with different completion-related displays and use different completion-related commands depending on the source of the completion data. Quite the opposite: each source of the completion data should be able to adapt its presentation to the user preferences, as expressed via user options (if we have such UI-related options). Users should not re-learn how to use completion in Emacs each time we add some new source of completion data to some command that offers completion. E.g., consider the following half-theoretical example: suppose the file-name completion learns to offer completion candidates from some source other than the list of files in default-directory -- my point is that those additional files that come from those other sources should be displayed in exactly the same way as the "traditional" source, and let users use the same commands to complete. Anything else would be terribly confusing, and we should not do it.