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: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 18:06:31 +0200 Message-ID: <837dqr27zs.fsf@gnu.org> References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9575"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 17:08:27 2020 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 1kcsfb-0002O1-7n for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 17:08:27 +0100 Original-Received: from localhost ([::1]:57830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcsfa-0002cB-4j for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 11:08:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcsdn-0000Tu-TE for emacs-devel@gnu.org; Wed, 11 Nov 2020 11:06:36 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59329) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcsdl-0003j7-0T; Wed, 11 Nov 2020 11:06:34 -0500 Original-Received: from [176.228.60.248] (port=3559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kcsda-0003nx-Ty; Wed, 11 Nov 2020 11:06:30 -0500 In-Reply-To: (message from martin rudalics on Wed, 11 Nov 2020 11:01:43 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:259021 Archived-At: > Cc: Eli Zaretskii , spacibba@aol.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > From: martin rudalics > Date: Wed, 11 Nov 2020 11:01:43 +0100 > > >> Applications have to accept that users want their minibuffer windows to > >> show just one line. Or at most two lines. Or three ... > > > > Also users: "Show us completions vertically" and > > (setq -separator "\n") > > Users shouldn't want the cake and eat it too. Any application should > take care of such users. If an application has a truly expandable > minibuffer window or a normal window at its hands, it can try to show > completions vertically. With the default minibuffer window, it should > always behave as if only one line were available. I'd say this much more bluntly: Emacs's minibuffer input was not designed for showing too many completion candidates, let alone show them vertically arranged. It was even less designed to display the candidates or other hints in overlays. Users come from other GUI applications, and expect a very different way of showing completion candidates than Emacs traditionally does. they want a UI which is akin to a combo box, sometimes even with scroll capability. If we want to support such UI, we should support it properly: by dropping down or popping up such a combo-like list. It is IMO wrong to do this the way icomplete-vertical and other similar packages try doing it, because the result will never look as pretty and professional as those other GUI applications offer. IOW, we should add new infrastructure into Emacs for supporting these features, perhaps by reusing some existing toolkit widgets. Playing tricks with display based on overlays with embedded newlines is not TRT, it's a dead end -- there are many things you simply will be unable to do reliably that way, and the results will not be pretty anyway.