From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 18:39:41 +0000 Message-ID: References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <837dqr27zs.fsf@gnu.org> <83361f22ah.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32775"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: rudalics@gmx.at, spacibba@aol.com, monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 19:52:31 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 1kcvEN-0008RC-9S for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 19:52:31 +0100 Original-Received: from localhost ([::1]:37738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcvEM-000769-9X for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 13:52:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcv2Q-00012T-OG for emacs-devel@gnu.org; Wed, 11 Nov 2020 13:40:10 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:64073) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcv2O-0008PJ-FQ; Wed, 11 Nov 2020 13:40:10 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0ABIdixj001236 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 11 Nov 2020 18:39:45 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ABIeDAb002241; Wed, 11 Nov 2020 18:40:13 GMT In-Reply-To: <83361f22ah.fsf@gnu.org> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 11:05:19 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:259040 Archived-At: >>> 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. > I honestly don't understand why you consider that vertical icomplete is "not pretty", even more so as you seem to consider at the same time that Emacs' handling of emails and web pages is okay. IMO, Emacs' rendering of HTML in emails and on web pages is definitely not pretty. IMO again, displaying completion candidates in the minibuffer is pretty enough, at least I don't see why it would be fundamentally less pretty for a newcomer than, say, the completion candidates displayed by Chromium or Visual Studio. > > 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. > There are limits, of course, but the feature that is requested is well within the limits of what Emacs can do. And AFAIU implementing a proper vertical icomplete/ido with a few more features similar to those of Ivy is also within the limits of what Emacs can do.