emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Support "\n" in icomplete-separator


From: Eli Zaretskii
Subject: Re: [PATCH] Support "\n" in icomplete-separator
Date: Thu, 12 Nov 2020 19:50:49 +0200

> Date: Thu, 12 Nov 2020 16:10:03 +0000
> From: Gregory Heytings <ghe@sdf.org>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]