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: Mon, 16 Nov 2020 10:24:21 +0000 Message-ID: References: <83r1p11369.fsf@gnu.org> <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> 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="17499"; 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 Mon Nov 16 11:25:20 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 1kebhH-0004Px-Re for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 11:25:19 +0100 Original-Received: from localhost ([::1]:53902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kebhG-0001GE-Tn for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 05:25:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54180) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kebgj-0000l6-VX for emacs-devel@gnu.org; Mon, 16 Nov 2020 05:24:45 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:57146) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kebgh-0001n7-M3; Mon, 16 Nov 2020 05:24:45 -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 0AGAOO3E026612 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 16 Nov 2020 10:24:24 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0AGAOonE025225; Mon, 16 Nov 2020 10:24:50 GMT In-Reply-To: <83r1oxwehu.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/16 05:24:37 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:259224 Archived-At: >>> No, I mean what would happen if we displayed a menu simulation by >>> showing menu items one below the other in a buffer, instead of using >>> the toolkit menus, or even instead of the TTY menus we have nowadays. >> >> Okay, now I see what you mean. Indeed doing this for menus would not >> make sense / would be ugly. But of course the essential difference >> here is that menus are not meant to be used with a keyboard > > Actually, menus (even GUI toolkit menus) work with the keyboard very > well. Including in Emacs. It's true that interaction with GUI widgets, > including the vertical lists, quite naturally is biased towards pointing > devices, but it is not limited to them. > > The important difference, at least for the purposes of this discussion, > is what menus look like, not how users interact with them. > What I said was probably not clear enough. My argument is the following: as you said, GUI widgets such as menus and vertical list widgets are "biased towards pointing devices". Therefore GUI widgets such as menus and vertical list widgets should not be used where the primary interaction device is the keyboard. Therefore vertical list widgets should not be used to display completion candidates in the minibuffer, where the primary interaction device is the keyboard.