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 20:09:42 +0200 Message-ID: <83361f22ah.fsf@gnu.org> References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <837dqr27zs.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1415"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, spacibba@aol.com, monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 19:10:16 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 1kcuZU-0000Hu-0P for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 19:10:16 +0100 Original-Received: from localhost ([::1]:43838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcuZS-000097-V7 for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 13:10:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcuYn-00089a-3s for emacs-devel@gnu.org; Wed, 11 Nov 2020 13:09:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34147) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcuYl-0005kk-2I; Wed, 11 Nov 2020 13:09:31 -0500 Original-Received: from [176.228.60.248] (port=3184 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kcuYk-0000XB-Bc; Wed, 11 Nov 2020 13:09:30 -0500 In-Reply-To: (message from Gregory Heytings on Wed, 11 Nov 2020 17:12:21 +0000) 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:259037 Archived-At: > Date: Wed, 11 Nov 2020 17:12:21 +0000 > From: Gregory Heytings > cc: martin rudalics , spacibba@aol.com, > monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org > > > 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. > > Well, Emacs wasn't designed to manage emails or browse the web either ;-) Yes, it was. Those applications basically display text with a few images, something that Emacs 21 was definitely designed to support. Don't misunderstand me: Emacs _can_ display what icomplete-vertical and similar features ask it, it just cannot do that well, and the results are not pretty. If you read the code that is involved, the reasons are acutely evident, and it is important for me to make these conclusions public and known to all, because many people believe there's no limit to what one can do with Emacs display features. Well, there is. > Did you try Ivy? Yes. > And, FWIW, I'm a user, and I do not expect a "very different way of > showing completion candidates". Neither am I. icomplete-vertical and friends weren't written for the likes of us.