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: Tue, 17 Nov 2020 11:51:21 +0000 Message-ID: References: <837dqr27zs.fsf@gnu.org> <83361f22ah.fsf@gnu.org> <83sg9fzlto.fsf@gnu.org> <83r1ozz22j.fsf@gnu.org> <83d00izloj.fsf@gnu.org> <83361ezix2.fsf@gnu.org> <83y2j6xy4m.fsf@gnu.org> <83v9e9wgyk.fsf@gnu.org> <83r1oxwehu.fsf@gnu.org> <83pn4dryau.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="37478"; 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 Tue Nov 17 12:53:37 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 1kezYG-0009cD-BH for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 12:53:36 +0100 Original-Received: from localhost ([::1]:56712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kezYF-0006Al-Dc for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 06:53:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kezWN-0004XD-9G for emacs-devel@gnu.org; Tue, 17 Nov 2020 06:51:39 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:56444) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kezWL-0001jF-Ju; Tue, 17 Nov 2020 06:51:38 -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 0AHBpONk012017 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 17 Nov 2020 11:51:24 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0AHBplbE027315; Tue, 17 Nov 2020 11:51:47 GMT In-Reply-To: <83pn4dryau.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/17 06:51:15 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:259284 Archived-At: > > Since vertical lists and icomplete-type completion features present the > same interaction interfaces, both keyboard- and mouse-related, I see no > reason to distinguish between them in this context. > > I didn't say these features should be used. However, people do want to > use them, whether we agree or not. > I use them, both in regular buffers and in the minibuffer, so at least I speak with some experience. > > When they do use such features, I maintain that the visual appearance > should be pretty and professional, like what we see in GUI apps out > there which use the vertical list widgets. > I would make a distinction between two things: (1) vertical display of completion candidates inside regular buffers (what Company does) and (2) vertical display of completion candidates in the minibuffer. I agree that for (1) a GUI vertical list widget could make sense instead of the pseudo-tooltip that Company creates with an overlay. I would not use such a widget myself, as I like the minimalism of a terminal-like interface, but I understand that others could prefer a more modern UI, and could judge that a pseudo-tooltip is "unprofessional". I can't agree that for (2) a GUI vertical list widget would make sense, IMO it would be awkward to use a GUI widget there. If AFAIK none of the packages that implement vertical lists there create an rectangular overlay with a pseudo scroll bar (as Company does) to mimic a GUI vertical list widget, it's probably not without any reason. > > I understand that you disagree, and that is fine. I just don't see why > we should continue arguing long after we've established that there's a > fundamental disagreement between us. > Indeed, I agree to fundamentally disagree.