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: Fri, 13 Nov 2020 14:59:15 +0200 Message-ID: <83v9e9wgyk.fsf@gnu.org> References: <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23365"; 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 Fri Nov 13 14:05:58 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 1kdYm6-0005wZ-CO for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 14:05:58 +0100 Original-Received: from localhost ([::1]:40532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdYm5-0002ZD-CY for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 08:05:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdYfu-0006Dl-6u for emacs-devel@gnu.org; Fri, 13 Nov 2020 07:59:34 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57253) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdYft-0004HW-Cv; Fri, 13 Nov 2020 07:59:33 -0500 Original-Received: from [176.228.60.248] (port=3050 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdYfs-0008E4-3l; Fri, 13 Nov 2020 07:59:32 -0500 In-Reply-To: (message from Gregory Heytings on Fri, 13 Nov 2020 12:40:13 +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:259134 Archived-At: > Date: Fri, 13 Nov 2020 12:40:13 +0000 > From: Gregory Heytings > cc: rudalics@gmx.at, spacibba@aol.com, monnier@iro.umontreal.ca, > andreyk.mad@gmail.com, emacs-devel@gnu.org > > > The important aspect is that in the browsers the lists are as wide or as > > narrow as the fields from which they drop; in Emacs it is always as wide > > as the frame, and that is many times way too wide. > > > > Now I'm not sure anymore what we are talking about. I was not talking > about lists in browsers in general; of course a combo box in a webpage for > example is not larger than the field from which it drops. I was talking > about what is, in a browser, the equivalent of the minibuffer in Emacs > (because it is there that you enter your "commands") : the address bar. The search box is also the equivalent of the minibuffer. And both show the same picture: the width of the dropped down list is the same as the field from which it drops. It can be wide, if the field is wide, but if you have enough stuff like tool-bar buttons on the same screen line, it will be much more narrow. That it sometimes is almost as wide as the frame is just a coincidence, and is not relevant to the issue at hand. In fact, the entire width issue is not very important: it is just a sign I used to demonstrate that we have a specialized GUI widget here, whereas the Emacs features that try to emulate that don't use any such GUI widgets. And the looks are accordingly much less pretty. > > More importantly, in Emacs the list doesn't drop down, it pushes the > > mode line up instead. Which is counter-intuitive for those who expect > > the drop-down list or combo-box UI which drops from the field for which > > it shows the possible completion candidates. So our emulation of that > > UI is poor and looks unprofessional. > > So it's the fact that the mode line is pushed up to display the completion > candidates in a drop-down way that worries you? No, it's the fact that we use a window that displays a buffer, and not a vertical list widget. > > Imagine that we would do something like that when other applications use > > menus, for example -- this is very similar. > > What do you mean? That the eternal nature of menus is to work top-down? 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. > > Of course, if some people like this, I don't see why we shouldn't have > > it. It's just a pity that we waste so much energy on these poor-man > > emulations instead of providing the "real thing". > > > > But what is "the real thing"? What macOS does? What Windows does? What > Chrome does? What ... does? The combo-like vertical list widget, of course. > > No, it is not redundant: the address bar is for addresses, the search > > box is for typing search strings. The difference becomes apparent when > > you look at the completion candidates each one offers. But that's an > > aside. > > > > That might have been the case some years ago, but browsers are now clever > enough to make a distinction between URLs and queries. Like I said, this is not relevant to the issue at hand. What's relevant is that you _can_ arrange for a browser to display that search box, and then the completion candidates will be much narrower than the frame.