[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Support "\n" in icomplete-separator
From: |
Gregory Heytings |
Subject: |
Re: [PATCH] Support "\n" in icomplete-separator |
Date: |
Thu, 12 Nov 2020 16:10:03 +0000 |
User-agent: |
Alpine 2.22 (NEB 394 2020-01-19) |
When you do need to use the Web browsers that implement that UI, do
you frequently regret they don't work like Ivy?
I don't understand your question.
Which of the two do you like better: the Emacs modes like
icomplete-vertical or the drop-down list UI of the browsers?
The Emacs modes... I guess I'm a hopeless case ;-)
No, those browsers never drop a list which is as wide as the
window/frame. So they waste much less screen space.
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
or the small Google Search window to the right of the address bar.
This one I don't use, and AFAIK it is not "activated" by default, as it is
redundant with the address bar.
firefox.png
Description: PNG image
- Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator, (continued)
- Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/12
- Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator, Jean Louis, 2020/11/12
- Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator,
Gregory Heytings <=
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Stephen Berman, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Stephen Berman, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/16