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: Thu, 12 Nov 2020 19:50:49 +0200 Message-ID: <83y2j6xy4m.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> <83361f22ah.fsf@gnu.org> <83sg9fzlto.fsf@gnu.org> <83r1ozz22j.fsf@gnu.org> <83d00izloj.fsf@gnu.org> <83361ezix2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33779"; 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 Thu Nov 12 18:51:52 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 1kdGlE-0008eO-8l for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 18:51:52 +0100 Original-Received: from localhost ([::1]:38442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdGlD-0005Op-B5 for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 12:51:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdGkJ-0004uj-Nn for emacs-devel@gnu.org; Thu, 12 Nov 2020 12:50:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57129) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdGkI-0006HH-Mk; Thu, 12 Nov 2020 12:50:54 -0500 Original-Received: from [176.228.60.248] (port=3632 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdGkI-0004EJ-1f; Thu, 12 Nov 2020 12:50:54 -0500 In-Reply-To: (message from Gregory Heytings on Thu, 12 Nov 2020 16:10:03 +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:259094 Archived-At: > Date: Thu, 12 Nov 2020 16:10:03 +0000 > From: Gregory Heytings > cc: rudalics@gmx.at, spacibba@aol.com, monnier@iro.umontreal.ca, > andreyk.mad@gmail.com, emacs-devel@gnu.org > > >> I attach a screenshot of Chromium. The frame is 2880 pixels wide, the > >> "combo box" with completion candidates is 2472 pixels wide. That's 86% > >> of the frame width. Okay, 86% is not 100%, but 86% is not "much less" > >> than 100%. > > > > Sheer luck. Try typing something into the Firefox's address bar > > > > Sheer luck??? Most users type their queries directly in its address bar > as I did, so they see exactly what is displayed on the screenshot, and the > "market share" of Chromium/Chrome is 66%. > > Here is a screenshot with Firefox, the combo box is 2342 pixels wide, that > is, 82% of the frame width. > > By the way, the search combo box in Chrome and Firefox is also taller than > the minibuffer in Emacs: it uses 30% of the frame height in Chrome, and > 50% of the frame height in Firefox. For Emacs (with the default > max-mini-window-height value) it's 25%. In terms of "wasted screen > space": > > - Emacs uses 1.15 M pixels > - Chrome uses 1.25 M pixels > - Firefox uses 2 M pixels Pixel dimensions are irrelevant. 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. 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. Imagine that we would do something like that when other applications use menus, for example -- this is very similar. It reminds me how XEmacs in old days would pop up a separate frame when a dialog box was called for -- it was 100% functional, but butt-ugly, even ridiculous. 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". > > or the small Google Search window to the right of the address bar. > > This one I don't use That's immaterial: try using it just to see what I mean. > and AFAIK it is not "activated" by default, as it is redundant with > the address bar. 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.