* RE: [PATCH] Support "\n" in icomplete-separator [not found] ` <<837dqr27zs.fsf@gnu.org> @ 2020-11-11 19:03 ` Drew Adams [not found] ` <<alpine.NEB.2.22.394.2011111803220453.17489@sdf.lonestar.org> 1 sibling, 0 replies; 115+ messages in thread From: Drew Adams @ 2020-11-11 19:03 UTC (permalink / raw To: Eli Zaretskii, martin rudalics Cc: spacibba, monnier, andreyk.mad, emacs-devel > Emacs's minibuffer input was not > designed for showing too many completion candidates, let alone show > them vertically arranged. It was even less designed to display the > candidates or other hints in overlays. Maybe so. What the creator originally had in mind was designed in the terminal-only days, back in the Dark Ages. I'd say too that minibuffer content and height is not only about showing multiple completion candidates, i.e., what Ido, Icomplete, and similar do. In my use, the minibuffer only shows one completion candidate. But that candidate can be multiple lines of text. Your point should be, I think, that it's about the size of what is displayed in the minibuffer, regardless of what is displayed there or how (text or overlay, for example). Your apparent assumption that the issue is only about showing multiple candidates, and hence your comments about implementing combo-boxes etc., may be warranted in the context of only this thread, which is about Icomplete. But the general issue of minibuffer size is, well more general. In any case, I think that the Emacs minibuffer should be able to handle pretty much arbitrary text, overlays, etc. - just what other buffers can handle. How such things get displayed can be up to the code that handles displaying it, and it need not be handled well by vanilla Emacs by default. But the minibuffer should allow libraries and user code to handle large content. ^ permalink raw reply [flat|nested] 115+ messages in thread
[parent not found: <<alpine.NEB.2.22.394.2011111803220453.17489@sdf.lonestar.org>]
[parent not found: <<83361f22ah.fsf@gnu.org>]
[parent not found: <<alpine.NEB.2.22.394.2011111926450453.27530@sdf.lonestar.org>]
[parent not found: <<83sg9fzlto.fsf@gnu.org>]
[parent not found: <<alpine.NEB.2.22.394.2011112128400453.4149@sdf.lonestar.org>]
[parent not found: <<83r1ozz22j.fsf@gnu.org>]
[parent not found: <<alpine.NEB.2.22.394.2011120932160453.28737@sdf.lonestar.org>]
[parent not found: <<83d00izloj.fsf@gnu.org>]
[parent not found: <<alpine.NEB.2.22.394.2011121544550453.26984@sdf.lonestar.org>]
[parent not found: <<83361ezix2.fsf@gnu.org>]
* RE: [PATCH] Support "\n" in icomplete-separator [not found] ` <<83361ezix2.fsf@gnu.org> @ 2020-11-12 17:42 ` Drew Adams 0 siblings, 0 replies; 115+ messages in thread From: Drew Adams @ 2020-11-12 17:42 UTC (permalink / raw To: Eli Zaretskii, Gregory Heytings Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Which of the two do you like better: the Emacs modes like > icomplete-vertical or the drop-down list UI of the browsers? Perhaps an unfair reply, as I don't use icomplete-vertical. But to respond to the question generally, I prefer a UI where: 1. I can hit a key to empty the current search pattern. 2. I can get regexp, fuzzy, substring, or whatever matching. 3. I can specify where I want the set of candidates shown (e.g. where to put *Completions* or whatever other display is used - not just drop it down, obscuring the content of the current "page"/window). In Emacs, use of a set of candidates is often closely involved with the buffer you start the filtering operation from. It can help to continue to see it, and to be able to (on demand) get the candidates list out of the way. 4. I can hit a key to change the sort order of the candidates, and multiple ways, which can be specific to the kind of candidates. 5. I can add additional patterns, to apply further filtering (AND-ing/intersecting with the current set). 6. Complementing the last filtering operation, to subtract its candidates from the previously shown set (AND-NOT). I have all of that with Icicles. All with keyboard keys. And I can use the mouse, including wheel, as well. ^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [PATCH] Support "\n" in icomplete-separator
@ 2020-11-06 16:30 Drew Adams
0 siblings, 0 replies; 115+ messages in thread
From: Drew Adams @ 2020-11-06 16:30 UTC (permalink / raw
To: Emacs-Devel List
[Forwarding to the list, as it got dropped from
Reply All.]
> My opinion is that there is no need to show visually that there are more
> candidates, most (all?) other programs I use never do that, they just
> display a list of candidates, and it becomes clear that there are no more
> candidates when the list shrinks after enough input.
"it becomes clear..."
Maybe, maybe not. If you have N completion matches
and their explicit display shows only N-5 of them,
you might want to know that there are 5 more.
In Icicles, by default, the number of candidates
currently shown, and the total number, are indicated
in the mode-line: e.g. "149/567 shown".
And the mode-line lighter includes "..." when not
all are shown.
(If not all candidates are shown it's because you've
chosen to limit the number to show.)
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH] Support "\n" in icomplete-separator @ 2020-11-05 23:10 Andrii Kolomoiets 2020-11-05 23:29 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-05 23:10 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 704 bytes --] Hi, I'm a bit late to the icomplete-vertical party, but please let me show you my approach at supporting "\n" in 'icomplete-separator'. The main idea is to treat the 'icomplete-prospects-height' variable value as the amount of completions we want to see if there is "\n" in the 'icomplete-separator'. Please see attached patch. Also see attached screenshot of minibuffer-only frame after: emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" M-x icomplete-mode (setq icomplete-prospects-height 5) (setq icomplete-hide-common-prefix nil) (setq icomplete-separator "\n ") (setq resize-mini-frames t) M-x icomp If that approach was already discussed, please let me know. WDYT? Thanks! [-- Attachment #2: icomplete-vertical.diff --] [-- Type: text/x-patch, Size: 3921 bytes --] diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 4e546807b7..ec11cbffce 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -701,19 +701,23 @@ icomplete-completions ((< compare (+ 2 (string-width ellipsis))) most) (t (concat ellipsis (substring most compare)))) close-bracket))) + (vertical (string-match "\n" icomplete-separator)) ;;"-prospects" - more than one candidate - (prospects-len (+ (string-width - (or determ (concat open-bracket close-bracket))) - (string-width icomplete-separator) - (+ 2 (string-width ellipsis)) ;; take {…} into account - (string-width (buffer-string)))) + (prospects-len (unless vertical + (+ (string-width + (or determ (concat open-bracket close-bracket))) + (string-width icomplete-separator) + (+ 2 (string-width ellipsis)) ;; take {…} into account + (string-width (buffer-string))))) (prospects-max - ;; Max total length to use, including the minibuffer content. - (* (+ icomplete-prospects-height - ;; If the minibuffer content already uses up more than - ;; one line, increase the allowable space accordingly. - (/ prospects-len (window-width))) - (window-width))) + (if vertical + icomplete-prospects-height + ;; Max total length to use, including the minibuffer content. + (* (+ icomplete-prospects-height + ;; If the minibuffer content already uses up more than + ;; one line, increase the allowable space accordingly. + (/ prospects-len (window-width))) + (window-width)))) ;; Find the common prefix among `comps'. ;; We can't use the optimization below because its assumptions ;; aren't always true, e.g. when completion-cycling (bug#10850): @@ -730,7 +734,9 @@ icomplete-completions ;; is already displayed via `most'. (string-prefix-p prefix most t) (length prefix))) ;;) - prospects comp limit) + (limit (when vertical + (> (length comps) prospects-max))) + prospects comp) (if (or (eq most-try t) (not (consp (cdr comps)))) (setq prospects nil) (when (member name comps) @@ -753,17 +759,24 @@ icomplete-completions ;; completion field. (setq determ (concat open-bracket "" close-bracket))) ;; Compute prospects for display. - (while (and comps (not limit)) - (setq comp - (if prefix-len (substring (car comps) prefix-len) (car comps)) - comps (cdr comps)) - (setq prospects-len - (+ (string-width comp) - (string-width icomplete-separator) - prospects-len)) - (if (< prospects-len prospects-max) - (push comp prospects) - (setq limit t)))) + (if vertical + (while (and comps (> prospects-max 0)) + (setq prospects-max (1- prospects-max)) + (push (if prefix-len + (substring (pop comps) prefix-len) + (pop comps)) + prospects)) + (while (and comps (not limit)) + (setq comp + (if prefix-len (substring (car comps) prefix-len) (car comps)) + comps (cdr comps)) + (setq prospects-len + (+ (string-width comp) + (string-width icomplete-separator) + prospects-len)) + (if (< prospects-len prospects-max) + (push comp prospects) + (setq limit t))))) (setq prospects (nreverse prospects)) ;; Decorate first of the prospects. (when prospects [-- Attachment #3: icomplete-vertical.png --] [-- Type: image/png, Size: 43149 bytes --] ^ permalink raw reply related [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:10 Andrii Kolomoiets @ 2020-11-05 23:29 ` Stefan Monnier 2020-11-06 0:04 ` Ergus 2020-11-06 10:26 ` Andrii Kolomoiets 2020-11-05 23:57 ` Ergus 2020-11-06 5:52 ` Jean Louis 2 siblings, 2 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-05 23:29 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel > I'm a bit late to the icomplete-vertical party, but please let me show > you my approach at supporting "\n" in 'icomplete-separator'. A side-note: I think the use of "..." to indicate that there are more entries is a bad idea. Better represent it with the absence of a terminator (e.g. in the normal icomplete-mode, it basically means replace "...}" with ""). It will make the code simpler, more robust, and a side benefit is that it will make slightly more efficient use of the screen real estate. Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:29 ` Stefan Monnier @ 2020-11-06 0:04 ` Ergus 2020-11-06 2:44 ` Stefan Monnier 2020-11-06 8:42 ` Gregory Heytings via Emacs development discussions. 2020-11-06 10:26 ` Andrii Kolomoiets 1 sibling, 2 replies; 115+ messages in thread From: Ergus @ 2020-11-06 0:04 UTC (permalink / raw To: Stefan Monnier; +Cc: Andrii Kolomoiets, emacs-devel On Thu, Nov 05, 2020 at 06:29:47PM -0500, Stefan Monnier wrote: >> I'm a bit late to the icomplete-vertical party, but please let me show >> you my approach at supporting "\n" in 'icomplete-separator'. > >A side-note: I think the use of "..." to indicate that there are more >entries is a bad idea. Better represent it with the absence of >a terminator (e.g. in the normal icomplete-mode, it basically means >replace "...}" with ""). It will make the code simpler, more robust, >and a side benefit is that it will make slightly more efficient use of >the screen real estate. > > > Stefan > Hi Stefan I agree that taking a like only for the ellipsis is inefficient witht he space. Actually the ellipsis is something I would like to discuss, but nobody put attention on it before ;(, so I was basically waiting to receive some feedback (and complains) respecting to that maybe after pushing into master.. The problem in vertical is that it will be "better" if we don't add {} or if it is at least customizable (to have a more ivy-like experience). What I thought maybe would be to add the ellipsis in the same line of the last candidate like: aaa bbb ccc... or so... But it was not good enough in my opinion. WDYT? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 0:04 ` Ergus @ 2020-11-06 2:44 ` Stefan Monnier 2020-11-06 8:42 ` Gregory Heytings via Emacs development discussions. 1 sibling, 0 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-06 2:44 UTC (permalink / raw To: Ergus; +Cc: Andrii Kolomoiets, emacs-devel > aaa > bbb > ccc... While '}' is not a great terminator in vertical mode, we can use something else, like a "thin horizontal line" or something. The advantage of using a terminator sign rather than a continuation sign is that we don't need to worry about pixel-precise sizing. Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 0:04 ` Ergus 2020-11-06 2:44 ` Stefan Monnier @ 2020-11-06 8:42 ` Gregory Heytings via Emacs development discussions. 1 sibling, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-06 8:42 UTC (permalink / raw To: Ergus; +Cc: emacs-devel > > I agree that taking a like only for the ellipsis is inefficient witht he > space. Actually the ellipsis is something I would like to discuss, but > nobody put attention on it before ;( > That's not correct, both Stefan and me commented on this earlier. My opinion is that there is no need to show visually that there are more candidates, most (all?) other programs I use never do that, they just display a list of candidates, and it becomes clear that there are no more candidates when the list shrinks after enough input. Stefan's opinion is that one could add a visual indication at the end of the candidate list, which means that when one does _not_ see that indication there are more candidates. It's a "non-ellipsis" if you want, a "this is the end" indication. For example: Find file: a[] aaa abb acc| (where [] represents the cursor and | the end indication). ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:29 ` Stefan Monnier 2020-11-06 0:04 ` Ergus @ 2020-11-06 10:26 ` Andrii Kolomoiets 1 sibling, 0 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-06 10:26 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 672 bytes --] Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I'm a bit late to the icomplete-vertical party, but please let me show >> you my approach at supporting "\n" in 'icomplete-separator'. > > A side-note: I think the use of "..." to indicate that there are more > entries is a bad idea. Better represent it with the absence of > a terminator (e.g. in the normal icomplete-mode, it basically means > replace "...}" with ""). It will make the code simpler, more robust, > and a side benefit is that it will make slightly more efficient use of > the screen real estate. Good point! Removed ellipsis completelly. Or it was intended to remove it only in vertical mode? [-- Attachment #2: icomplete-vertical.diff --] [-- Type: text/x-patch, Size: 6177 bytes --] diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 4e546807b7..2fe740292c 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -687,33 +687,32 @@ icomplete-completions ;; a prefix of most, or something else. (compare (compare-strings name nil nil most nil nil completion-ignore-case)) - (ellipsis (if (char-displayable-p ?…) "…" "...")) (determ (unless (or (eq t compare) (eq t most-try) (= (setq compare (1- (abs compare))) (length most))) (concat open-bracket - (cond - ((= compare (length name)) + ;; Don't bother truncating if it doesn't gain + ;; us at least 2 columns. + (if (< compare 2) + most ;; Typical case: name is a prefix. - (substring most compare)) - ;; Don't bother truncating if it doesn't gain - ;; us at least 2 columns. - ((< compare (+ 2 (string-width ellipsis))) most) - (t (concat ellipsis (substring most compare)))) + (substring most compare)) close-bracket))) + (vertical (string-match "\n" icomplete-separator)) ;;"-prospects" - more than one candidate - (prospects-len (+ (string-width - (or determ (concat open-bracket close-bracket))) - (string-width icomplete-separator) - (+ 2 (string-width ellipsis)) ;; take {…} into account - (string-width (buffer-string)))) + (prospects-len (unless vertical + (+ (string-width + (if determ (concat determ "{") open-bracket)) + (string-width (buffer-string))))) (prospects-max - ;; Max total length to use, including the minibuffer content. - (* (+ icomplete-prospects-height - ;; If the minibuffer content already uses up more than - ;; one line, increase the allowable space accordingly. - (/ prospects-len (window-width))) - (window-width))) + (if vertical + icomplete-prospects-height + ;; Max total length to use, including the minibuffer content. + (* (+ icomplete-prospects-height + ;; If the minibuffer content already uses up more than + ;; one line, increase the allowable space accordingly. + (/ prospects-len (window-width))) + (window-width)))) ;; Find the common prefix among `comps'. ;; We can't use the optimization below because its assumptions ;; aren't always true, e.g. when completion-cycling (bug#10850): @@ -730,7 +729,9 @@ icomplete-completions ;; is already displayed via `most'. (string-prefix-p prefix most t) (length prefix))) ;;) - prospects comp limit) + (limit (when vertical + (> (length comps) prospects-max))) + prospects comp) (if (or (eq most-try t) (not (consp (cdr comps)))) (setq prospects nil) (when (member name comps) @@ -753,24 +754,38 @@ icomplete-completions ;; completion field. (setq determ (concat open-bracket "" close-bracket))) ;; Compute prospects for display. - (while (and comps (not limit)) - (setq comp - (if prefix-len (substring (car comps) prefix-len) (car comps)) - comps (cdr comps)) - (setq prospects-len - (+ (string-width comp) - (string-width icomplete-separator) - prospects-len)) - (if (< prospects-len prospects-max) - (push comp prospects) - (setq limit t)))) - (setq prospects (nreverse prospects)) - ;; Decorate first of the prospects. - (when prospects - (let ((first (copy-sequence (pop prospects)))) - (put-text-property 0 (length first) - 'face 'icomplete-first-match first) - (push first prospects))) + (if vertical + (while (and comps (> prospects-max 0)) + (setq prospects-max (1- prospects-max)) + (push (if prefix-len + (substring (pop comps) prefix-len) + (pop comps)) + prospects)) + (while (and comps (not limit)) + (setq comp (if prefix-len + (substring (pop comps) prefix-len) + (pop comps))) + (setq prospects-len + (+ (string-width comp) + prospects-len)) + ;; There be the } after last comp. Add 1 to prospects-len if last comp. + (if (<= (+ (if comps 0 1) prospects-len) prospects-max) + (push comp prospects) + (setq limit t)) + ;; Add separator if there are more comps + (when (and comps (not limit)) + (setq prospects-len + (+ (string-width icomplete-separator) + prospects-len)) + (unless (<= prospects-len prospects-max) + (setq limit t))))) + (when prospects + (setq prospects (nreverse prospects)) + ;; Decorate first of the prospects. + (let ((first (copy-sequence (pop prospects)))) + (put-text-property 0 (length first) + 'face 'icomplete-first-match first) + (push first prospects)))) ;; Restore the base-size info, since completion-all-sorted-completions ;; is cached. (if last (setcdr last base-size)) @@ -778,8 +793,7 @@ icomplete-completions (concat determ "{" (mapconcat 'identity prospects icomplete-separator) - (and limit (concat icomplete-separator ellipsis)) - "}") + (unless limit "}")) (concat determ " [Matched]")))))) ;;; Iswitchb compatibility ^ permalink raw reply related [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:10 Andrii Kolomoiets 2020-11-05 23:29 ` Stefan Monnier @ 2020-11-05 23:57 ` Ergus 2020-11-06 8:43 ` Gregory Heytings via Emacs development discussions. 2020-11-06 12:36 ` Andrii Kolomoiets 2020-11-06 5:52 ` Jean Louis 2 siblings, 2 replies; 115+ messages in thread From: Ergus @ 2020-11-05 23:57 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel Hi Andrii: Yes, this is more or less the same in implemented in the branch. Please look at the emails I sent to Gregory some months ago about this approach and Gregory's answer. What you do in the patch is basically the same that is in the branch, but there are considered some more user requested cases like multiple \n in the separator, using a different font size in the minibuffer and display the completions in window-only frames like in mapple, or having a first candidate longer than a single line/occupying multiple lines. On Fri, Nov 06, 2020 at 01:10:20AM +0200, Andrii Kolomoiets wrote: >Hi, > >I'm a bit late to the icomplete-vertical party, but please let me show >you my approach at supporting "\n" in 'icomplete-separator'. > >The main idea is to treat the 'icomplete-prospects-height' variable >value as the amount of completions we want to see if there is "\n" in the >'icomplete-separator'. > >Please see attached patch. > >Also see attached screenshot of minibuffer-only frame after: > >emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" >M-x icomplete-mode >(setq icomplete-prospects-height 5) >(setq icomplete-hide-common-prefix nil) >(setq icomplete-separator "\n ") >(setq resize-mini-frames t) >M-x icomp > >If that approach was already discussed, please let me know. > >WDYT? > >Thanks! ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:57 ` Ergus @ 2020-11-06 8:43 ` Gregory Heytings via Emacs development discussions. 2020-11-06 12:36 ` Andrii Kolomoiets 1 sibling, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-06 8:43 UTC (permalink / raw To: Ergus; +Cc: Andrii Kolomoiets, emacs-devel > > What you do in the patch is basically the same that is in the branch, > but there are considered some more user requested cases like multiple \n > in the separator, using a different font size in the minibuffer and > display the completions in window-only frames like in mapple, or having > a first candidate longer than a single line/occupying multiple lines. > The problem is that there were so far only a few "other user requested cases", and that there are other cases that were not yet requested. It is alas a too fragile solution. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:57 ` Ergus 2020-11-06 8:43 ` Gregory Heytings via Emacs development discussions. @ 2020-11-06 12:36 ` Andrii Kolomoiets 2020-11-06 15:15 ` Ergus 1 sibling, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-06 12:36 UTC (permalink / raw To: Ergus; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1732 bytes --] Ergus <spacibba@aol.com> writes: > What you do in the patch is basically the same that is in the branch, IMO the key differece is that the patch doesn't do any calculation of completions count based on line height, count of "\n" in separator etc. I propose use the 'icomplete-prospects-height' value as the count of completions that must be shown. Let's see how the patch deals with mentioned user requests: > multiple \n in the separator (setq icomplete-hide-common-prefix nil) (setq icomplete-separator "\n----------\n") (setq icomplete-prospects-height 3) (completing-read "prompt: " '("completion1" "completion2" "completion3")) Doesn't matter how many \n is in the separator. Just show 3 completions. See multiple-n.png attached. > using a different font size in the minibuffer Still show 3 completions, some text may doesn't fit in case the font size will be too big. > display the completions in window-only frames like in mapple Thats actually why the patch was implemented. See, maple-minibuffer-mode uses fixed frame height so the branch is show some completions that fits based on frame-pixel-height. But mini-frame-mode, which I use, uses resizeable minibuffer-only frame to show the minibuffer content and the branch doesn't show any completions. I mention this issue earlier: https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00124.html In this usecase the patch behave better. > having a first candidate longer than a single line/occupying multiple > lines Still show 3 completions, but minibuffer window may occupy more than 3 lines. See long-completions.png attached. Oh, link to mini-frame-mode if needed: https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el [-- Attachment #2: multiple-n.png --] [-- Type: image/png, Size: 21043 bytes --] [-- Attachment #3: long-completions.png --] [-- Type: image/png, Size: 31901 bytes --] ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 12:36 ` Andrii Kolomoiets @ 2020-11-06 15:15 ` Ergus 2020-11-08 20:14 ` Andrii Kolomoiets 0 siblings, 1 reply; 115+ messages in thread From: Ergus @ 2020-11-06 15:15 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel On Fri, Nov 06, 2020 at 02:36:14PM +0200, Andrii Kolomoiets wrote: >Ergus <spacibba@aol.com> writes: > >> What you do in the patch is basically the same that is in the branch, > >IMO the key differece is that the patch doesn't do any calculation of >completions count based on line height, count of "\n" in separator etc. >I propose use the 'icomplete-prospects-height' value as the count of >completions that must be shown. > >Let's see how the patch deals with mentioned user requests: > Yes, I understand that; actually the height calculation was made because of this: ``` (setq icomplete-show-matches-on-no-input t) (icomplete-mode 1) (setq icomplete-separator "\n") (defface vmacs-minibuffer-font `((t :inherit default :height 1.3)) "The default font for minibuffer buffer. Monospaced font whihc is fixed idth and height is recommended." :group 'minibuffer) (defun vmacs-minibuffer-hook() (set (make-local-variable 'buffer-face-mode-face) 'vmacs-minibuffer-font) (buffer-face-mode t)) (add-hook 'minibuffer-setup-hook #'vmacs-minibuffer-hook) (setq max-mini-window-height 10) ;; add this line ``` in here: https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01578.html Up to some months ago the pixel calculation was required because showing more candidates than fit in the minibuffer hided the prompt. There were long discussions related with that. Up to now there is a fix in the display engine, but I don't really know if we could totally ignore the max-height with that. Probably we could relax it a bit, but not totally. >> multiple \n in the separator > >(setq icomplete-hide-common-prefix nil) >(setq icomplete-separator "\n----------\n") >(setq icomplete-prospects-height 3) >(completing-read "prompt: " '("completion1" "completion2" "completion3")) > >Doesn't matter how many \n is in the separator. Just show 3 >completions. >See multiple-n.png attached. > This of course is supposed to work. But try with more candidates like 10 or so. In the branch I basically take the min between the icomplete-prospects-height and the number of candidates that fit in max-mini-window-height. >> using a different font size in the minibuffer > >Still show 3 completions, some text may doesn't fit in case the font >size will be too big. > I think that with the Eli fix probably we could relax at least this part a bit. >> display the completions in window-only frames like in mapple > >Thats actually why the patch was implemented. See, >maple-minibuffer-mode uses fixed frame height so the branch is show some >completions that fits based on frame-pixel-height. But mini-frame-mode, >which I use, uses resizeable minibuffer-only frame to show the >minibuffer content and the branch doesn't show any completions. >I mention this issue earlier: >https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00124.html > >In this usecase the patch behave better. > I can't reproduce the issue, that's why I didn't reply; sorry. In your use case I suppose it works "better" because the patch totally ignores the window height to fit; which, as I mention before, I am not sure is something we can do in the general case due to the prompt issue. If the prompt issue is totally away, we could; but I will need some confirmation from Eli or Stefan; but last time I tried it was still there. In any case if in your case it is broken, then we probably need another considerations. >> having a first candidate longer than a single line/occupying multiple >> lines > >Still show 3 completions, but minibuffer window may occupy more than 3 >lines. >See long-completions.png attached. > >Oh, link to mini-frame-mode if needed: >https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el > Best, Ergus ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 15:15 ` Ergus @ 2020-11-08 20:14 ` Andrii Kolomoiets 2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions. 2020-11-09 3:28 ` Eli Zaretskii 0 siblings, 2 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-08 20:14 UTC (permalink / raw To: Ergus; +Cc: eliz, monnier, emacs-devel Ergus <spacibba@aol.com> writes: I've checked your receipts on nearly recent master with the patch applied on GTK3 build under Gnome and on NS build. >> I propose use the 'icomplete-prospects-height' value as the count of >> completions that must be shown. >> > Yes, I understand that; actually the height calculation was made because > of this: > > (defface vmacs-minibuffer-font > `((t :inherit default :height 1.3)) > > Up to some months ago the pixel calculation was required because showing > more candidates than fit in the minibuffer hided the prompt. There were > long discussions related with that. With changed minibuffer font size the prompt is visible. >>> multiple \n in the separator > This of course is supposed to work. But try with more candidates like 10 Prompt is still visible. >>> display the completions in window-only frames like in mapple >> >> Thats actually why the patch was implemented. See, >> maple-minibuffer-mode uses fixed frame height so the branch is show some >> completions that fits based on frame-pixel-height. But mini-frame-mode, >> which I use, uses resizeable minibuffer-only frame to show the >> minibuffer content and the branch doesn't show any completions. >> I mention this issue earlier: >> https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00124.html >> >> In this usecase the patch behave better. >> > I can't reproduce the issue, that's why I didn't reply; sorry. What build/OS you are using? I can reproduce it at least on NS and GTK3 builds. Doesn't minibuffer-only frame became the minimal width and height for you right after evaluating '(setq resize-mini-frames t)'? > In your use case I suppose it works "better" because the patch totally > ignores the window height to fit; which, as I mention before, I am not > sure is something we can do in the general case due to the prompt > issue. > > If the prompt issue is totally away, we could; but I will need some > confirmation from Eli or Stefan; but last time I tried it was still > there. I didn't saw the prompt issue. Stefan and Eli, can you please confirm that the prompt issue is totally gone? Thanks. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-08 20:14 ` Andrii Kolomoiets @ 2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions. 2020-11-08 20:36 ` Andrii Kolomoiets 2020-11-09 3:28 ` Eli Zaretskii 1 sibling, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-08 20:30 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel >> If the prompt issue is totally away, we could; but I will need some >> confirmation from Eli or Stefan; but last time I tried it was still >> there. > > I didn't saw the prompt issue. Stefan and Eli, can you please confirm > that the prompt issue is totally gone? > It all depends how you define "prompt issue". If you define it as "the prompt should be visible unless it's impossible", then it is gone in something like 99% of the cases. If you define it as "the prompt should generally be visible but can in some rare cases be hidden", then it is totally gone. With the former definition however, Ergus' solution does not solve all the 1% remaining cases. The only correct solution to solve all these 1% remaining cases is to ask redisplay to start displaying the minibuffer at beginning of buffer (point-min). ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions. @ 2020-11-08 20:36 ` Andrii Kolomoiets 0 siblings, 0 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-08 20:36 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel Gregory Heytings <ghe@sdf.org> writes: >>> If the prompt issue is totally away, we could; but I will need some >>> confirmation from Eli or Stefan; but last time I tried it was still >>> there. >> >> I didn't saw the prompt issue. Stefan and Eli, can you please >> confirm that the prompt issue is totally gone? > > With the former definition however, Ergus' solution does not solve all > the 1% remaining cases. The only correct solution to solve all these > 1% remaining cases is to ask redisplay to start displaying the > minibuffer at beginning of buffer (point-min). Do you have any receipt for that 1%? Please share it with me if you have one. TIA! ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-08 20:14 ` Andrii Kolomoiets 2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions. @ 2020-11-09 3:28 ` Eli Zaretskii 2020-11-09 21:04 ` Andrii Kolomoiets 1 sibling, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-09 3:28 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: spacibba, monnier, emacs-devel > From: Andrii Kolomoiets <andreyk.mad@gmail.com> > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org > Date: Sun, 08 Nov 2020 22:14:07 +0200 > > I didn't saw the prompt issue. Stefan and Eli, can you please confirm > that the prompt issue is totally gone? Can you show the recipe (or recipes) which I should try in order to answer your question? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-09 3:28 ` Eli Zaretskii @ 2020-11-09 21:04 ` Andrii Kolomoiets 2020-11-10 15:13 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-09 21:04 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2568 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> From: Andrii Kolomoiets <andreyk.mad@gmail.com> >> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org >> Date: Sun, 08 Nov 2020 22:14:07 +0200 >> >> I didn't saw the prompt issue. Stefan and Eli, can you please confirm >> that the prompt issue is totally gone? > > Can you show the recipe (or recipes) which I should try in order to > answer your question? While preparing receipt, I've found that the bug with the prompt is still exists. The receipt should be checked using feature/icomplete-vertical branch and using patched master branch (patch attached). Code that need to be put to the *scratch* buffer: (setq resize-mini-frames t) (icomplete-mode 1) (setq icomplete-separator "\n--\n") (setq icomplete-show-matches-on-no-input t) (setq icomplete-hide-common-prefix nil) (setq icomplete-prospects-height 10) (add-hook 'minibuffer-setup-hook (lambda () (set (make-local-variable 'face-remapping-alist) '((default :height 1.3))))) (setq completion-items (mapcar (lambda (x) (format "Multiline completion item to occupy \ several lines %s" x)) '(1 2 3 4 5 6 7 8 9 0))) (completing-read "This prompt is visible: " completion-items) (completing-read "This line of the prompt is not visible because the propmt \ occupy several lines: " completion-items) Part one. 1. emacs -Q 2. Put the code above to the *scratch* buffer 3. M-x eval-buffer feature/icomplete-vertical and patched master: Prompt is visible. 4. TAB (to complete the common part) feature/icomplete-vertical: Prompt is visible. Patched master: Prompt is hidden. 5. RET feature/icomplete-vertical: Prompt is visible. Patched master: The firs line of the prompt is hidden. 6. TAB feature/icomplete-vertical: Prompt is visible. Patched master: Prompt is hidden. Part two. 1. emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" 2. Put the code above to the *scratch* buffer 3. M-x eval-buffer feature/icomplete-vertical: Minibuffer frame remains minimum height and width, prompt is hidden. Patched master: Prompt is visible, minibuffer frame resized to fit all the 10 completion items. Well, the "part one" is for sure the answer to my own question :) But because of the "part two" I'm still very like the idea to treat 'icomplete-prospects-height' as completions count and not as the lines count. So I have another question: that prompt issue in patched master from the "part one" must be solved in icomplete-mode or somewhere in the display engine? Thanks! [-- Attachment #2: icomplete-vertical.diff --] [-- Type: text/x-patch, Size: 6177 bytes --] diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 4e546807b7..2fe740292c 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -687,33 +687,32 @@ icomplete-completions ;; a prefix of most, or something else. (compare (compare-strings name nil nil most nil nil completion-ignore-case)) - (ellipsis (if (char-displayable-p ?…) "…" "...")) (determ (unless (or (eq t compare) (eq t most-try) (= (setq compare (1- (abs compare))) (length most))) (concat open-bracket - (cond - ((= compare (length name)) + ;; Don't bother truncating if it doesn't gain + ;; us at least 2 columns. + (if (< compare 2) + most ;; Typical case: name is a prefix. - (substring most compare)) - ;; Don't bother truncating if it doesn't gain - ;; us at least 2 columns. - ((< compare (+ 2 (string-width ellipsis))) most) - (t (concat ellipsis (substring most compare)))) + (substring most compare)) close-bracket))) + (vertical (string-match "\n" icomplete-separator)) ;;"-prospects" - more than one candidate - (prospects-len (+ (string-width - (or determ (concat open-bracket close-bracket))) - (string-width icomplete-separator) - (+ 2 (string-width ellipsis)) ;; take {…} into account - (string-width (buffer-string)))) + (prospects-len (unless vertical + (+ (string-width + (if determ (concat determ "{") open-bracket)) + (string-width (buffer-string))))) (prospects-max - ;; Max total length to use, including the minibuffer content. - (* (+ icomplete-prospects-height - ;; If the minibuffer content already uses up more than - ;; one line, increase the allowable space accordingly. - (/ prospects-len (window-width))) - (window-width))) + (if vertical + icomplete-prospects-height + ;; Max total length to use, including the minibuffer content. + (* (+ icomplete-prospects-height + ;; If the minibuffer content already uses up more than + ;; one line, increase the allowable space accordingly. + (/ prospects-len (window-width))) + (window-width)))) ;; Find the common prefix among `comps'. ;; We can't use the optimization below because its assumptions ;; aren't always true, e.g. when completion-cycling (bug#10850): @@ -730,7 +729,9 @@ icomplete-completions ;; is already displayed via `most'. (string-prefix-p prefix most t) (length prefix))) ;;) - prospects comp limit) + (limit (when vertical + (> (length comps) prospects-max))) + prospects comp) (if (or (eq most-try t) (not (consp (cdr comps)))) (setq prospects nil) (when (member name comps) @@ -753,24 +754,38 @@ icomplete-completions ;; completion field. (setq determ (concat open-bracket "" close-bracket))) ;; Compute prospects for display. - (while (and comps (not limit)) - (setq comp - (if prefix-len (substring (car comps) prefix-len) (car comps)) - comps (cdr comps)) - (setq prospects-len - (+ (string-width comp) - (string-width icomplete-separator) - prospects-len)) - (if (< prospects-len prospects-max) - (push comp prospects) - (setq limit t)))) - (setq prospects (nreverse prospects)) - ;; Decorate first of the prospects. - (when prospects - (let ((first (copy-sequence (pop prospects)))) - (put-text-property 0 (length first) - 'face 'icomplete-first-match first) - (push first prospects))) + (if vertical + (while (and comps (> prospects-max 0)) + (setq prospects-max (1- prospects-max)) + (push (if prefix-len + (substring (pop comps) prefix-len) + (pop comps)) + prospects)) + (while (and comps (not limit)) + (setq comp (if prefix-len + (substring (pop comps) prefix-len) + (pop comps))) + (setq prospects-len + (+ (string-width comp) + prospects-len)) + ;; There be the } after last comp. Add 1 to prospects-len if last comp. + (if (<= (+ (if comps 0 1) prospects-len) prospects-max) + (push comp prospects) + (setq limit t)) + ;; Add separator if there are more comps + (when (and comps (not limit)) + (setq prospects-len + (+ (string-width icomplete-separator) + prospects-len)) + (unless (<= prospects-len prospects-max) + (setq limit t))))) + (when prospects + (setq prospects (nreverse prospects)) + ;; Decorate first of the prospects. + (let ((first (copy-sequence (pop prospects)))) + (put-text-property 0 (length first) + 'face 'icomplete-first-match first) + (push first prospects)))) ;; Restore the base-size info, since completion-all-sorted-completions ;; is cached. (if last (setcdr last base-size)) @@ -778,8 +793,7 @@ icomplete-completions (concat determ "{" (mapconcat 'identity prospects icomplete-separator) - (and limit (concat icomplete-separator ellipsis)) - "}") + (unless limit "}")) (concat determ " [Matched]")))))) ;;; Iswitchb compatibility ^ permalink raw reply related [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-09 21:04 ` Andrii Kolomoiets @ 2020-11-10 15:13 ` Eli Zaretskii 2020-11-10 17:18 ` Andrii Kolomoiets 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-10 15:13 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: spacibba, monnier, emacs-devel > From: Andrii Kolomoiets <andreyk.mad@gmail.com> > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Mon, 09 Nov 2020 23:04:01 +0200 > > >> I didn't saw the prompt issue. Stefan and Eli, can you please confirm > >> that the prompt issue is totally gone? > > > > Can you show the recipe (or recipes) which I should try in order to > > answer your question? > > While preparing receipt, I've found that the bug with the prompt is > still exists. Does this mean I no longer need to answer your question? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 15:13 ` Eli Zaretskii @ 2020-11-10 17:18 ` Andrii Kolomoiets 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. ` (2 more replies) 0 siblings, 3 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-10 17:18 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> While preparing receipt, I've found that the bug with the prompt is >> still exists. > > Does this mean I no longer need to answer your question? Yes. But no :) In 'emacs -Q', evaluate buffer with the following code: (defvar o (make-overlay 0 0 nil t t)) (minibuffer-with-setup-hook (lambda () (set (make-local-variable 'face-remapping-alist) '((default :height 1.3))) (move-overlay o (point) (point) (current-buffer)) (let ((text (mapconcat #'identity '("Some" "text" "that" "will" "not" "fit" "the" "minibuffer" "window") "\n"))) (put-text-property 0 1 'cursor t text) (overlay-put o 'after-string text))) (read-string "Multiline\nprompt: ")) Is it possible to make the prompt visible? Should I file bug report for this? TIA! ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 17:18 ` Andrii Kolomoiets @ 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. 2020-11-11 9:41 ` Andrii Kolomoiets 2020-11-10 18:23 ` Eli Zaretskii 2020-11-10 20:01 ` Stefan Monnier 2 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-10 18:18 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: Eli Zaretskii, spacibba, monnier, emacs-devel > > (defvar o (make-overlay 0 0 nil t t)) > (minibuffer-with-setup-hook > (lambda () > (set (make-local-variable 'face-remapping-alist) > '((default :height 1.3))) > (move-overlay o (point) (point) (current-buffer)) > (let ((text (mapconcat > #'identity > '("Some" "text" "that" "will" "not" "fit" > "the" "minibuffer" "window") > "\n"))) > (put-text-property 0 1 'cursor t text) > (overlay-put o 'after-string text))) > (read-string "Multiline\nprompt: ")) > This is one of the cases where it does not work, indeed. Another one is (again with emacs -Q): (let (w bd) (setq w 60) (setq bd (concat (temporary-file-directory) (make-string w ?a) "/")) (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t)) (setq default-directory bd) (set-frame-height nil 20) (set-frame-width nil (+ (length bd) 10)) (icomplete-mode) (setq icomplete-separator "\n") (call-interactively 'insert-file)) > > Is it possible to make the prompt visible? > Yes it is. As I already told you, to make the prompt visible in all cases (when it is not impossible to make it visible) it is necessary to ask redisplay to start displaying at the beginning of the buffer. I provided short and simple Lisp-only solution for this: (defvar-local start-display-at-beginning-of-minibuffer nil) (defun start-display-at-beginning-of-minibuffer (&rest args) (when (and start-display-at-beginning-of-minibuffer (minibufferp)) (set-window-start-at-begin (point-min) (point)))) (defun set-window-start-at-begin (beg end) (when (< (+ beg 2) end) (set-window-start nil beg) (unless (pos-visible-in-window-p end nil t) (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end)))) (add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibuffer) (add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer) Just add (setq start-display-at-beginning-of-minibuffer t) in your minibuffer-with-setup-hook lambda, and it will work as you expect it to work. As I said a few days ago in the "Feature branches review please" thread, the problem of this solution is that Eli doesn't like it. He thinks another solution, using a text property that would be put on the prompt, should be implemented. Stefan thinks yet another solution, using the buffer redisplay routines instead of using a specific redisplay code for minibuffers, should be used. > > Should I file bug report for this? > I think you should read the other relevant bug reports first (bug#24293, bug#39379, bug#43519 and bug#43572). AFAIU the remaining 1% cases which are demonstrated by the two above recipes are not considered important enough to be classified as "bugs", so it is more a "feature request". ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 9:41 ` Andrii Kolomoiets 0 siblings, 0 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-11 9:41 UTC (permalink / raw To: Gregory Heytings; +Cc: Eli Zaretskii, emacs-devel, spacibba, monnier Gregory Heytings <ghe@sdf.org> writes: >> Should I file bug report for this? > > I think you should read the other relevant bug reports first > (bug#24293, bug#39379, bug#43519 and bug#43572). AFAIU the remaining > 1% cases which are demonstrated by the two above recipes are not > considered important enough to be classified as "bugs", so it is more > a "feature request". Thanks! I'll take a look on that bugs. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 17:18 ` Andrii Kolomoiets 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. @ 2020-11-10 18:23 ` Eli Zaretskii 2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions. 2020-11-10 21:09 ` Andrii Kolomoiets 2020-11-10 20:01 ` Stefan Monnier 2 siblings, 2 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-10 18:23 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: spacibba, monnier, emacs-devel > From: Andrii Kolomoiets <andreyk.mad@gmail.com> > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Tue, 10 Nov 2020 19:18:18 +0200 > > (defvar o (make-overlay 0 0 nil t t)) > (minibuffer-with-setup-hook > (lambda () > (set (make-local-variable 'face-remapping-alist) > '((default :height 1.3))) > (move-overlay o (point) (point) (current-buffer)) > (let ((text (mapconcat > #'identity > '("Some" "text" "that" "will" "not" "fit" > "the" "minibuffer" "window") > "\n"))) > (put-text-property 0 1 'cursor t text) > (overlay-put o 'after-string text))) > (read-string "Multiline\nprompt: ")) > > Is it possible to make the prompt visible? Should I file bug report for this? What is the bug here? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 18:23 ` Eli Zaretskii @ 2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions. 2020-11-10 19:27 ` Eli Zaretskii 2020-11-10 21:09 ` Andrii Kolomoiets 1 sibling, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-10 19:17 UTC (permalink / raw To: Eli Zaretskii; +Cc: Andrii Kolomoiets, spacibba, monnier, emacs-devel >> (defvar o (make-overlay 0 0 nil t t)) >> (minibuffer-with-setup-hook >> (lambda () >> (set (make-local-variable 'face-remapping-alist) >> '((default :height 1.3))) >> (move-overlay o (point) (point) (current-buffer)) >> (let ((text (mapconcat >> #'identity >> '("Some" "text" "that" "will" "not" "fit" >> "the" "minibuffer" "window") >> "\n"))) >> (put-text-property 0 1 'cursor t text) >> (overlay-put o 'after-string text))) >> (read-string "Multiline\nprompt: ")) >> >> Is it possible to make the prompt visible? Should I file bug report for this? > > What is the bug here? > The "bug" is that the word "Multiline" is not visible, only the word "prompt:" is. This has been discussed again and again, I don't understand why it is not yet clear for you. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions. @ 2020-11-10 19:27 ` Eli Zaretskii 2020-11-10 20:00 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-10 19:27 UTC (permalink / raw To: Gregory Heytings; +Cc: spacibba, monnier, andreyk.mad, emacs-devel > Date: Tue, 10 Nov 2020 19:17:30 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, spacibba@aol.com, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > >> (defvar o (make-overlay 0 0 nil t t)) > >> (minibuffer-with-setup-hook > >> (lambda () > >> (set (make-local-variable 'face-remapping-alist) > >> '((default :height 1.3))) > >> (move-overlay o (point) (point) (current-buffer)) > >> (let ((text (mapconcat > >> #'identity > >> '("Some" "text" "that" "will" "not" "fit" > >> "the" "minibuffer" "window") > >> "\n"))) > >> (put-text-property 0 1 'cursor t text) > >> (overlay-put o 'after-string text))) > >> (read-string "Multiline\nprompt: ")) > >> > >> Is it possible to make the prompt visible? Should I file bug report for this? > > > > What is the bug here? > > The "bug" is that the word "Multiline" is not visible, only the word > "prompt:" is. This has been discussed again and again, I don't understand > why it is not yet clear for you. I asked Andrii. I'm not sure if he thinks the same as you, but in case he does: the text inserted into the minibuffer doesn't fit. So in this situation, Emacs can either (a) start display from the prompt's beginning, or (b) end the display at the end of the text, or (c) start display somewhere in the middle, to show the end of the prompt and some of the text after it. Whatever Emacs does, some of the text will not be visible. How should Emacs know which of the possibilities is the correct one in this case? A "bug" is when there's an obvious choice between the possible outcomes, but Emacs behaves not in the obvious way. I don't think this is the situation here. Thus my question. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 19:27 ` Eli Zaretskii @ 2020-11-10 20:00 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-10 20:00 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, andreyk.mad, emacs-devel >>>> (defvar o (make-overlay 0 0 nil t t)) >>>> (minibuffer-with-setup-hook >>>> (lambda () >>>> (set (make-local-variable 'face-remapping-alist) >>>> '((default :height 1.3))) >>>> (move-overlay o (point) (point) (current-buffer)) >>>> (let ((text (mapconcat >>>> #'identity >>>> '("Some" "text" "that" "will" "not" "fit" >>>> "the" "minibuffer" "window") >>>> "\n"))) >>>> (put-text-property 0 1 'cursor t text) >>>> (overlay-put o 'after-string text))) >>>> (read-string "Multiline\nprompt: ")) >>>> >>>> Is it possible to make the prompt visible? Should I file bug report >>>> for this? >>> >>> What is the bug here? >> >> The "bug" is that the word "Multiline" is not visible, only the word >> "prompt:" is. This has been discussed again and again, I don't >> understand why it is not yet clear for you. > > I asked Andrii. I'm not sure if he thinks the same as you > It's obvious he does, given the recipe. > > but in case he does: the text inserted into the minibuffer doesn't fit. > So in this situation, Emacs can either (a) start display from the > prompt's beginning, or (b) end the display at the end of the text > AFAIU (b) is not possible in this case, because the text that doesn't fit is in an overlay. > > or (c) start display somewhere in the middle, to show the end of the > prompt and some of the text after it. Whatever Emacs does, some of the > text will not be visible. How should Emacs know which of the > possibilities is the correct one in this case? > Emacs can't know. As I already said, this should be decided by the application programmer, which isn't possible ATM, except with my solution. > > A "bug" is when there's an obvious choice between the possible outcomes, > but Emacs behaves not in the obvious way. I don't think this is the > situation here. Thus my question. > Note that I have put the word "bug" between quotes, I do not think this is a bug. It's a missing feature. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 18:23 ` Eli Zaretskii 2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions. @ 2020-11-10 21:09 ` Andrii Kolomoiets 2020-11-11 8:27 ` martin rudalics 2020-11-11 16:30 ` Eli Zaretskii 1 sibling, 2 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-10 21:09 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> (defvar o (make-overlay 0 0 nil t t)) >> (minibuffer-with-setup-hook >> (lambda () >> (set (make-local-variable 'face-remapping-alist) >> '((default :height 1.3))) >> (move-overlay o (point) (point) (current-buffer)) >> (let ((text (mapconcat >> #'identity >> '("Some" "text" "that" "will" "not" "fit" >> "the" "minibuffer" "window") >> "\n"))) >> (put-text-property 0 1 'cursor t text) >> (overlay-put o 'after-string text))) >> (read-string "Multiline\nprompt: ")) >> >> Is it possible to make the prompt visible? Should I file bug report >> for this? > > What is the bug here? I don't take the overlay text as the actual text but rather like a hint or helper. E.g. in icomplete-mode overlay text shows what part of the text can be automatically completed. Overlay text can be completelly hidden and even in this case I will be able to enter the text. The prompt is more important. Imagine there are two prompts: "Selected file will be deleted. Select file: " and "Selected file will be opened. Selected file: ". I certainly don't want to see only "Select file:" because all the space is occupied by hints. Hide hints but show me the full prompt. The point is more important than the prompt, obviously. I must see where and what I typed. IMO the minibuffer behavior about the prompt, the text and the overlay should be: show as much text before point as possible (including the prompt), then show the rest of the text (in case the point is not at the end of the text) and then show the overlay text. And here I come to the answer to your question: for me, the bug here is that the prompt is hidden in favor of the overlay text. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 21:09 ` Andrii Kolomoiets @ 2020-11-11 8:27 ` martin rudalics 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. ` (2 more replies) 2020-11-11 16:30 ` Eli Zaretskii 1 sibling, 3 replies; 115+ messages in thread From: martin rudalics @ 2020-11-11 8:27 UTC (permalink / raw To: Andrii Kolomoiets, Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel > And here I come to the answer to your question: for me, the bug here is > that the prompt is hidden in favor of the overlay text. Applications have to accept that users want their minibuffer windows to show just one line. Or at most two lines. Or three ... martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 8:27 ` martin rudalics @ 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:57 ` Jean Louis 2020-11-11 9:38 ` Andrii Kolomoiets 2020-11-11 18:52 ` Drew Adams 2 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 9:07 UTC (permalink / raw To: martin rudalics Cc: Andrii Kolomoiets, Eli Zaretskii, spacibba, monnier, emacs-devel >> And here I come to the answer to your question: for me, the bug here is >> that the prompt is hidden in favor of the overlay text. > > Applications have to accept that users want their minibuffer windows to > show just one line. Or at most two lines. Or three ... > I agree with you, except that I would not write "users want" but "some users want". At the same time, applications should be given the possibility to override the current only behavior, which starts displaying at the beginning of the minibuffer line on which the cursor is. Applications should have the possibility to give a hint to redisplay that, when it is possible (that is, when users have not asked for a single line minibuffer for example) displaying should start at the beginning of the minibuffer (= point-min). ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 15:57 ` Jean Louis 0 siblings, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 15:57 UTC (permalink / raw To: Gregory Heytings Cc: spacibba, Andrii Kolomoiets, emacs-devel, martin rudalics, monnier, Eli Zaretskii * Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-11 12:08]: > > > > And here I come to the answer to your question: for me, the bug here > > > is that the prompt is hidden in favor of the overlay text. > > > > Applications have to accept that users want their mini-buffer windows to > > show just one line. Or at most two lines. Or three ... > > > > I agree with you, except that I would not write "users want" but "some users > want". > > At the same time, applications should be given the possibility to override > the current only behavior, which starts displaying at the beginning of the > minibuffer line on which the cursor is. Applications should have the > possibility to give a hint to redisplay that, when it is possible (that is, > when users have not asked for a single line minibuffer for example) > displaying should start at the beginning of the minibuffer (= point-min). In relation to this last line above "displaying should start..." I do not agree to that detail. This may also apply to other completion packages within or outside Emacs. Normally when minibuffer is opened there can be some default and user decides if to complete or not. To put a possible match in the space where I have my input is capricious choice where user did not decide about it. I am sorry that I present maybe too many disagreements, it is not meant like that. This is only for thinking. I do not want as user for program to give me matches into space where I need to press enter to choose that match. If that is taking place then description for icomplete, ido, fido should tell that to user. Built-in completion gives me some default in the line (maybe), but it does not enter random match into the minibuffer. So as user I do not want random matches already in my minibuffer. That seams wrong. I did not even start typing. M-x (Here I can enter what I want) As if I did not start typing why it is completing? That is hypothetical question. Built-in `completing-read' does not complete for me if I as user do not want. I have to decide to press TAB to get completion. Not one time, I have to decide normally 2 times. So it is very explicit completion that does not disturb user. Any completing package should not coerce user with matches. It shall by default leave to the user option to write in the minibuffer what user wants. This may not match, but user shall be left free to write. M-x icomplete-mode "Icomplete mode disabled" C-x C-f (no completion shown, just some default) and I can write what I want, only if I press TAB two times I can complete. M-x icomplete-mode "Icomplete mode enabled" C-x C-f shows BUNCH OF UNRELATED FILES that I have not choosen neither wanted to be shown in my minibuffer. Minibuffer is disturbed and mode line jumps up. M-x helm-find-file Window splits Minibuffer says: Find files or url: /home/data1/protected/tmp and I can write anything in the minibuffer. Program does not coerce me with files not related to my choice on the place where I should maybe press enter. That this is dangerous have been shown in bug report where files can be accidentally deleted when using ido-mode. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 8:27 ` martin rudalics 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 9:38 ` Andrii Kolomoiets 2020-11-11 10:01 ` martin rudalics 2020-11-11 14:09 ` Jean Louis 2020-11-11 18:52 ` Drew Adams 2 siblings, 2 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-11 9:38 UTC (permalink / raw To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel, spacibba, monnier martin rudalics <rudalics@gmx.at> writes: >> And here I come to the answer to your question: for me, the bug here is >> that the prompt is hidden in favor of the overlay text. > > Applications have to accept that users want their minibuffer windows to > show just one line. Or at most two lines. Or three ... Also users: "Show us completions vertically" and (setq <icomplete/ido/etc>-separator "\n") ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 9:38 ` Andrii Kolomoiets @ 2020-11-11 10:01 ` martin rudalics 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. ` (2 more replies) 2020-11-11 14:09 ` Jean Louis 1 sibling, 3 replies; 115+ messages in thread From: martin rudalics @ 2020-11-11 10:01 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: Eli Zaretskii, emacs-devel, spacibba, monnier >> Applications have to accept that users want their minibuffer windows to >> show just one line. Or at most two lines. Or three ... > > Also users: "Show us completions vertically" and > (setq <icomplete/ido/etc>-separator "\n") Users shouldn't want the cake and eat it too. Any application should take care of such users. If an application has a truly expandable minibuffer window or a normal window at its hands, it can try to show completions vertically. With the default minibuffer window, it should always behave as if only one line were available. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:01 ` martin rudalics @ 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. 2020-11-11 10:53 ` martin rudalics 2020-11-11 15:32 ` Jean Louis 2020-11-11 15:26 ` Jean Louis 2020-11-11 16:06 ` Eli Zaretskii 2 siblings, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 10:21 UTC (permalink / raw To: martin rudalics Cc: Andrii Kolomoiets, Eli Zaretskii, emacs-devel, spacibba, monnier >>> Applications have to accept that users want their minibuffer windows >>> to show just one line. Or at most two lines. Or three ... >> >> Also users: "Show us completions vertically" and (setq >> <icomplete/ido/etc>-separator "\n") > > Users shouldn't want the cake and eat it too. Any application should > take care of such users. > Of course, nobody is asking to display completion candidates vertically by default. > > If an application has a truly expandable minibuffer window or a normal > window at its hands, it can try to show completions vertically. With > the default minibuffer window, it should always behave as if only one > line were available. > Why? The default value for max-mini-window-height is 0.25 (at least since Emacs 21), which means that in a default 80x24 terminal the minibuffer can be 6 lines tall. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 10:53 ` martin rudalics 2020-11-11 11:22 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:32 ` Jean Louis 1 sibling, 1 reply; 115+ messages in thread From: martin rudalics @ 2020-11-11 10:53 UTC (permalink / raw To: Gregory Heytings Cc: Eli Zaretskii, monnier, spacibba, Andrii Kolomoiets, emacs-devel >> If an application has a truly expandable minibuffer window or a normal window at its hands, it can try to show completions vertically. With the default minibuffer window, it should always behave as if only one line were available. >> > > Why? The default value for max-mini-window-height is 0.25 (at least since Emacs 21), which means that in a default 80x24 terminal the minibuffer can be 6 lines tall. I explained earlier why this is not generally true. Have a look at the code of 'window--resize-root-window-vertically'. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:53 ` martin rudalics @ 2020-11-11 11:22 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:49 ` martin rudalics 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 11:22 UTC (permalink / raw To: martin rudalics Cc: Eli Zaretskii, monnier, spacibba, Andrii Kolomoiets, emacs-devel >>> If an application has a truly expandable minibuffer window or a normal >>> window at its hands, it can try to show completions vertically. With >>> the default minibuffer window, it should always behave as if only one >>> line were available. >> >> Why? The default value for max-mini-window-height is 0.25 (at least >> since Emacs 21), which means that in a default 80x24 terminal the >> minibuffer can be 6 lines tall. > > I explained earlier why this is not generally true. Have a look at the > code of 'window--resize-root-window-vertically'. > Yes of course, you are correct, it is not always true that the minibuffer can be expanded to 0.25 * frame-height. I should have said "which means that in a default 80x24 terminal the minibuffer can _normally_ be 6 lines tall." The exceptions are however orthogonal to the request to give applications the control on how the contents of the minibuffer should preferably be displayed: should it preferably start at the beginning of buffer (point-min), or should it preferably start at the beginning of the line on which the cursor is? ATM the latter behavior is the only possibility (except with the code I sent to Andrii yesterday). ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 11:22 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 15:49 ` martin rudalics 2020-11-11 15:57 ` Eli Zaretskii 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. 0 siblings, 2 replies; 115+ messages in thread From: martin rudalics @ 2020-11-11 15:49 UTC (permalink / raw To: Gregory Heytings Cc: Eli Zaretskii, emacs-devel, monnier, Andrii Kolomoiets, spacibba > The exceptions are however orthogonal to the request to give > applications the control on how the contents of the minibuffer should > preferably be displayed: should it preferably start at the beginning > of buffer (point-min), or should it preferably start at the beginning > of the line on which the cursor is? ATM the latter behavior is the > only possibility (except with the code I sent to Andrii yesterday). The application has to make sure that when it asks for user input, the entire prompt can be seen in the minibuffer window without truncating lines. Emacs has to provide some reasonable minimum space for the minibuffer window - usually one canonical frame line. If an application asks for more than can be displayed in the minibuffer window, that application has a bug. In the worst case, it's responsible when users lose files or changes made to their buffers. Exemptions can be made in emergency situations, for example, when Emacs gets stuck with a frame that cannot be re-enlarged to some reasonable size and some user input _is_ necessary to terminate the Emacs process cleanly. But the "normal" case is as stated above. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 15:49 ` martin rudalics @ 2020-11-11 15:57 ` Eli Zaretskii 2020-11-11 16:16 ` Jean Louis 2020-11-11 17:06 ` martin rudalics 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. 1 sibling, 2 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 15:57 UTC (permalink / raw To: martin rudalics; +Cc: ghe, spacibba, monnier, andreyk.mad, emacs-devel > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca, spacibba@aol.com, > Andrii Kolomoiets <andreyk.mad@gmail.com>, emacs-devel@gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Wed, 11 Nov 2020 16:49:54 +0100 > > The application has to make sure that when it asks for user input, the > entire prompt can be seen in the minibuffer window without truncating > lines. Emacs has to provide some reasonable minimum space for the > minibuffer window - usually one canonical frame line. If an application > asks for more than can be displayed in the minibuffer window, that > application has a bug. In that case, most uses of icomplete-vertical and any similar features "have bugs". There's no chance in the world you can display all the files in a non-trivial directory vertically in a mini-window without losing some of the file names and/or some of the prompt. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 15:57 ` Eli Zaretskii @ 2020-11-11 16:16 ` Jean Louis 2020-11-11 17:06 ` martin rudalics 1 sibling, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 16:16 UTC (permalink / raw To: Eli Zaretskii Cc: spacibba, andreyk.mad, emacs-devel, martin rudalics, monnier, ghe * Eli Zaretskii <eliz@gnu.org> [2020-11-11 18:57]: > > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca, spacibba@aol.com, > > Andrii Kolomoiets <andreyk.mad@gmail.com>, emacs-devel@gnu.org > > From: martin rudalics <rudalics@gmx.at> > > Date: Wed, 11 Nov 2020 16:49:54 +0100 > > > > The application has to make sure that when it asks for user input, the > > entire prompt can be seen in the minibuffer window without truncating > > lines. Emacs has to provide some reasonable minimum space for the > > minibuffer window - usually one canonical frame line. If an application > > asks for more than can be displayed in the minibuffer window, that > > application has a bug. > > In that case, most uses of icomplete-vertical and any similar features > "have bugs". There's no chance in the world you can display all the > files in a non-trivial directory vertically in a mini-window without > losing some of the file names and/or some of the prompt. One can display it in other window and where line is too long, user can use keys like arrows right/left to go to side depending of the language, to see the remaining of the line. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 15:57 ` Eli Zaretskii 2020-11-11 16:16 ` Jean Louis @ 2020-11-11 17:06 ` martin rudalics 2020-11-11 17:28 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: martin rudalics @ 2020-11-11 17:06 UTC (permalink / raw To: Eli Zaretskii; +Cc: ghe, spacibba, monnier, andreyk.mad, emacs-devel > In that case, most uses of icomplete-vertical and any similar features > "have bugs". There's no chance in the world you can display all the > files in a non-trivial directory vertically in a mini-window without > losing some of the file names and/or some of the prompt. Right. I exclusively use systems where I can always see the entire prompt which might ask me something like "Delete 27 files?" and additionally allows me to see the names of these files via some extra scrolling mechanism. Provided there's not enough space to see the entire prompt and the names of all these files in a popped-up window. In either case, the entire prompt must be visible. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:06 ` martin rudalics @ 2020-11-11 17:28 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:28 UTC (permalink / raw To: martin rudalics Cc: Eli Zaretskii, spacibba, monnier, andreyk.mad, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1185 bytes --] Eli Zaretskii: >> In that case, most uses of icomplete-vertical and any similar features >> "have bugs". There's no chance in the world you can display all the >> files in a non-trivial directory vertically in a mini-window without >> losing some of the file names and/or some of the prompt. Luckily, there's a chance that you can display the entire prompt! (*) martin rudalics: > Right. I exclusively use systems where I can always see the entire > prompt which might ask me something like "Delete 27 files?" and > additionally allows me to see the names of these files via some extra > scrolling mechanism. Provided there's not enough space to see the > entire prompt and the names of all these files in a popped-up window. In > either case, the entire prompt must be visible. I fully agree with you that "the entire prompt must always be visible". Icomplete does this, with the attached code. The entire prompt is always visible (*), and you can scroll the completion candidates with C-. and C-,. (*) Except of course in pathological cases, for example with (setq max-mini-window-height 1) and (set-frame-width nil 10). But in these cases nothing can be done. [-- Attachment #2: Type: text/plain, Size: 1141 bytes --] (defvar-local start-display-at-beginning-of-minibuffer nil) (defun start-display-at-beginning-of-minibuffer (&rest args) (when (and start-display-at-beginning-of-minibuffer (minibufferp)) (set-window-start-at-begin (point-min) (point)))) (defun set-window-start-at-begin (beg end) (when (< (+ beg 2) end) (set-window-start nil beg) (unless (pos-visible-in-window-p end nil t) (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end)))) (add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibuffer) (add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer) (setq icomplete-separator "\n") (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t))) (defun icomplete-vertical-reformat-completions (completions) (save-match-data (if (string-match "^\\((.*)\\|\\[.*\\]\\)?{\\(\\(?:.\\|\n\\)+\\)}" completions) (format "%s \n%s" (or (match-string 1 completions) "") (match-string 2 completions)) completions))) (advice-add 'icomplete-completions :filter-return #'icomplete-vertical-reformat-completions) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 15:49 ` martin rudalics 2020-11-11 15:57 ` Eli Zaretskii @ 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:06 ` martin rudalics 2020-11-11 17:26 ` Stefan Monnier 1 sibling, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 16:05 UTC (permalink / raw To: martin rudalics Cc: Eli Zaretskii, monnier, spacibba, Andrii Kolomoiets, emacs-devel >> The exceptions are however orthogonal to the request to give >> applications the control on how the contents of the minibuffer should >> preferably be displayed: should it preferably start at the beginning of >> buffer (point-min), or should it preferably start at the beginning of >> the line on which the cursor is? ATM the latter behavior is the only >> possibility (except with the code I sent to Andrii yesterday). > > The application has to make sure that when it asks for user input, the > entire prompt can be seen in the minibuffer window without truncating > lines. > Again I agree with you. Hence the request to have a way for the application to tell to Emacs: "please display the entire prompt (unless it's impossible to do so)". The code I sent to Andrii does does exactly that. > > Emacs has to provide some reasonable minimum space for the minibuffer > window - usually one canonical frame line. If an application asks for > more than can be displayed in the minibuffer window, that application > has a bug. > Alas, it is practically impossible to create a text that you can be sure will fit / be displayed entirely in the minibuffer window. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:06 ` martin rudalics 2020-11-11 17:26 ` Stefan Monnier 1 sibling, 0 replies; 115+ messages in thread From: martin rudalics @ 2020-11-11 17:06 UTC (permalink / raw To: Gregory Heytings Cc: Eli Zaretskii, emacs-devel, monnier, Andrii Kolomoiets, spacibba > Alas, it is practically impossible to create a text that you can be > sure will fit / be displayed entirely in the minibuffer window. Yet it has to be done. For a default-minibuffer-based solution (1) get the available size via 'max-mini-window-height' and 'window-sizable' for the root window, (2) calculate the prompt size (if it does not fit, shorten it), (3) distribute the remaining height among the most suitable completion candidates or whatever else you want to show. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:06 ` martin rudalics @ 2020-11-11 17:26 ` Stefan Monnier 2020-11-11 17:37 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: Stefan Monnier @ 2020-11-11 17:26 UTC (permalink / raw To: Gregory Heytings Cc: martin rudalics, Eli Zaretskii, spacibba, Andrii Kolomoiets, emacs-devel > Alas, it is practically impossible to create a text that you can be sure > will fit / be displayed entirely in the minibuffer window. I think the core of the argument is that the prompt should fit on a single line. The problematic cases with icomplete-vertical only occur when the prompt itself spans multiple lines, but a prompt that spans multiple lines is already a problem, regardless of icomplete-mode, because there are setups where the minibuffer is only made of one line and is not allowed to grow. That's the reason why "poor redisplay when prompt > 1 line" is a low-priority problem: the better solution is to shorten the prompt. Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:26 ` Stefan Monnier @ 2020-11-11 17:37 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:37 UTC (permalink / raw To: Stefan Monnier Cc: martin rudalics, Eli Zaretskii, spacibba, Andrii Kolomoiets, emacs-devel >> Alas, it is practically impossible to create a text that you can be >> sure will fit / be displayed entirely in the minibuffer window. > > I think the core of the argument is that the prompt should fit on a > single line. The problematic cases with icomplete-vertical only occur > when the prompt itself spans multiple lines, but a prompt that spans > multiple lines is already a problem, regardless of icomplete-mode, > because there are setups where the minibuffer is only made of one line > and is not allowed to grow. > > That's the reason why "poor redisplay when prompt > 1 line" is a > low-priority problem: the better solution is to shorten the prompt. > Hmmm... no, the problematic cases also occur for example when the prompt and the initial input span multiple lines. I'll send the recipe one more time: (let (w bd) (setq w 60) (setq bd (concat (temporary-file-directory) (make-string w ?a) "/")) (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t)) (setq default-directory bd) (set-frame-height nil 20) (set-frame-width nil (+ (length bd) 10)) (icomplete-mode) (setq icomplete-separator "\n") (call-interactively 'insert-file)) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. 2020-11-11 10:53 ` martin rudalics @ 2020-11-11 15:32 ` Jean Louis 1 sibling, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 15:32 UTC (permalink / raw To: Gregory Heytings Cc: spacibba, Andrii Kolomoiets, emacs-devel, martin rudalics, monnier, Eli Zaretskii * Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-11 13:32]: > > > > > Applications have to accept that users want their minibuffer > > > > windows to show just one line. Or at most two lines. Or three > > > > ... > > > > > > Also users: "Show us completions vertically" and (setq > > > <icomplete/ido/etc>-separator "\n") > > > > Users shouldn't want the cake and eat it too. Any application should > > take care of such users. > > > > Of course, nobody is asking to display completion candidates vertically by > default. I prefer having completion candidates vertically for reason that vertical line has longer length, thus I can read the completion better. Text on screen is vertically arranged, I expect textual buffers such as minibuffers, if they are expanding to show me vertical arrangement. In fact I felt surprised and confused when I discovered ido completing horizontally. The default `completing-read' in Emacs, when explicitly requested by user by using TAB key is not horizontally shown but vertically. Default also does not move mode line up and down but opens split window. I can even move into the split window and do what I want to find the match. In fact in every description of a function that changes default one shall describe that new feature to warn the user. Description for icomplete-mode should say that it offers horizontal completion as that is substantial difference to the built-in completing-read. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:01 ` martin rudalics 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 15:26 ` Jean Louis 2020-11-11 16:06 ` Eli Zaretskii 2 siblings, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 15:26 UTC (permalink / raw To: martin rudalics Cc: Eli Zaretskii, monnier, spacibba, Andrii Kolomoiets, emacs-devel * martin rudalics <rudalics@gmx.at> [2020-11-11 13:03]: > >> Applications have to accept that users want their minibuffer windows to > >> show just one line. Or at most two lines. Or three ... > > > > Also users: "Show us completions vertically" and > > (setq <icomplete/ido/etc>-separator "\n") > > Users shouldn't want the cake and eat it too. Any application should > take care of such users. If an application has a truly expandable > minibuffer window or a normal window at its hands, it can try to show > completions vertically. With the default minibuffer window, it should > always behave as if only one line were available. Personally, it is bad idea to expand minibuffer. I could agree maybe to 2 lines, not even to three. I prefer having possibility to expand completion into full screen and to expand into split-window so that mode line remains where it is. When I was asking here before some months how to write a function to replace `read-from-minibuffer' into `read-from-buffer' I have got some tips and I think Eli and others helped that Emacs does not break the excursion. Then I made it possible for strings larger than length X to expand editing into full window. When there is string to be entered larger than what minibuffer should accommodate in relation to legibility and disturbance of user interface (mode line going up with longer strings), then the full window opens and I can receive the string from window or full buffer. There are various components of user interface, mini buffer is "informational component" and users expect to get information on familiar place. Common user interface shall remain as such. Only exceptionally and by user's CHOICE should minibuffer open up. Not by default. Personally I like how helm does it, it opens split window usually and mode line remains where it is, while I can use mini buffer to narrow the collection and find the matches. I have not given any command to helm to have my mode line jump up and down. The built-in completing-read does not automatically let the mode line jump up. I can complete with by using few words and TAB. If there is no completion TAB will expand the mini buffer. In this case I have explicitly decided to see the collection. Deciding for user to expand mini buffer is bad idea. To understand my feelings you would need to manage database by using completion frameworks, with 100+ tables where some of them have hundreds of thousands of records. If we already get split-screen, at least mode line shall remain where it is. What about the case of using minibuffer within minibuffer? I hope that has been taken in account with icomplete. Hide Enable Recursive Minibuffers: Toggle on (non-nil) State : SET for current session only. Non-nil means to allow minibuffer commands while in the minibuffer. More TAB is meant for line completion. For narrowing match completion there are words and choice, up and down or forward and back. Maybe some lists of how to design user interfaces could help: https://www.usability.gov/what-and-why/user-interface-design.html What applies: Quotes: " Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging. Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly. It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site." "Think about the defaults. By carefully thinking about and anticipating the goals people bring to your site, you can create defaults that reduce the burden on the user. This becomes particularly important when it comes to form design where you might have an opportunity to have some fields pre-chosen or filled out." ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 10:01 ` martin rudalics 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:26 ` Jean Louis @ 2020-11-11 16:06 ` Eli Zaretskii 2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions. 2 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 16:06 UTC (permalink / raw To: martin rudalics; +Cc: spacibba, monnier, andreyk.mad, emacs-devel > Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Wed, 11 Nov 2020 11:01:43 +0100 > > >> Applications have to accept that users want their minibuffer windows to > >> show just one line. Or at most two lines. Or three ... > > > > Also users: "Show us completions vertically" and > > (setq <icomplete/ido/etc>-separator "\n") > > Users shouldn't want the cake and eat it too. Any application should > take care of such users. If an application has a truly expandable > minibuffer window or a normal window at its hands, it can try to show > completions vertically. With the default minibuffer window, it should > always behave as if only one line were available. I'd say this much more bluntly: Emacs's minibuffer input was not designed for showing too many completion candidates, let alone show them vertically arranged. It was even less designed to display the candidates or other hints in overlays. Users come from other GUI applications, and expect a very different way of showing completion candidates than Emacs traditionally does. they want a UI which is akin to a combo box, sometimes even with scroll capability. If we want to support such UI, we should support it properly: by dropping down or popping up such a combo-like list. It is IMO wrong to do this the way icomplete-vertical and other similar packages try doing it, because the result will never look as pretty and professional as those other GUI applications offer. IOW, we should add new infrastructure into Emacs for supporting these features, perhaps by reusing some existing toolkit widgets. Playing tricks with display based on overlays with embedded newlines is not TRT, it's a dead end -- there are many things you simply will be unable to do reliably that way, and the results will not be pretty anyway. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 16:06 ` Eli Zaretskii @ 2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:19 ` Alfred M. Szmidt 2020-11-11 18:09 ` Eli Zaretskii 0 siblings, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:12 UTC (permalink / raw To: Eli Zaretskii Cc: martin rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > I'd say this much more bluntly: Emacs's minibuffer input was not > designed for showing too many completion candidates, let alone show them > vertically arranged. It was even less designed to display the > candidates or other hints in overlays. > Well, Emacs wasn't designed to manage emails or browse the web either ;-) Both are several orders of magnitude more complex than displaying completion candidates. > > Users come from other GUI applications, and expect a very different way > of showing completion candidates than Emacs traditionally does. they > want a UI which is akin to a combo box, sometimes even with scroll > capability. > Did you try Ivy? I don't use it, but it seems to me that it comes close to what you describe. If Ivy can do it, there is no reason that icomplete or ido couldn't do it. And, FWIW, I'm a user, and I do not expect a "very different way of showing completion candidates". That being said, I'm perhaps not a typical user; I don't know. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:19 ` Alfred M. Szmidt 2020-11-11 17:44 ` Gregory Heytings via Emacs development discussions. 2020-11-11 18:09 ` Eli Zaretskii 1 sibling, 1 reply; 115+ messages in thread From: Alfred M. Szmidt @ 2020-11-11 17:19 UTC (permalink / raw To: Gregory Heytings Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, eliz > I'd say this much more bluntly: Emacs's minibuffer input was not > designed for showing too many completion candidates, let alone show them > vertically arranged. It was even less designed to display the > candidates or other hints in overlays. Well, Emacs wasn't designed to manage emails or browse the web either ;-) That isn't really the case, Emacs has been able to manage email since it was a bunch of editor macros for TECO and it has always been one of the usages for Emacs other than writing code. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:19 ` Alfred M. Szmidt @ 2020-11-11 17:44 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:50 ` Alfred M. Szmidt 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:44 UTC (permalink / raw To: Alfred M. Szmidt Cc: eliz, rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > > I'd say this much more bluntly: Emacs's minibuffer input was not > > > designed for showing too many completion candidates, let alone show > > > them vertically arranged. It was even less designed to display the > > > candidates or other hints in overlays. > > > > Well, Emacs wasn't designed to manage emails or browse the web either > > ;-) > > That isn't really the case, Emacs has been able to manage email since it > was a bunch of editor macros for TECO and it has always been one of the > usages for Emacs other than writing code. > Thank you, this I didn't know. That being said, I'd guess that "manage email" in those days meant something completely different (much, much simpler) from what Gnus for example does these days... ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:44 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 17:50 ` Alfred M. Szmidt 2020-11-11 18:14 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Alfred M. Szmidt @ 2020-11-11 17:50 UTC (permalink / raw To: Gregory Heytings Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, eliz Thank you, this I didn't know. That being said, I'd guess that "manage email" in those days meant something completely different (much, much simpler) from what Gnus for example does these days... Not everyone uses gnus, some of us use rmail, which dates back to before Emacs (and if you used ITS RMAIL it would be familiar). Maybe simpler is better... ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:50 ` Alfred M. Szmidt @ 2020-11-11 18:14 ` Eli Zaretskii 0 siblings, 0 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 18:14 UTC (permalink / raw To: Alfred M. Szmidt Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, ghe > From: "Alfred M. Szmidt" <ams@gnu.org> > Cc: eliz@gnu.org, rudalics@gmx.at, spacibba@aol.com, > monnier@iro.umontreal.ca, andreyk.mad@gmail.com, > emacs-devel@gnu.org > Date: Wed, 11 Nov 2020 12:50:58 -0500 > > Not everyone uses gnus, some of us use rmail, which dates back to > before Emacs (and if you used ITS RMAIL it would be familiar). Maybe > simpler is better... The display aspects are not very different these days, AFAIK. Rmail can display HTML and images, and supports attachments. Features that aren't related to display (and where Gnus is much more powerful) are irrelevant in the context of this discussion. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:19 ` Alfred M. Szmidt @ 2020-11-11 18:09 ` Eli Zaretskii 2020-11-11 18:39 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 18:09 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Wed, 11 Nov 2020 17:12:21 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: martin rudalics <rudalics@gmx.at>, spacibba@aol.com, > monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org > > > I'd say this much more bluntly: Emacs's minibuffer input was not > > designed for showing too many completion candidates, let alone show them > > vertically arranged. It was even less designed to display the > > candidates or other hints in overlays. > > Well, Emacs wasn't designed to manage emails or browse the web either ;-) Yes, it was. Those applications basically display text with a few images, something that Emacs 21 was definitely designed to support. Don't misunderstand me: Emacs _can_ display what icomplete-vertical and similar features ask it, it just cannot do that well, and the results are not pretty. If you read the code that is involved, the reasons are acutely evident, and it is important for me to make these conclusions public and known to all, because many people believe there's no limit to what one can do with Emacs display features. Well, there is. > Did you try Ivy? Yes. > And, FWIW, I'm a user, and I do not expect a "very different way of > showing completion candidates". Neither am I. icomplete-vertical and friends weren't written for the likes of us. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 18:09 ` Eli Zaretskii @ 2020-11-11 18:39 ` Gregory Heytings via Emacs development discussions. 2020-11-11 20:21 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 18:39 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel >>> I'd say this much more bluntly: Emacs's minibuffer input was not >>> designed for showing too many completion candidates, let alone show >>> them vertically arranged. It was even less designed to display the >>> candidates or other hints in overlays. >> >> Well, Emacs wasn't designed to manage emails or browse the web either >> ;-) > > Yes, it was. Those applications basically display text with a few > images, something that Emacs 21 was definitely designed to support. > > Don't misunderstand me: Emacs _can_ display what icomplete-vertical and > similar features ask it, it just cannot do that well, and the results > are not pretty. > I honestly don't understand why you consider that vertical icomplete is "not pretty", even more so as you seem to consider at the same time that Emacs' handling of emails and web pages is okay. IMO, Emacs' rendering of HTML in emails and on web pages is definitely not pretty. IMO again, displaying completion candidates in the minibuffer is pretty enough, at least I don't see why it would be fundamentally less pretty for a newcomer than, say, the completion candidates displayed by Chromium or Visual Studio. > > If you read the code that is involved, the reasons are acutely evident, > and it is important for me to make these conclusions public and known to > all, because many people believe there's no limit to what one can do > with Emacs display features. Well, there is. > There are limits, of course, but the feature that is requested is well within the limits of what Emacs can do. And AFAIU implementing a proper vertical icomplete/ido with a few more features similar to those of Ivy is also within the limits of what Emacs can do. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 18:39 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 20:21 ` Eli Zaretskii 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. 2020-11-12 7:58 ` martin rudalics 0 siblings, 2 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 20:21 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Wed, 11 Nov 2020 18:39:41 +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 honestly don't understand why you consider that vertical icomplete is > "not pretty", even more so as you seem to consider at the same time that > Emacs' handling of emails and web pages is okay. IMO, Emacs' rendering of > HTML in emails and on web pages is definitely not pretty. IMO again, > displaying completion candidates in the minibuffer is pretty enough, at > least I don't see why it would be fundamentally less pretty for a newcomer > than, say, the completion candidates displayed by Chromium or Visual > Studio. If someone wants to claim that display of completion candidates by icomplete-vertical, ivy, etc. is anywhere near as pretty as what you get when you click on the address bar of a browser and get the drop-down list of candidates, then I can only say that I cannot disagree more. > > If you read the code that is involved, the reasons are acutely evident, > > and it is important for me to make these conclusions public and known to > > all, because many people believe there's no limit to what one can do > > with Emacs display features. Well, there is. > > There are limits, of course, but the feature that is requested is well > within the limits of what Emacs can do. And AFAIU implementing a proper > vertical icomplete/ido with a few more features similar to those of Ivy is > also within the limits of what Emacs can do. I explicitly said that Emacs _can_ do that. My point was entirely different. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 20:21 ` Eli Zaretskii @ 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. 2020-11-11 21:55 ` Ergus 2020-11-12 3:28 ` Eli Zaretskii 2020-11-12 7:58 ` martin rudalics 1 sibling, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-11 20:37 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > If someone wants to claim that display of completion candidates by > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you get > when you click on the address bar of a browser and get the drop-down > list of candidates, then I can only say that I cannot disagree more. > But why??? I just tried Ivy again, AFAICS it has everything you have in the drop-down list of a browser: the matching substring is colorized, you can use the mouse to click on a candidate to select it, you can use the mouse to scroll the list up and down... What am I missing? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. @ 2020-11-11 21:55 ` Ergus 2020-11-11 22:26 ` Jean Louis 2020-11-11 22:59 ` Stefan Monnier 2020-11-12 3:28 ` Eli Zaretskii 1 sibling, 2 replies; 115+ messages in thread From: Ergus @ 2020-11-11 21:55 UTC (permalink / raw To: Gregory Heytings Cc: Eli Zaretskii, rudalics, monnier, andreyk.mad, emacs-devel On Wed, Nov 11, 2020 at 08:37:36PM +0000, Gregory Heytings wrote: > >> >>If someone wants to claim that display of completion candidates by >>icomplete-vertical, ivy, etc. is anywhere near as pretty as what you >>get when you click on the address bar of a browser and get the >>drop-down list of candidates, then I can only say that I cannot >>disagree more. >> > >But why??? I just tried Ivy again, AFAICS it has everything you have >in the drop-down list of a browser: the matching substring is >colorized, you can use the mouse to click on a candidate to select it, >you can use the mouse to scroll the list up and down... What am I >missing? Indeed, I don't see any important visual "disadvantage" in ivy appearance compared with what is around. Plus ivy adds some exclusive features like the M-o actions, avy integration (avy was created the same author) and hydra integration (also from same author). IMO (I already said that) we should put more attention to ivy if we want a better/pretty completion already working. Ivy solves details like the scrolling, long prompt, long like candidates and so on... There is also an extension for ivy: ivy-postframe [1] which shows the completions in a postframe (of course). And the appearance is (IMO) as good as anything else around. [1]: https://github.com/tumashu/ivy-posframe BTW: The postframe creator asked in this list some days ago about adding the package to elpa . All the contributors got the copyright already; but I don't know if he received any reply to proceed. You can see the thread: https://github.com/tumashu/ivy-posframe/issues/95 ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 21:55 ` Ergus @ 2020-11-11 22:26 ` Jean Louis 2020-11-11 22:59 ` Stefan Monnier 1 sibling, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 22:26 UTC (permalink / raw To: Ergus Cc: andreyk.mad, emacs-devel, rudalics, monnier, Gregory Heytings, Eli Zaretskii * Ergus <spacibba@aol.com> [2020-11-12 00:58]: > On Wed, Nov 11, 2020 at 08:37:36PM +0000, Gregory Heytings wrote: > > > > > > > > If someone wants to claim that display of completion candidates by > > > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you > > > get when you click on the address bar of a browser and get the > > > drop-down list of candidates, then I can only say that I cannot > > > disagree more. > > > > > > > But why??? I just tried Ivy again, AFAICS it has everything you have in > > the drop-down list of a browser: the matching substring is colorized, > > you can use the mouse to click on a candidate to select it, you can use > > the mouse to scroll the list up and down... What am I missing? > > Indeed, I don't see any important visual "disadvantage" in ivy > appearance compared with what is around. Plus ivy adds some exclusive > features like the M-o actions, avy integration (avy was created the same > author) and hydra integration (also from same author). IMO (I already > said that) we should put more attention to ivy if we want a > better/pretty completion already working. Ivy solves details like the > scrolling, long prompt, long like candidates and so on... Exactly. Ivy is for me so much more useful than icomplete/ido/fido And by adding this function from Ivy friend, it can be added to ivy-display-functions-alist Its value is ((counsel-irony . ivy-display-function-overlay) (describe-function . ivy-display-function-window) (ivy-completion-in-region . ivy-display-function-overlay) (t . ivy-display-function-window)) Original value was ((ivy-completion-in-region . ivy-display-function-overlay) (t)) Then the mode line stays down where it should be and split window appears with collection. I am including this hear as maybe icomplete developers wish to implement similar. (defun ivy-display-function-window (text) (let ((buffer (get-buffer-create "*ivy-candidate-window*")) (str (with-current-buffer (get-buffer-create " *Minibuf-1*") (let ((point (point)) (string (concat (buffer-string) " " text))) (add-face-text-property (- point 1) point 'ivy-cursor t string) string)))) (with-current-buffer buffer (let ((inhibit-read-only t)) (erase-buffer) (insert str))) (with-ivy-window (display-buffer buffer `((display-buffer-reuse-window display-buffer-below-selected) (window-height . ,(1+ (ivy--height (ivy-state-caller ivy-last))))))))) ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 21:55 ` Ergus 2020-11-11 22:26 ` Jean Louis @ 2020-11-11 22:59 ` Stefan Monnier 1 sibling, 0 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-11 22:59 UTC (permalink / raw To: Ergus; +Cc: Gregory Heytings, rudalics, Eli Zaretskii, andreyk.mad, emacs-devel > BTW: The postframe creator asked in this list some days ago about adding > the package to elpa . All the contributors got the copyright already; but > I don't know if he received any reply to proceed. https://elpa.gnu.org/packages/ivy-posframe.html Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. 2020-11-11 21:55 ` Ergus @ 2020-11-12 3:28 ` Eli Zaretskii 2020-11-12 8:50 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-12 3:28 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Wed, 11 Nov 2020 20:37:36 +0000 > cc: rudalics@gmx.at, spacibba@aol.com, monnier@iro.umontreal.ca, > andreyk.mad@gmail.com, emacs-devel@gnu.org > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > If someone wants to claim that display of completion candidates by > > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you get > > when you click on the address bar of a browser and get the drop-down > > list of candidates, then I can only say that I cannot disagree more. > > But why??? I just tried Ivy again, AFAICS it has everything you have in > the drop-down list of a browser: the matching substring is colorized, you > can use the mouse to click on a candidate to select it, you can use the > mouse to scroll the list up and down... What am I missing? The looks, the looks... ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 3:28 ` Eli Zaretskii @ 2020-11-12 8:50 ` Gregory Heytings via Emacs development discussions. 2020-11-12 14:36 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-12 8:50 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel >>> If someone wants to claim that display of completion candidates by >>> icomplete-vertical, ivy, etc. is anywhere near as pretty as what you >>> get when you click on the address bar of a browser and get the >>> drop-down list of candidates, then I can only say that I cannot >>> disagree more. >> >> But why??? I just tried Ivy again, AFAICS it has everything you have >> in the drop-down list of a browser: the matching substring is >> colorized, you can use the mouse to click on a candidate to select it, >> you can use the mouse to scroll the list up and down... What am I >> missing? > > The looks, the looks... > This is very subjective. I find the looks of the minibuffer with vertical completions very nice, and given the popularity of packages that implement that feature (Helm and Ivy) I'm sure I'm not alone. And, FWIW, I would very much dislike a "combo box like UI" to replace this. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 8:50 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 14:36 ` Eli Zaretskii 2020-11-12 15:05 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-12 14:36 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Thu, 12 Nov 2020 08:50:34 +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 > > >>> If someone wants to claim that display of completion candidates by > >>> icomplete-vertical, ivy, etc. is anywhere near as pretty as what you > >>> get when you click on the address bar of a browser and get the > >>> drop-down list of candidates, then I can only say that I cannot > >>> disagree more. > >> > >> But why??? I just tried Ivy again, AFAICS it has everything you have > >> in the drop-down list of a browser: the matching substring is > >> colorized, you can use the mouse to click on a candidate to select it, > >> you can use the mouse to scroll the list up and down... What am I > >> missing? > > > > The looks, the looks... > > > > This is very subjective. Of course, it is! Which is why I'm not going to argue, I'm just surprised that this needs to be explained. Do you also disagree that those Emacs packages strive to emulate the drop-down combo UI? > And, FWIW, I would very much dislike a "combo box like UI" to > replace this. When you do need to use the Web browsers that implement that UI, do you frequently regret they don't work like Ivy? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 14:36 ` Eli Zaretskii @ 2020-11-12 15:05 ` Gregory Heytings via Emacs development discussions. 2020-11-12 15:36 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-12 15:05 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1586 bytes --] > > Do you also disagree that those Emacs packages strive to emulate the > drop-down combo UI? > I don't know. What I can tell is that when I wrote my vertical icomplete, I did not think a single second about drop-down combo UI's. I just thought something like "I can't read these completion candidates presented horizontally, my eye has to move too much, I want them to be displayed right under the cursor." (And yes, this "be displayed under the cursor" is not a standard feature of those packages.) >> And, FWIW, I would very much dislike a "combo box like UI" to replace >> this. > > 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. I understood earlier that you find that browsers implement this in a prettier way, but now you seem to think that it works "better" in browsers. But I don't know what is "better". >>> Wholeheartedly agreed. In particular with all that blank space at the >>> right side of the minibuffer window. >> >> I don't know what browser you use, but with both Chromium and Firefox >> you also have "all that blank space at the right side" of the drop-down >> list of candidates. > > 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%. [-- Attachment #2: Type: image/png, Size: 54040 bytes --] ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 15:05 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 15:36 ` Eli Zaretskii 2020-11-12 16:10 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-12 15:36 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Thu, 12 Nov 2020 15:05:06 +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 > > > 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? > > 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 or the small Google Search window to the right of the address bar. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 15:36 ` Eli Zaretskii @ 2020-11-12 16:10 ` Gregory Heytings via Emacs development discussions. 2020-11-12 17:50 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-12 16:10 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1640 bytes --] >>> 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. [-- Attachment #2: Type: image/png, Size: 189235 bytes --] ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 16:10 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 17:50 ` Eli Zaretskii 2020-11-13 12:40 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-12 17:50 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > 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. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 17:50 ` Eli Zaretskii @ 2020-11-13 12:40 ` Gregory Heytings via Emacs development discussions. 2020-11-13 12:59 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-13 12:40 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > 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. And I showed, with numbers, that with the default configuration of the browser used by the vast majority (66%) of the world population, the combo box of the address bar is larger than the largest possible Emacs minibuffer (again with the default configuration). I think you underestimate the fact that the UI expectations of most people today have been heavily influenced by smartphones (or "portable listening and surveillance device" as RMS would call them ;-) and tablets. On a smartphone the combo box when you type something in the address bar (and generally in most apps) typically uses 100% of the available screen space, on a tablet it's typically 50-60%. In the same vein, most people today prefer to use full-screen apps, and what you consider to be "wasted screen space" is not at all a problem for them. > > 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? IMO you're overestimating the importance of this, and IMO it is not at all counter-intuitive. There are many ways to display such things, for example the system search bar in macOS is positioned at the center of the screen with completion candidates displayed below, but in Windows it is positioned at the bottom of the screen with completion candidates displayed above. All apps are different, and I don't see why the fact that Emacs doesn't behave like another app (BTW, which one should be the reference?) would make it counter-intuitive. > > 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? That's not true, the Windows start menu is bottom-up, and I've never seen this as a problem. I've never heard anyone complaining about it either. And the current trend seems to be menus that work left-right (with the menu title replaced by an icon). > > 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? >>> or the small Google Search window to the right of the address bar. >> >> 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. > That might have been the case some years ago, but browsers are now clever enough to make a distinction between URLs and queries. I can't tell what happens on your computer, but on mine typing "foo" in the search box and in the address bar lists the exact same completion candidates. Which is why the search box isn't there in the default configuration, and why I did not add it. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 12:40 ` Gregory Heytings via Emacs development discussions. @ 2020-11-13 12:59 ` Eli Zaretskii 2020-11-13 13:36 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 12:59 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Fri, 13 Nov 2020 12:40:13 +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 > > > 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. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 12:59 ` Eli Zaretskii @ 2020-11-13 13:36 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:52 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-13 13:36 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > 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. > I fear I'll repeat myself, but I don't understand why you think that displaying completions vertically is trying to emulate the combo-like vertical list widget. For me it's doing something similar (but not identical) in a different (and more efficient) way. > > No, it's the fact that we use a window that displays a buffer, and not a > vertical list widget. > I believe it is clear for you, but FWIW, I wouln't use such a vertical list widget. The way I want to interact with Emacs in the minibuffer is much closer to a command shell than to a GUI app. Perhaps it would make sense to make a poll to see what GUI widgets Emacs users would want to have, or whether Emacs users would want such a widget in this case. > > 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, while opening a file or switching from a buffer to another or calling an Emacs command with the minibuffer is meant to be done with the keyboard. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:36 ` Gregory Heytings via Emacs development discussions. @ 2020-11-13 13:52 ` Eli Zaretskii 2020-11-13 15:09 ` Stephen Berman 2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions. 0 siblings, 2 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 13:52 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Fri, 13 Nov 2020 13:36:41 +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 > > > 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. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:52 ` Eli Zaretskii @ 2020-11-13 15:09 ` Stephen Berman 2020-11-13 16:05 ` Eli Zaretskii 2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: Stephen Berman @ 2020-11-13 15:09 UTC (permalink / raw To: Eli Zaretskii Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, Gregory Heytings On Fri, 13 Nov 2020 15:52:29 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Fri, 13 Nov 2020 13:36:41 +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 >> >> > 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 I frequently use the keyboard to open, navigate and select items from menues in GTK builds of Emacs, but in my no-toolkit build, I can pop open the global menu with F10 but it responds to no further keyboard action, only to the mouse (this is under GNU/Linux). Is this a known limitation of no-toolkit menues? Steve Berman ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 15:09 ` Stephen Berman @ 2020-11-13 16:05 ` Eli Zaretskii 2020-11-13 17:31 ` Stephen Berman 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 16:05 UTC (permalink / raw To: Stephen Berman; +Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, ghe > From: Stephen Berman <stephen.berman@gmx.net> > Cc: Gregory Heytings <ghe@sdf.org>, rudalics@gmx.at, spacibba@aol.com, > monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org > Date: Fri, 13 Nov 2020 16:09:59 +0100 > > > Actually, menus (even GUI toolkit menus) work with the keyboard very > ^^^^^^^^^^^^^^^^^^^^^^ > > well. Including in Emacs. It's true that interaction with GUI > > I frequently use the keyboard to open, navigate and select items from > menues in GTK builds of Emacs, but in my no-toolkit build, I can pop > open the global menu with F10 but it responds to no further keyboard > action, only to the mouse (this is under GNU/Linux). Is this a known > limitation of no-toolkit menues? I think we just didn't implement keyboard movement in non-toolkit menus on X. Patches are welcome. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 16:05 ` Eli Zaretskii @ 2020-11-13 17:31 ` Stephen Berman 0 siblings, 0 replies; 115+ messages in thread From: Stephen Berman @ 2020-11-13 17:31 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, andreyk.mad, emacs-devel, rudalics, monnier, ghe On Fri, 13 Nov 2020 18:05:29 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Cc: Gregory Heytings <ghe@sdf.org>, rudalics@gmx.at, spacibba@aol.com, >> monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org >> Date: Fri, 13 Nov 2020 16:09:59 +0100 >> >> > Actually, menus (even GUI toolkit menus) work with the keyboard very >> ^^^^^^^^^^^^^^^^^^^^^^ >> > well. Including in Emacs. It's true that interaction with GUI >> >> I frequently use the keyboard to open, navigate and select items from >> menues in GTK builds of Emacs, but in my no-toolkit build, I can pop >> open the global menu with F10 but it responds to no further keyboard >> action, only to the mouse (this is under GNU/Linux). Is this a known >> limitation of no-toolkit menues? > > I think we just didn't implement keyboard movement in non-toolkit > menus on X. Patches are welcome. Ok, I'll be happy to join the welcoming committee ;-) Steve Berman ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:52 ` Eli Zaretskii 2020-11-13 15:09 ` Stephen Berman @ 2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions. 2020-11-16 17:44 ` Eli Zaretskii 1 sibling, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-16 10:24 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions. @ 2020-11-16 17:44 ` Eli Zaretskii 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-16 17:44 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Mon, 16 Nov 2020 10:24:21 +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 > > > 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. Since vertical lists and icomplete-type completion features present the same interaction interfaces, both keyboard- and mouse-related, I see no reason to distinguish between them in this context. I didn't say these features should be used. However, people do want to use them, whether we agree or not. When they do use such features, I maintain that the visual appearance should be pretty and professional, like what we see in GUI apps out there which use the vertical list widgets. I understand that you disagree, and that is fine. I just don't see why we should continue arguing long after we've established that there's a fundamental disagreement between us. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 17:44 ` Eli Zaretskii @ 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-17 11:51 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > > Since vertical lists and icomplete-type completion features present the > same interaction interfaces, both keyboard- and mouse-related, I see no > reason to distinguish between them in this context. > > I didn't say these features should be used. However, people do want to > use them, whether we agree or not. > I use them, both in regular buffers and in the minibuffer, so at least I speak with some experience. > > When they do use such features, I maintain that the visual appearance > should be pretty and professional, like what we see in GUI apps out > there which use the vertical list widgets. > I would make a distinction between two things: (1) vertical display of completion candidates inside regular buffers (what Company does) and (2) vertical display of completion candidates in the minibuffer. I agree that for (1) a GUI vertical list widget could make sense instead of the pseudo-tooltip that Company creates with an overlay. I would not use such a widget myself, as I like the minimalism of a terminal-like interface, but I understand that others could prefer a more modern UI, and could judge that a pseudo-tooltip is "unprofessional". I can't agree that for (2) a GUI vertical list widget would make sense, IMO it would be awkward to use a GUI widget there. If AFAIK none of the packages that implement vertical lists there create an rectangular overlay with a pseudo scroll bar (as Company does) to mimic a GUI vertical list widget, it's probably not without any reason. > > I understand that you disagree, and that is fine. I just don't see why > we should continue arguing long after we've established that there's a > fundamental disagreement between us. > Indeed, I agree to fundamentally disagree. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 20:21 ` Eli Zaretskii 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 7:58 ` martin rudalics 2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions. 2020-11-12 12:39 ` Dmitry Gutov 1 sibling, 2 replies; 115+ messages in thread From: martin rudalics @ 2020-11-12 7:58 UTC (permalink / raw To: Eli Zaretskii, Gregory Heytings Cc: spacibba, monnier, andreyk.mad, emacs-devel > If someone wants to claim that display of completion candidates by > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you > get when you click on the address bar of a browser and get the > drop-down list of candidates, then I can only say that I cannot > disagree more. Wholeheartedly agreed. In particular with all that blank space at the right side of the minibuffer window. Unfortunately, drop-down lists are inherently modal like menus. You cannot, for example, show a list of candidates and do some other things in between on the same frame before making your choice. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 7:58 ` martin rudalics @ 2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions. 2020-11-12 14:37 ` Eli Zaretskii 2020-11-12 12:39 ` Dmitry Gutov 1 sibling, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-12 8:52 UTC (permalink / raw To: martin rudalics Cc: Eli Zaretskii, spacibba, monnier, andreyk.mad, emacs-devel >> If someone wants to claim that display of completion candidates by >> icomplete-vertical, ivy, etc. is anywhere near as pretty as what you >> get when you click on the address bar of a browser and get the >> drop-down list of candidates, then I can only say that I cannot >> disagree more. > > Wholeheartedly agreed. In particular with all that blank space at the > right side of the minibuffer window. > I don't know what browser you use, but with both Chromium and Firefox you also have "all that blank space at the right side" of the drop-down list of candidates. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 14:37 ` Eli Zaretskii 0 siblings, 0 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-12 14:37 UTC (permalink / raw To: Gregory Heytings; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Thu, 12 Nov 2020 08:52:32 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, monnier@iro.umontreal.ca, > andreyk.mad@gmail.com, emacs-devel@gnu.org > > > Wholeheartedly agreed. In particular with all that blank space at the > > right side of the minibuffer window. > > I don't know what browser you use, but with both Chromium and Firefox you > also have "all that blank space at the right side" of the drop-down list > of candidates. No, those browsers never drop a list which is as wide as the window/frame. So they waste much less screen space. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 7:58 ` martin rudalics 2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions. @ 2020-11-12 12:39 ` Dmitry Gutov 2020-11-12 19:31 ` Howard Melman 1 sibling, 1 reply; 115+ messages in thread From: Dmitry Gutov @ 2020-11-12 12:39 UTC (permalink / raw To: martin rudalics, Eli Zaretskii, Gregory Heytings Cc: spacibba, monnier, andreyk.mad, emacs-devel On 12.11.2020 09:58, martin rudalics wrote: > > If someone wants to claim that display of completion candidates by > > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you > > get when you click on the address bar of a browser and get the > > drop-down list of candidates, then I can only say that I cannot > > disagree more. > > Wholeheartedly agreed. In particular with all that blank space at the > right side of the minibuffer window. Have either of you tried Ivy + ivy-rich + ivy-posframe? > Unfortunately, drop-down lists are > inherently modal like menus.You cannot, for example, show a list of > candidates and do some other things in between on the same frame before > making your choice. That's true of any browser as well. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 12:39 ` Dmitry Gutov @ 2020-11-12 19:31 ` Howard Melman 0 siblings, 0 replies; 115+ messages in thread From: Howard Melman @ 2020-11-12 19:31 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 812 bytes --] Dmitry Gutov <dgutov@yandex.ru> writes: > On 12.11.2020 09:58, martin rudalics wrote: >> > If someone wants to claim that display of completion candidates by >> > icomplete-vertical, ivy, etc. is anywhere near as pretty as what you >> > get when you click on the address bar of a browser and get the >> > drop-down list of candidates, then I can only say that I cannot >> > disagree more. >> Wholeheartedly agreed. In particular with all that blank space at the >> right side of the minibuffer window. > > Have either of you tried Ivy + ivy-rich + ivy-posframe? I've been using ivy happily for years and like it's UI better than ido, icomplete and helm, having tried them all. And I look forward to selectrum becoming more complete. ivy-rich is also great, particularly when you fill the right side [-- Attachment #2: Screen Shot 2020-11-12 at 2.19.33 PM.png --] [-- Type: image/png, Size: 172002 bytes --] [-- Attachment #3: Screen Shot 2020-11-12 at 2.19.54 PM.png --] [-- Type: image/png, Size: 133449 bytes --] [-- Attachment #4: Type: text/plain, Size: 14 bytes --] -- Howard ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 9:38 ` Andrii Kolomoiets 2020-11-11 10:01 ` martin rudalics @ 2020-11-11 14:09 ` Jean Louis 2020-11-11 15:51 ` Eli Zaretskii 1 sibling, 1 reply; 115+ messages in thread From: Jean Louis @ 2020-11-11 14:09 UTC (permalink / raw To: Andrii Kolomoiets Cc: martin rudalics, Eli Zaretskii, spacibba, monnier, emacs-devel * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-11 12:39]: > martin rudalics <rudalics@gmx.at> writes: > > >> And here I come to the answer to your question: for me, the bug here is > >> that the prompt is hidden in favor of the overlay text. > > > > Applications have to accept that users want their minibuffer windows to > > show just one line. Or at most two lines. Or three ... > > Also users: "Show us completions vertically" and > (setq <icomplete/ido/etc>-separator "\n") Jumping mode line is the side effect that completion packages do not take in account. From Emacs manual: 1.3 The Mode Line ================= At the bottom of each window is a “mode line”, which describes what is going on in the current buffer. This way we teach user that mode line is at the bottom of each window. We do not tell to user that mode line is to disappear from the bottom and that one may find it somewhere in the middle. Personally, frequent searches are disturbing. In my opinion completions should NOT by default have mode line jumping up and down and mini buffer shall remain where it is. Split window may show completion candidates or another frame, or overlay. If this default is not followed then each completion package should at least offer option for user to customize it so the mode line does not jump up and down and that minibuffer stays "mini". ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 14:09 ` Jean Louis @ 2020-11-11 15:51 ` Eli Zaretskii 2020-11-11 16:05 ` Jean Louis 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 15:51 UTC (permalink / raw To: Jean Louis; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel > Date: Wed, 11 Nov 2020 17:09:54 +0300 > From: Jean Louis <bugs@gnu.support> > Cc: martin rudalics <rudalics@gmx.at>, Eli Zaretskii <eliz@gnu.org>, > emacs-devel@gnu.org, spacibba@aol.com, monnier@iro.umontreal.ca > > Jumping mode line is the side effect that completion packages do not > take in account. If it annoys you so much, you can easily stop it from jumping. See the variable resize-mini-windows. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 15:51 ` Eli Zaretskii @ 2020-11-11 16:05 ` Jean Louis 0 siblings, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-11 16:05 UTC (permalink / raw To: Eli Zaretskii; +Cc: rudalics, spacibba, monnier, andreyk.mad, emacs-devel * Eli Zaretskii <eliz@gnu.org> [2020-11-11 18:52]: > > Jumping mode line is the side effect that completion packages do not > > take in account. > > If it annoys you so much, you can easily stop it from jumping. See > the variable resize-mini-windows. Thank you. I hoped it will automagically solve it. But it even blocks some completion packages of using it. Maybe packages do not look into that variable as authoritative. It could tame little icomplete. Not other packages for completion. ^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [PATCH] Support "\n" in icomplete-separator 2020-11-11 8:27 ` martin rudalics 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. 2020-11-11 9:38 ` Andrii Kolomoiets @ 2020-11-11 18:52 ` Drew Adams 2020-11-11 19:10 ` martin rudalics 2 siblings, 1 reply; 115+ messages in thread From: Drew Adams @ 2020-11-11 18:52 UTC (permalink / raw To: martin rudalics, Andrii Kolomoiets, Eli Zaretskii Cc: spacibba, monnier, emacs-devel > Applications have to accept that users want their minibuffer > windows to show just one line. Or at most two lines. Or three ... Huh? Why do you think that? Not sure what you mean by an application, but if the application is the thing that's presenting and reading the minibuffer then it's up to the application to decide how to present and use it, what to expect, and what to let users know about what to expect. There's no such rule/guideline, IMO, and none would be appropriate, to say that applications must accept that users (in general? always? all users? most?) want minibuffer windows to be of a certain shape/size, position, or whatever. ___ FWIW: My standalone minibuffer frame automatically fits itself to the minibuffer content, by default. And Icicles has commands that can provide large completion candidates, e.g., a complete sexp or a complete doc string. And some such have more than a few lines. And when you cycle among candidates the current candidate replaces the minibuffer content. So it's not so uncommon to have multiple-line content in the minibuffer. There's nothing wrong with allowing such behavior. I don't see why you're prescribing or supposing restrictions on the height of a minibuffer. That's up to libraries and the users who decide to use them. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 18:52 ` Drew Adams @ 2020-11-11 19:10 ` martin rudalics 2020-11-11 19:49 ` Drew Adams 2020-11-11 19:51 ` Drew Adams 0 siblings, 2 replies; 115+ messages in thread From: martin rudalics @ 2020-11-11 19:10 UTC (permalink / raw To: Drew Adams, Andrii Kolomoiets, Eli Zaretskii Cc: spacibba, monnier, emacs-devel > Not sure what you mean by an application, but if the > application is the thing that's presenting and reading > the minibuffer then it's up to the application to > decide how to present and use it, what to expect, and > what to let users know about what to expect. > > There's no such rule/guideline, IMO, and none would > be appropriate, to say that applications must accept > that users (in general? always? all users? most?) > want minibuffer windows to be of a certain shape/size, > position, or whatever. Users decide how large their frames are, how many windows they contain and what the values of 'resize-mini-windows' and 'max-mini-window-height' are. Applications that do not obey these restrictions are wrong. > My standalone minibuffer frame automatically fits > itself to the minibuffer content, by default. > > And Icicles has commands that can provide large > completion candidates, e.g., a complete sexp or a > complete doc string. And some such have more than a > few lines. And when you cycle among candidates the > current candidate replaces the minibuffer content. > > So it's not so uncommon to have multiple-line > content in the minibuffer. There's nothing wrong > with allowing such behavior. I don't see why you're > prescribing or supposing restrictions on the height > of a minibuffer. That's up to libraries and the > users who decide to use them. Standalone minibuffer frames are not subject to the restrictions cited above. Their size is constrained only by that of the display screen. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [PATCH] Support "\n" in icomplete-separator 2020-11-11 19:10 ` martin rudalics @ 2020-11-11 19:49 ` Drew Adams 2020-11-12 7:58 ` martin rudalics 2020-11-11 19:51 ` Drew Adams 1 sibling, 1 reply; 115+ messages in thread From: Drew Adams @ 2020-11-11 19:49 UTC (permalink / raw To: martin rudalics, Andrii Kolomoiets, Eli Zaretskii Cc: spacibba, monnier, emacs-devel > > Not sure what you mean by an application, but if the > > application is the thing that's presenting and reading > > the minibuffer then it's up to the application to > > decide how to present and use it, what to expect, and > > what to let users know about what to expect. > > > > There's no such rule/guideline, IMO, and none would > > be appropriate, to say that applications must accept > > that users (in general? always? all users? most?) > > want minibuffer windows to be of a certain shape/size, > > position, or whatever. > > Users decide how large their frames are, how many windows they contain > and what the values of 'resize-mini-windows' and > 'max-mini-window-height' are. Applications that do not obey these > restrictions are wrong. Sure, unless they tell users what the behavior is and users choose to use them, i.e., choose that behavior. An "application" can present choices to users just as much as a user option can. The function `customize-save-variable' is an "application" that a user can use to change, i.e., override an option setting. What makes it OK is that the command tells you what it does, and it's up to use whether you use it. > > My standalone minibuffer frame automatically fits > > itself to the minibuffer content, by default. > > > > And Icicles has commands that can provide large > > completion candidates, e.g., a complete sexp or a > > complete doc string. And some such have more than a > > few lines. And when you cycle among candidates the > > current candidate replaces the minibuffer content. > > > > So it's not so uncommon to have multiple-line > > content in the minibuffer. There's nothing wrong > > with allowing such behavior. I don't see why you're > > prescribing or supposing restrictions on the height > > of a minibuffer. That's up to libraries and the > > users who decide to use them. > > Standalone minibuffer frames are not subject to the restrictions cited > above. Their size is constrained only by that of the display screen. Good to hear. But why the restrictions for non-standalone? What I said about Icicles is independent of a standalone minibuffer frame. There are lots of situations under which minibuffer content can reasonably be more than a line or two. I don't see any good reason presented for such restrictions. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 19:49 ` Drew Adams @ 2020-11-12 7:58 ` martin rudalics 0 siblings, 0 replies; 115+ messages in thread From: martin rudalics @ 2020-11-12 7:58 UTC (permalink / raw To: Drew Adams, Andrii Kolomoiets, Eli Zaretskii Cc: spacibba, monnier, emacs-devel >> Users decide how large their frames are, how many windows they contain >> and what the values of 'resize-mini-windows' and >> 'max-mini-window-height' are. Applications that do not obey these >> restrictions are wrong. > > Sure, unless they tell users what the behavior is > and users choose to use them, i.e., choose that > behavior. An "application" can present choices to > users just as much as a user option can. > > The function `customize-save-variable' is an > "application" that a user can use to change, i.e., > override an option setting. What makes it OK is > that the command tells you what it does, and it's > up to use whether you use it. With one subtle distinction: If an application tells me that in order to get a better user experience I should customize a variable in a certain way, I usually trust it. I will trust it even more, if it supports my own previously customized value. But I don't trust an application that tells me that in order to get a better user experience it will make the customizations for me. >> Standalone minibuffer frames are not subject to the restrictions cited >> above. Their size is constrained only by that of the display screen. > > Good to hear. I tacitly assume that standalone minibuffer management obeys any customization of the option 'resize-mini-frames' instead. > But why the restrictions for non-standalone? > > What I said about Icicles is independent of a standalone > minibuffer frame. There are lots of situations under which > minibuffer content can reasonably be more than a line or two. > > I don't see any good reason presented for such restrictions. The default minibuffer windows work well under fair use. Displaying a few lines of text is OK. Using a quarter of a frame's height can be already troublesome, in particular with small windows present at the frame's bottom. martin ^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [PATCH] Support "\n" in icomplete-separator 2020-11-11 19:10 ` martin rudalics 2020-11-11 19:49 ` Drew Adams @ 2020-11-11 19:51 ` Drew Adams 1 sibling, 0 replies; 115+ messages in thread From: Drew Adams @ 2020-11-11 19:51 UTC (permalink / raw To: martin rudalics, Andrii Kolomoiets, Eli Zaretskii Cc: spacibba, monnier, emacs-devel > that the command tells you what it does, and it's > up to use whether you use it. ^ you ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 21:09 ` Andrii Kolomoiets 2020-11-11 8:27 ` martin rudalics @ 2020-11-11 16:30 ` Eli Zaretskii 2020-11-12 22:51 ` Andrii Kolomoiets 1 sibling, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-11 16:30 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: spacibba, monnier, emacs-devel > From: Andrii Kolomoiets <andreyk.mad@gmail.com> > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Tue, 10 Nov 2020 23:09:03 +0200 > > >> (defvar o (make-overlay 0 0 nil t t)) > >> (minibuffer-with-setup-hook > >> (lambda () > >> (set (make-local-variable 'face-remapping-alist) > >> '((default :height 1.3))) > >> (move-overlay o (point) (point) (current-buffer)) > >> (let ((text (mapconcat > >> #'identity > >> '("Some" "text" "that" "will" "not" "fit" > >> "the" "minibuffer" "window") > >> "\n"))) > >> (put-text-property 0 1 'cursor t text) > >> (overlay-put o 'after-string text))) > >> (read-string "Multiline\nprompt: ")) > >> > >> Is it possible to make the prompt visible? Should I file bug report > >> for this? > > > > What is the bug here? > > I don't take the overlay text as the actual text but rather like a hint > or helper. E.g. in icomplete-mode overlay text shows what part of the > text can be automatically completed. Overlay text can be completelly > hidden and even in this case I will be able to enter the text. > > The prompt is more important. Imagine there are two prompts: "Selected > file will be deleted. Select file: " and "Selected file will be > opened. Selected file: ". I certainly don't want to see only "Select > file:" because all the space is occupied by hints. Hide hints but show > me the full prompt. That is one way of looking at this. But it is not the only one, or at least it doesn't necessarily fit all the uses of the minibuffer. First, the overlay text is not just a "hint": sometimes it is very important to let you know what to type next. For example, the list of files in a large directory that are completion candidates is very important to see, unless you know in advance what file you want. Moreover, in some cases those "hints" are the _only_ way of knowing what inputs are acceptable: imagine a multiple-selection question where only a finite set of possible answers is acceptable, and you don't know in advance what that set is. E.g., this: Send this email message by: {Mailclient, Smtp, XDG-email} - - - Without seeing the possible answers, what are your chances of knowing what to type? OTOH, sometimes the prompt is not important: when you yourself invoke the command that prompts. For example, if you type "C-x C-f", how important is it for you to see the "Find file" prompt? Probably not too important. > The point is more important than the prompt, obviously. I must see > where and what I typed. That is a non-issue, since Emacs always shows point. > IMO the minibuffer behavior about the prompt, the text and the overlay > should be: show as much text before point as possible (including the > prompt), then show the rest of the text (in case the point is not at the > end of the text) and then show the overlay text. Do you still think this is always true? > And here I come to the answer to your question: for me, the bug here is > that the prompt is hidden in favor of the overlay text. The strategy Emacs uses to display stuff in the mini-window is shared by both minibuffer and echo-area display -- in the latter case your proposal that distinguishes between the prompt, the rest of the text, and the overlay at the end, will not necessarily make sense. The design of that strategy assumed that text displayed in the mini-window is relatively short. It is easy to break this strategy by using features that were never intended to be extensively used in the mini-window. But those uses don't invalidate the design assumptions, they just demand support for very different use cases. Thus, a "bug" is not an appropriate name for what you are bringing up, and I hope you will agree that a single strategy will never be able to cover all the possible uses of the mini-window. The conclusion, IMO, is that the application should tell the display engine how it wants to display the stuff in the mini-window in the "unusual" cases, where the default strategy produces sub-optimal results. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-11 16:30 ` Eli Zaretskii @ 2020-11-12 22:51 ` Andrii Kolomoiets 2020-11-13 8:39 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-12 22:51 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> I don't take the overlay text as the actual text but rather like a hint >> or helper. E.g. in icomplete-mode overlay text shows what part of the >> text can be automatically completed. Overlay text can be completelly >> hidden and even in this case I will be able to enter the text. >> >> The prompt is more important. Imagine there are two prompts: "Selected >> file will be deleted. Select file: " and "Selected file will be >> opened. Selected file: ". I certainly don't want to see only "Select >> file:" because all the space is occupied by hints. Hide hints but show >> me the full prompt. > > That is one way of looking at this. But it is not the only one, or at > least it doesn't necessarily fit all the uses of the minibuffer. > > First, the overlay text is not just a "hint": sometimes it is very > important to let you know what to type next. For example, the list of > files in a large directory that are completion candidates is very > important to see, unless you know in advance what file you want. > Moreover, in some cases those "hints" are the _only_ way of knowing > what inputs are acceptable: Can you please show me the example of such usage in the default configuration? As I can see, Emacs by default doesn't show any hints in the minibuffer while reading user input. Even with the icomplete-mode enabled, possible completions are not visible by default if the input is empty: one must also enable icomplete-show-matches-on-no-input. > imagine a multiple-selection question where only a finite set of > possible answers is acceptable, and you don't know in advance what > that set is. E.g., this: > > Send this email message by: {Mailclient, Smtp, XDG-email} > - - - > > Without seeing the possible answers, what are your chances of knowing > what to type? Chances are pretty good: I'll press TAB to see the *Completions* buffer. Those completion hints are not replacing usage of the usual Emacs completion system, but complements it, at least in the icomplete-mode. > OTOH, sometimes the prompt is not important: when you yourself invoke > the command that prompts. For example, if you type "C-x C-f", how > important is it for you to see the "Find file" prompt? Probably not > too important. Next to "C-x C-f" is "C-x C-d", so if you accidentally hit the "d" instead of the "f", the prompt is the only one who can tell you why no files are showed in the completion hints. For me the prompt is important. Sometimes I hit "C-x v d" instead of "C-x C-f" and try to complete filename to find. >> IMO the minibuffer behavior about the prompt, the text and the overlay >> should be: show as much text before point as possible (including the >> prompt), then show the rest of the text (in case the point is not at the >> end of the text) and then show the overlay text. > > Do you still think this is always true? > >> And here I come to the answer to your question: for me, the bug here is >> that the prompt is hidden in favor of the overlay text. > > The strategy Emacs uses to display stuff in the mini-window is shared > by both minibuffer and echo-area display -- in the latter case your > proposal that distinguishes between the prompt, the rest of the text, > and the overlay at the end, will not necessarily make sense. Oh, in this case let's try even simpler approach: show as much text before point as possible. > The design of that strategy assumed that text displayed in the > mini-window is relatively short. It is easy to break this strategy by > using features that were never intended to be extensively used in the > mini-window. Yes, and I'm not really fond of those insane examples with multiline promts. And if it is the application responsible for keeping the prompt short, we must be ready for long user inputs. For example, better show me the prompt and the default directory on "C-x C-f" rather than all filenames in the directory. > But those uses don't invalidate the design assumptions, they just > demand support for very different use cases. Then I have a question about the display strategy: why is the tail of the message is more important than the head? For example, evaluate this buffer: (setq max-mini-window-height 1) (set-frame-width nil 77) Now move point to the "max-mini-window-height" and wait to eldoc message to come up. What I see in the echo-area is "fer and the echo area).". > Thus, a "bug" is not an appropriate name for what you are bringing up, > and I hope you will agree that a single strategy will never be able to > cover all the possible uses of the mini-window. Yes, I agree. > The conclusion, IMO, is that the application should tell the display > engine how it wants to display the stuff in the mini-window in the > "unusual" cases, where the default strategy produces sub-optimal > results. I see many applications are trying their best to fit the text into the miniwindow. Can the display strategy be changed to display the beginning of the text by default? Or every application must use solution provided by Gregory? BTW, icomplete-mode is trying way too hard :) Just found this while playing with completing-read: Evaluate buffer: (icomplete-mode) (setq max-mini-window-height 1) (setq icomplete-prospects-height 1) (setq icomplete-show-matches-on-no-input t) (completing-read "Long prompt to ask user how to send this email message. By: " '("Mailclient" "Smtp" "XDG-email")) Now use C-. to switch between completion candidates. All but "Smtp" are hidden with just "[Matched]" printed. In this letter I have tried to give real examples that describes my point of view. It would be interesting for me to know about use cases with the opposite point of view. Thanks! ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-12 22:51 ` Andrii Kolomoiets @ 2020-11-13 8:39 ` Eli Zaretskii 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. 2020-11-13 20:18 ` Andrii Kolomoiets 0 siblings, 2 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 8:39 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: spacibba, monnier, emacs-devel > From: Andrii Kolomoiets <andreyk.mad@gmail.com> > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Fri, 13 Nov 2020 00:51:25 +0200 > > > First, the overlay text is not just a "hint": sometimes it is very > > important to let you know what to type next. For example, the list of > > files in a large directory that are completion candidates is very > > important to see, unless you know in advance what file you want. > > Moreover, in some cases those "hints" are the _only_ way of knowing > > what inputs are acceptable: > > Can you please show me the example of such usage in the default > configuration? emacs -Q M-x icomplete-mode RET C-x C-f > As I can see, Emacs by default doesn't show any hints in the > minibuffer while reading user input. We are not talking about the default completion in this thread, we are talking about icomplete-mode and its ilk. They work differently, and in particular do show completion candidates automatically in the minibuffer. > Even with the icomplete-mode enabled, possible completions are not > visible by default See the trivial example of the contrary above. > > Send this email message by: {Mailclient, Smtp, XDG-email} > > - - - > > > > Without seeing the possible answers, what are your chances of knowing > > what to type? > > Chances are pretty good: I'll press TAB to see the *Completions* buffer. Pressing TAB seems to be against the philosophy of icomplete, ivy, and similar features, at least AFAIU: they display the candidates without any prior request by the user. > > OTOH, sometimes the prompt is not important: when you yourself invoke > > the command that prompts. For example, if you type "C-x C-f", how > > important is it for you to see the "Find file" prompt? Probably not > > too important. > > Next to "C-x C-f" is "C-x C-d", so if you accidentally hit the "d" > instead of the "f", the prompt is the only one who can tell you why no > files are showed in the completion hints. For me the prompt is > important. Sometimes I hit "C-x v d" instead of "C-x C-f" and try to > complete filename to find. You are just confirming the point I want to make: that sometimes we want/need to see the beginning, and sometimes we don't. IOW, that there are examples from either class doesn't mean one of the two classes is invalid or not interesting. > > The strategy Emacs uses to display stuff in the mini-window is shared > > by both minibuffer and echo-area display -- in the latter case your > > proposal that distinguishes between the prompt, the rest of the text, > > and the overlay at the end, will not necessarily make sense. > > Oh, in this case let's try even simpler approach: show as much text > before point as possible. What is "this case"? If "this case" is limited to echo-area display, then it cannot be shared with minibuffer display. If you mean both use cases, then "displaying as much as possible before point" will yield sub-optimal results for minibuffer input, when some text is displayed after point, whether as an aoverlay string or not. > > But those uses don't invalidate the design assumptions, they just > > demand support for very different use cases. > > Then I have a question about the display strategy: why is the tail of > the message is more important than the head? It is based on heuristic, and assumes the default values of the variables. It also assumes that the mini-window is not used to show too much stuff. > For example, evaluate this buffer: > > (setq max-mini-window-height 1) > (set-frame-width nil 77) > > Now move point to the "max-mini-window-height" and wait to eldoc message > to come up. > What I see in the echo-area is "fer and the echo area).". Yes, with radical enough customizations of the defaults, the results could be disastrous. However, the above could arguably be seen as a bug in ElDoc: it should arrange for the mini-window to be configured properly to show the info, or perhaps use the mode line in this case. > > The conclusion, IMO, is that the application should tell the display > > engine how it wants to display the stuff in the mini-window in the > > "unusual" cases, where the default strategy produces sub-optimal > > results. > > I see many applications are trying their best to fit the text into the > miniwindow. Can the display strategy be changed to display the > beginning of the text by default? We can do that, but I don't think it would be TRT, because the current strategy does work in many use cases. I thin a better way is to let applications control this aspect of the behavior, because we will never be able to find a solution that always works, what with all the different settings and kinds of display in the mini-window. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 8:39 ` Eli Zaretskii @ 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:02 ` Eli Zaretskii 2020-11-13 19:27 ` Andrii Kolomoiets 2020-11-13 20:18 ` Andrii Kolomoiets 1 sibling, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-13 12:56 UTC (permalink / raw To: Eli Zaretskii; +Cc: Andrii Kolomoiets, spacibba, monnier, emacs-devel Andrii Kolomoiets: >> For example, evaluate this buffer: >> >> (setq max-mini-window-height 1) >> (set-frame-width nil 77) >> >> Now move point to the "max-mini-window-height" and wait to eldoc >> message to come up. What I see in the echo-area is "fer and the echo >> area).". No, the default configuration displays "max-mini-window-height: Maximum height for resizing mini-windows (the minibu". Eli Zaretskii: >> I see many applications are trying their best to fit the text into the >> miniwindow. Can the display strategy be changed to display the >> beginning of the text by default? > > We can do that, but I don't think it would be TRT, because the current > strategy does work in many use cases. I thin a better way is to let > applications control this aspect of the behavior, because we will never > be able to find a solution that always works, what with all the > different settings and kinds of display in the mini-window. > I fully agree with you. And the question is again: given that the solution I offered doesn't please you, how should that be done? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. @ 2020-11-13 13:02 ` Eli Zaretskii 2020-11-13 13:44 ` Gregory Heytings via Emacs development discussions. 2020-11-13 19:27 ` Andrii Kolomoiets 1 sibling, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 13:02 UTC (permalink / raw To: Gregory Heytings; +Cc: spacibba, monnier, andreyk.mad, emacs-devel > Date: Fri, 13 Nov 2020 12:56:12 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, spacibba@aol.com, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > We can do that, but I don't think it would be TRT, because the current > > strategy does work in many use cases. I thin a better way is to let > > applications control this aspect of the behavior, because we will never > > be able to find a solution that always works, what with all the > > different settings and kinds of display in the mini-window. > > I fully agree with you. And the question is again: given that the > solution I offered doesn't please you, how should that be done? As mentioned in the original discussion: with a special text property or overlay property on the first character of the text to be shown in the mini-window. The display engine will see that and heed it. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:02 ` Eli Zaretskii @ 2020-11-13 13:44 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:55 ` Eli Zaretskii 0 siblings, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-13 13:44 UTC (permalink / raw To: Eli Zaretskii; +Cc: andreyk.mad, spacibba, monnier, emacs-devel >>> We can do that, but I don't think it would be TRT, because the current >>> strategy does work in many use cases. I thin a better way is to let >>> applications control this aspect of the behavior, because we will >>> never be able to find a solution that always works, what with all the >>> different settings and kinds of display in the mini-window. >> >> I fully agree with you. And the question is again: given that the >> solution I offered doesn't please you, how should that be done? > > As mentioned in the original discussion: with a special text property or > overlay property on the first character of the text to be shown in the > mini-window. The display engine will see that and heed it. > Okay. As mentioned in the original discussion, I volunteered to do that, but haven't heard from you since then. And IIUC, Stefan didn't think this is the optimal way to do this, does he now agree that it's what should be done? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:44 ` Gregory Heytings via Emacs development discussions. @ 2020-11-13 13:55 ` Eli Zaretskii 2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 115+ messages in thread From: Eli Zaretskii @ 2020-11-13 13:55 UTC (permalink / raw To: Gregory Heytings; +Cc: spacibba, monnier, andreyk.mad, emacs-devel > Date: Fri, 13 Nov 2020 13:44:43 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: andreyk.mad@gmail.com, spacibba@aol.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > > As mentioned in the original discussion: with a special text property or > > overlay property on the first character of the text to be shown in the > > mini-window. The display engine will see that and heed it. > > Okay. As mentioned in the original discussion, I volunteered to do that, > but haven't heard from you since then. Thank you for volunteering. What do you need to hear beyond what I already said? > And IIUC, Stefan didn't think this is the optimal way to do this, > does he now agree that it's what should be done? Stefan wanted something more general. It's fine with me to provide a more general feature, but the simpler one would suffice (and will do the job in all the use cases we've been discussing, AFAIU). ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 13:55 ` Eli Zaretskii @ 2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions. 2020-11-16 17:40 ` Eli Zaretskii 2020-11-16 17:41 ` Stefan Monnier 0 siblings, 2 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-16 10:25 UTC (permalink / raw To: Eli Zaretskii; +Cc: andreyk.mad, spacibba, monnier, emacs-devel >>> As mentioned in the original discussion: with a special text property >>> or overlay property on the first character of the text to be shown in >>> the mini-window. The display engine will see that and heed it. >> >> Okay. As mentioned in the original discussion, I volunteered to do >> that, but haven't heard from you since then. > > Thank you for volunteering. > > What do you need to hear beyond what I already said? > I would prefer to be sure that there is an agreement that your proposed solution (using a text property or an overlay property) is the way to go. AFAIU the discussion between you and Stefan in bug#43572 stopped before reaching such an agreement. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions. @ 2020-11-16 17:40 ` Eli Zaretskii 2020-11-16 17:41 ` Stefan Monnier 1 sibling, 0 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-16 17:40 UTC (permalink / raw To: Gregory Heytings; +Cc: spacibba, monnier, andreyk.mad, emacs-devel > Date: Mon, 16 Nov 2020 10:25:28 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: andreyk.mad@gmail.com, spacibba@aol.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > >> Okay. As mentioned in the original discussion, I volunteered to do > >> that, but haven't heard from you since then. > > > > Thank you for volunteering. > > > > What do you need to hear beyond what I already said? > > > > I would prefer to be sure that there is an agreement that your proposed > solution (using a text property or an overlay property) is the way to go. > AFAIU the discussion between you and Stefan in bug#43572 stopped before > reaching such an agreement. That's not how Emacs development works. So my recommendation is not to wait for any such advance agreement. However, eventually it's your call. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions. 2020-11-16 17:40 ` Eli Zaretskii @ 2020-11-16 17:41 ` Stefan Monnier 2020-11-16 18:24 ` Eli Zaretskii 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 1 sibling, 2 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-16 17:41 UTC (permalink / raw To: Gregory Heytings; +Cc: Eli Zaretskii, spacibba, andreyk.mad, emacs-devel > I would prefer to be sure that there is an agreement that your proposed > solution (using a text property or an overlay property) is the way to > go. AFAIU the discussion between you and Stefan in bug#43572 stopped before > reaching such an agreement. My proposal was for a more ambitious new feature which would be used not just in the minibuffer but also in things like diff-mode or smerge-mode (to tell the redisplay that when we're in a hunk, it's a good idea to try and focus on that hunk). Such a new feature is well beyond the scope of your needs (and introduces a lot of open questions), so better ignore it at this point. I just hijacked this discussion because it reminded me of a need I've had in other contexts. Sorry 'bout that. Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 17:41 ` Stefan Monnier @ 2020-11-16 18:24 ` Eli Zaretskii 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 1 sibling, 0 replies; 115+ messages in thread From: Eli Zaretskii @ 2020-11-16 18:24 UTC (permalink / raw To: Stefan Monnier; +Cc: ghe, spacibba, andreyk.mad, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, andreyk.mad@gmail.com, spacibba@aol.com, > emacs-devel@gnu.org > Date: Mon, 16 Nov 2020 12:41:28 -0500 > > My proposal was for a more ambitious new feature which would be used not > just in the minibuffer but also in things like diff-mode or smerge-mode Nothing wrong with that, we could always extend the initial implementation to support those additional situations as well. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-16 17:41 ` Stefan Monnier 2020-11-16 18:24 ` Eli Zaretskii @ 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 2020-11-17 14:05 ` Stefan Monnier 1 sibling, 1 reply; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-17 11:51 UTC (permalink / raw To: Stefan Monnier; +Cc: Eli Zaretskii, spacibba, andreyk.mad, emacs-devel >> I would prefer to be sure that there is an agreement that your proposed >> solution (using a text property or an overlay property) is the way to >> go. AFAIU the discussion between you and Stefan in bug#43572 stopped >> before reaching such an agreement. > > My proposal was for a more ambitious new feature which would be used not > just in the minibuffer but also in things like diff-mode or smerge-mode > (to tell the redisplay that when we're in a hunk, it's a good idea to > try and focus on that hunk). > I was not thinking about that feature, which indeed is much more ambitious, but about the `minibuffer-scroll-generic' feature you proposed, which would have solved the issue at hand, and for which you wrote a (partial) patch. Now I think indeed that just doing what Eli wants is the best way to move forward. > > Such a new feature is well beyond the scope of your needs (and > introduces a lot of open questions), so better ignore it at this point. > I just hijacked this discussion because it reminded me of a need I've > had in other contexts. Sorry 'bout that. > No worries, there have been several discussions in parallel, and perhaps I have misunderstood some of the messages. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. @ 2020-11-17 14:05 ` Stefan Monnier 0 siblings, 0 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-17 14:05 UTC (permalink / raw To: Gregory Heytings; +Cc: Eli Zaretskii, spacibba, andreyk.mad, emacs-devel > I was not thinking about that feature, which indeed is much more ambitious, > but about the `minibuffer-scroll-generic' feature you proposed, which would > have solved the issue at hand, and for which you wrote a (partial) patch. Ah you mean the patch where I basically remove the ad-hoc scrolling code from resize_mini_window? Eli doesn't like it, so it would have to be activated by a config variable (and deactivated by default). I'm using it in my local Emacs (see patch below) and have been tempted to add it to master (under the control of a boolean config variable), but its effect is so minor that I'm not sure it's worth the trouble. If you think you can make use of it, then I can clean it up and push it. > Now I think indeed that just doing what Eli wants is the best way to > move forward. Sounds about right. Stefan diff --git a/src/xdisp.c b/src/xdisp.c index 021c99dec4..d953120e28 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11814,10 +11814,10 @@ resize_mini_window_1 (void *a1, Lisp_Object exactly) means size the window exactly to the size needed. Otherwise, it's only enlarged until W's buffer is empty. - Set W->start to the right place to begin display. If the whole - contents fit, start at the beginning. Otherwise, start so as - to make the end of the contents appear. This is particularly - important for y-or-n-p, but seems desirable generally. + If the whole contents fit, set W->start at the beginning. + Otherwise, let redisplay do its thing to make sure point is displayed, + so we can control which part is more important by placing point + accordingly. Value is true if the window height has been changed. */ @@ -11839,9 +11839,10 @@ resize_mini_window (struct window *w, bool exact_p) return false; /* By default, start display at the beginning. */ - set_marker_both (w->start, w->contents, - BUF_BEGV (XBUFFER (w->contents)), - BUF_BEGV_BYTE (XBUFFER (w->contents))); + /* bug#43519: Let the redisplay choose the window start! + * set_marker_both (w->start, w->contents, + * BUF_BEGV (XBUFFER (w->contents)), + * BUF_BEGV_BYTE (XBUFFER (w->contents))); */ /* Nil means don't try to resize. */ if ((NILP (Vresize_mini_windows) @@ -11900,27 +11901,18 @@ resize_mini_window (struct window *w, bool exact_p) if (height > max_height) { height = (max_height / unit) * unit; - init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); - move_it_vertically_backward (&it, height - unit); - /* The following move is usually a no-op when the stuff - displayed in the mini-window comes entirely from buffer - text, but it is needed when some of it comes from overlay - strings, especially when there's an after-string at ZV. - This happens with some completion packages, like - icomplete, ido-vertical, etc. With those packages, if we - don't force w->start to be at the beginning of a screen - line, important parts of the stuff in the mini-window, - such as user prompt, will be hidden from view. */ - move_it_by_lines (&it, 0); - start = it.current.pos; - /* Prevent redisplay_window from recentering, and thus from - overriding the window-start point we computed here. */ - w->start_at_line_beg = false; + /* bug#43519: Let the redisplay choose the window start! + * + * init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID); + * move_it_vertically_backward (&it, height - unit); + * start = it.current.pos; */ } else - SET_TEXT_POS (start, BEGV, BEGV_BYTE); + { + SET_TEXT_POS (start, BEGV, BEGV_BYTE); - SET_MARKER_FROM_TEXT_POS (w->start, start); + SET_MARKER_FROM_TEXT_POS (w->start, start); + } if (EQ (Vresize_mini_windows, Qgrow_only)) { ^ permalink raw reply related [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:02 ` Eli Zaretskii @ 2020-11-13 19:27 ` Andrii Kolomoiets 2020-11-17 8:59 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-13 19:27 UTC (permalink / raw To: Gregory Heytings via Emacs development discussions. Cc: Gregory Heytings, Eli Zaretskii, spacibba, monnier Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> writes: > Andrii Kolomoiets: >>> For example, evaluate this buffer: >>> >>> (setq max-mini-window-height 1) >>> (set-frame-width nil 77) >>> >>> Now move point to the "max-mini-window-height" and wait to eldoc >>> message to come up. What I see in the echo-area is "fer and the >>> echo area).". > > No, the default configuration displays "max-mini-window-height: > Maximum height for resizing mini-windows (the minibu". Checked recent master NS and GTK builds. Both shows me "fer and the echo area).". ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 19:27 ` Andrii Kolomoiets @ 2020-11-17 8:59 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 115+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-11-17 8:59 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel, Eli Zaretskii, spacibba, monnier >>>> For example, evaluate this buffer: >>>> >>>> (setq max-mini-window-height 1) >>>> (set-frame-width nil 77) >>>> >>>> Now move point to the "max-mini-window-height" and wait to eldoc >>>> message to come up. What I see in the echo-area is "fer and the echo >>>> area).". >> >> No, the default configuration displays "max-mini-window-height: Maximum >> height for resizing mini-windows (the minibu". > > Checked recent master NS and GTK builds. Both shows me "fer and the > echo area).". > You are correct. I bisected this behavior change to commit 10e7c76ee3e263a7691745d9384bae475c2f5c86 (Oct 4), which was merged into master on Oct 26. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 8:39 ` Eli Zaretskii 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. @ 2020-11-13 20:18 ` Andrii Kolomoiets 2020-11-14 6:17 ` Ergus 1 sibling, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-13 20:18 UTC (permalink / raw To: Eli Zaretskii; +Cc: spacibba, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > We are not talking about the default completion in this thread, we are > talking about icomplete-mode and its ilk. They work differently, and > in particular do show completion candidates automatically in the > minibuffer. > >> > Without seeing the possible answers, what are your chances of knowing >> > what to type? >> >> Chances are pretty good: I'll press TAB to see the *Completions* buffer. > > Pressing TAB seems to be against the philosophy of icomplete, ivy, and > similar features, at least AFAIU: they display the candidates without > any prior request by the user. Among icomplete, ivy and ido modes only ivy is overriding TAB key. With icomplete and ido the overlay text is not the _only_ way of knowing what inputs are acceptable. Seems like they has nothing against using TAB to complete text. >> Oh, in this case let's try even simpler approach: show as much text >> before point as possible. > > What is "this case"? If "this case" is limited to echo-area display, > then it cannot be shared with minibuffer display. If you mean both > use cases, then "displaying as much as possible before point" will > yield sub-optimal results for minibuffer input, when some text is > displayed after point, whether as an aoverlay string or not. I agree. >> > The conclusion, IMO, is that the application should tell the display >> > engine how it wants to display the stuff in the mini-window in the >> > "unusual" cases, where the default strategy produces sub-optimal >> > results. >> >> I see many applications are trying their best to fit the text into the >> miniwindow. Can the display strategy be changed to display the >> beginning of the text by default? > > We can do that, but I don't think it would be TRT, because the current > strategy does work in many use cases. I thin a better way is to let > applications control this aspect of the behavior, because we will > never be able to find a solution that always works, what with all the > different settings and kinds of display in the mini-window. Got it. Looking forward for usable tool to let applications control the display behavior. Thanks! ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-13 20:18 ` Andrii Kolomoiets @ 2020-11-14 6:17 ` Ergus 2020-11-14 20:36 ` Andrii Kolomoiets 0 siblings, 1 reply; 115+ messages in thread From: Ergus @ 2020-11-14 6:17 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: Eli Zaretskii, emacs-devel, monnier On Fri, Nov 13, 2020 at 10:18:58PM +0200, Andrii Kolomoiets wrote: >Eli Zaretskii <eliz@gnu.org> writes: > >> We are not talking about the default completion in this thread, we are >> talking about icomplete-mode and its ilk. They work differently, and >> in particular do show completion candidates automatically in the >> minibuffer. >> >>> > Without seeing the possible answers, what are your chances of knowing >>> > what to type? >>> >>> Chances are pretty good: I'll press TAB to see the *Completions* buffer. >> >> Pressing TAB seems to be against the philosophy of icomplete, ivy, and >> similar features, at least AFAIU: they display the candidates without >> any prior request by the user. > >Among icomplete, ivy and ido modes only ivy is overriding TAB key. With >icomplete and ido the overlay text is not the _only_ way of knowing what >inputs are acceptable. Seems like they has nothing against using TAB to >complete text. > Ivy has ivy-partial-or-done bind to tab by default. Which completes common part or open on single alternative with the default action (find-file for file; dired for directories...). But it is possible to bind tab to ivy-partial in ivy-minibuffer-map instead. Then you have only completion on tab which is probably more familiar for shell users, and a more predictable behavior. Actually the most opposed completion system to use tabs is helm not ivy ;p ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-14 6:17 ` Ergus @ 2020-11-14 20:36 ` Andrii Kolomoiets 2020-11-15 2:39 ` Ergus 0 siblings, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-14 20:36 UTC (permalink / raw To: Ergus; +Cc: Eli Zaretskii, monnier, emacs-devel Ergus <spacibba@aol.com> writes: >>> Pressing TAB seems to be against the philosophy of icomplete, ivy, and >>> similar features, at least AFAIU: they display the candidates without >>> any prior request by the user. >> >>Among icomplete, ivy and ido modes only ivy is overriding TAB key. With >>icomplete and ido the overlay text is not the _only_ way of knowing what >>inputs are acceptable. Seems like they has nothing against using TAB to >>complete text. >> > Ivy has ivy-partial-or-done bind to tab by default. Which completes > common part or open on single alternative with the default action > (find-file for file; dired for directories...). > > But it is possible to bind tab to ivy-partial in ivy-minibuffer-map > instead. Then you have only completion on tab which is probably more > familiar for shell users, and a more predictable behavior. Actually the > most opposed completion system to use tabs is helm not ivy ;p In emacs -Q: 1. M-: (set-frame-height nil 1) 2. M-x 3. TAB Completion buffer is opened and from now each pressing of TAB will scroll completions. 4. ivy-mode RET 5. M-x 6. TAB No completions are visible 7. TAB No completions so far but the 'enable-theme' command is invoked. With TAB rebinded to 'ivy-partial', the command in step 7 is not invoked, but still no completions are showed. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-14 20:36 ` Andrii Kolomoiets @ 2020-11-15 2:39 ` Ergus 2020-11-15 19:32 ` Andrii Kolomoiets 0 siblings, 1 reply; 115+ messages in thread From: Ergus @ 2020-11-15 2:39 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: Eli Zaretskii, emacs-devel, monnier On Sat, Nov 14, 2020 at 10:36:06PM +0200, Andrii Kolomoiets wrote: >Ergus <spacibba@aol.com> writes: > >>>> Pressing TAB seems to be against the philosophy of icomplete, ivy, and >>>> similar features, at least AFAIU: they display the candidates without >>>> any prior request by the user. >>> >>>Among icomplete, ivy and ido modes only ivy is overriding TAB key. With >>>icomplete and ido the overlay text is not the _only_ way of knowing what >>>inputs are acceptable. Seems like they has nothing against using TAB to >>>complete text. >>> >> Ivy has ivy-partial-or-done bind to tab by default. Which completes >> common part or open on single alternative with the default action >> (find-file for file; dired for directories...). >> >> But it is possible to bind tab to ivy-partial in ivy-minibuffer-map >> instead. Then you have only completion on tab which is probably more >> familiar for shell users, and a more predictable behavior. Actually the >> most opposed completion system to use tabs is helm not ivy ;p > >In emacs -Q: >1. M-: (set-frame-height nil 1) >2. M-x >3. TAB >Completion buffer is opened and from now each pressing of TAB will >scroll completions. >4. ivy-mode RET >5. M-x >6. TAB >No completions are visible >7. TAB >No completions so far but the 'enable-theme' command is invoked. > >With TAB rebinded to 'ivy-partial', the command in step 7 is not >invoked, but still no completions are showed. Something is wrong in this setup or I don't understand what do you mean, sorry. If you do: Git clone git@github.com:abo-abo/swiper.git cd swiper make plain M-x Don't you get a completion list in minibuffer (without needing a tab)? Pressing <Tab> does nothing in this case... because it is not needed. But If you type something like: defi<Tab> don't you get: defin (completing the n) and a list with completion candidates starting with "defin"? (6 in my case) then if you do: e<Tab> you get: define- (completing the -) and a new shorter list with less candidates? Ivy doesn't need the tab to show completion candidates, but it completes with tab and shows the candidates in the minibuffer (like icomplete does, remember ivy is a fork of icomplete). Or when you say "completion" are you referring to the *Completions* buffer only? Is the *Completions* buffer useful somehow when you already have the same candidates in the ivy minibuffer with all the functionalities? without needing to use the mouse (ivy candidates are clickable) or change window to select a candidate? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-15 2:39 ` Ergus @ 2020-11-15 19:32 ` Andrii Kolomoiets 0 siblings, 0 replies; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-15 19:32 UTC (permalink / raw To: Ergus; +Cc: Eli Zaretskii, monnier, emacs-devel Ergus <spacibba@aol.com> writes: >>In emacs -Q: >>1. M-: (set-frame-height nil 1) >>2. M-x >>3. TAB >>Completion buffer is opened and from now each pressing of TAB will >>scroll completions. >>4. ivy-mode RET >>5. M-x >>6. TAB >>No completions are visible >>7. TAB >>No completions so far but the 'enable-theme' command is invoked. >> >>With TAB rebinded to 'ivy-partial', the command in step 7 is not >>invoked, but still no completions are showed. > > Something is wrong in this setup or I don't understand what do you mean, > sorry. > > If you do: > > Git clone git@github.com:abo-abo/swiper.git > cd swiper > make plain > M-x > > Don't you get a completion list in minibuffer (without needing a tab)? Try to make the frame as small as possible with '(set-frame-height nil 1)' Do you get a completions list in minibuffer? > Pressing <Tab> does nothing in this case... because it is not needed. The problem is that with ivy completions in minibuffer is the only way to see possible completions. Ivy overrides the 'max-mini-window-height' variable with the 'ivy-height' variable, but in some cases mini window can't occupy that many lines. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-10 17:18 ` Andrii Kolomoiets 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. 2020-11-10 18:23 ` Eli Zaretskii @ 2020-11-10 20:01 ` Stefan Monnier 2 siblings, 0 replies; 115+ messages in thread From: Stefan Monnier @ 2020-11-10 20:01 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: Eli Zaretskii, spacibba, emacs-devel > In 'emacs -Q', evaluate buffer with the following code: > > (defvar o (make-overlay 0 0 nil t t)) > (minibuffer-with-setup-hook [...] > > Is it possible to make the prompt visible? The prompt is visible for me here (not all of it, but the second line). So if you make it a bug-report, please clarify what you mean by "visible". Stefan ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-05 23:10 Andrii Kolomoiets 2020-11-05 23:29 ` Stefan Monnier 2020-11-05 23:57 ` Ergus @ 2020-11-06 5:52 ` Jean Louis 2020-11-06 12:40 ` Andrii Kolomoiets 2 siblings, 1 reply; 115+ messages in thread From: Jean Louis @ 2020-11-06 5:52 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-06 02:11]: > Hi, > > I'm a bit late to the icomplete-vertical party, but please let me show > you my approach at supporting "\n" in 'icomplete-separator'. > > The main idea is to treat the 'icomplete-prospects-height' variable > value as the amount of completions we want to see if there is "\n" in the > 'icomplete-separator'. > > Please see attached patch. > > Also see attached screenshot of minibuffer-only frame after: > > emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" > M-x icomplete-mode > (setq icomplete-prospects-height 5) > (setq icomplete-hide-common-prefix nil) > (setq icomplete-separator "\n ") > (setq resize-mini-frames t) > M-x icomp > > If that approach was already discussed, please let me know. Maybe you can also improve ido-mode to work vertically? ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 5:52 ` Jean Louis @ 2020-11-06 12:40 ` Andrii Kolomoiets 2020-11-06 12:59 ` Jean Louis 0 siblings, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-06 12:40 UTC (permalink / raw To: Jean Louis; +Cc: emacs-devel Jean Louis <bugs@gnu.support> writes: > Maybe you can also improve ido-mode to work vertically? Back in the days when I was the ido user, ido-vertical-mode works fine for me. It's available on MELPA. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 12:40 ` Andrii Kolomoiets @ 2020-11-06 12:59 ` Jean Louis 2020-11-08 20:28 ` Andrii Kolomoiets 0 siblings, 1 reply; 115+ messages in thread From: Jean Louis @ 2020-11-06 12:59 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-06 15:41]: > Jean Louis <bugs@gnu.support> writes: > > > Maybe you can also improve ido-mode to work vertically? > > Back in the days when I was the ido user, ido-vertical-mode works fine > for me. It's available on MELPA. There is difference when feature is built in. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-06 12:59 ` Jean Louis @ 2020-11-08 20:28 ` Andrii Kolomoiets 2020-11-08 20:50 ` Jean Louis 0 siblings, 1 reply; 115+ messages in thread From: Andrii Kolomoiets @ 2020-11-08 20:28 UTC (permalink / raw To: Jean Louis; +Cc: emacs-devel Jean Louis <bugs@gnu.support> writes: > * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-06 15:41]: >> Jean Louis <bugs@gnu.support> writes: >> >> > Maybe you can also improve ido-mode to work vertically? >> >> Back in the days when I was the ido user, ido-vertical-mode works fine >> for me. It's available on MELPA. > > There is difference when feature is built in. Did you try to set the 3rd element of 'ido-decorations' or 'ido-separator' to "\n"? Looks like ido-mode doesn't calculate how many completions will fit into minibuffer. Completions count is specified by the 'ido-max-prospects' variable. ^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH] Support "\n" in icomplete-separator 2020-11-08 20:28 ` Andrii Kolomoiets @ 2020-11-08 20:50 ` Jean Louis 0 siblings, 0 replies; 115+ messages in thread From: Jean Louis @ 2020-11-08 20:50 UTC (permalink / raw To: Andrii Kolomoiets; +Cc: emacs-devel * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-08 23:29]: > Jean Louis <bugs@gnu.support> writes: > > > * Andrii Kolomoiets <andreyk.mad@gmail.com> [2020-11-06 15:41]: > >> Jean Louis <bugs@gnu.support> writes: > >> > >> > Maybe you can also improve ido-mode to work vertically? > >> > >> Back in the days when I was the ido user, ido-vertical-mode works fine > >> for me. It's available on MELPA. > > > > There is difference when feature is built in. > > Did you try to set the 3rd element of 'ido-decorations' or > 'ido-separator' to "\n"? Looks like ido-mode doesn't calculate how many > completions will fit into minibuffer. Completions count is specified by > the 'ido-max-prospects' variable. ido-separator is a variable defined in ‘ido.el’. Its value is nil This variable is obsolete; set 3rd element of `ido-decorations' instead. You can customize this variable. because it is obsolete I did not try using it. I tried with the 3rd element in ido-decorations Now when I try using it, it somehow works. I just forgot to use C-n C-p as C-. and C-, could be remapped. It is not as user friendly. If I search for something (in that vertical ido mode) then I typed few letters, but if I move back and forth and wish to complete selection those few typed letters still remain there and I have to delete them. Somehow it works, depends of familiarity. I know that ido-mode would be complex and sensitive to people who need to work with my database as education level in this country is not for commendation. But in general I see it works. I did not try on large collections and I do not know how to reverse the order of words. ^ permalink raw reply [flat|nested] 115+ messages in thread
end of thread, other threads:[~2020-11-17 14:05 UTC | newest] Thread overview: 115+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<m2a6vv8ko3.fsf@gmail.com> [not found] ` <<20201105235735.oxouuek66ehu5o45@Ergus> [not found] ` <<m2y2je7jcx.fsf@gmail.com> [not found] ` <<20201106151541.dpgep7borlja25su@Ergus> [not found] ` <<m2d00n7gj4.fsf@gmail.com> [not found] ` <<837dqv5huk.fsf@gnu.org> [not found] ` <<m24klys0n2.fsf@gmail.com> [not found] ` <<83mtzp2qj0.fsf@gnu.org> [not found] ` <<m2imad6sh1.fsf@gmail.com> [not found] ` <<83r1p11369.fsf@gnu.org> [not found] ` <<m2a6vo7wcw.fsf@gmail.com> [not found] ` <<ca240036-8493-968d-2204-620f430334b9@gmx.at> [not found] ` <<m2sg9g5j2p.fsf@gmail.com> [not found] ` <<fe70158f-d55a-010a-74ba-2f81d1bb7663@gmx.at> [not found] ` <<837dqr27zs.fsf@gnu.org> 2020-11-11 19:03 ` [PATCH] Support "\n" in icomplete-separator Drew Adams [not found] ` <<alpine.NEB.2.22.394.2011111803220453.17489@sdf.lonestar.org> [not found] ` <<83361f22ah.fsf@gnu.org> [not found] ` <<alpine.NEB.2.22.394.2011111926450453.27530@sdf.lonestar.org> [not found] ` <<83sg9fzlto.fsf@gnu.org> [not found] ` <<alpine.NEB.2.22.394.2011112128400453.4149@sdf.lonestar.org> [not found] ` <<83r1ozz22j.fsf@gnu.org> [not found] ` <<alpine.NEB.2.22.394.2011120932160453.28737@sdf.lonestar.org> [not found] ` <<83d00izloj.fsf@gnu.org> [not found] ` <<alpine.NEB.2.22.394.2011121544550453.26984@sdf.lonestar.org> [not found] ` <<83361ezix2.fsf@gnu.org> 2020-11-12 17:42 ` Drew Adams 2020-11-06 16:30 Drew Adams -- strict thread matches above, loose matches on Subject: below -- 2020-11-05 23:10 Andrii Kolomoiets 2020-11-05 23:29 ` Stefan Monnier 2020-11-06 0:04 ` Ergus 2020-11-06 2:44 ` Stefan Monnier 2020-11-06 8:42 ` Gregory Heytings via Emacs development discussions. 2020-11-06 10:26 ` Andrii Kolomoiets 2020-11-05 23:57 ` Ergus 2020-11-06 8:43 ` Gregory Heytings via Emacs development discussions. 2020-11-06 12:36 ` Andrii Kolomoiets 2020-11-06 15:15 ` Ergus 2020-11-08 20:14 ` Andrii Kolomoiets 2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions. 2020-11-08 20:36 ` Andrii Kolomoiets 2020-11-09 3:28 ` Eli Zaretskii 2020-11-09 21:04 ` Andrii Kolomoiets 2020-11-10 15:13 ` Eli Zaretskii 2020-11-10 17:18 ` Andrii Kolomoiets 2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions. 2020-11-11 9:41 ` Andrii Kolomoiets 2020-11-10 18:23 ` Eli Zaretskii 2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions. 2020-11-10 19:27 ` Eli Zaretskii 2020-11-10 20:00 ` Gregory Heytings via Emacs development discussions. 2020-11-10 21:09 ` Andrii Kolomoiets 2020-11-11 8:27 ` martin rudalics 2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:57 ` Jean Louis 2020-11-11 9:38 ` Andrii Kolomoiets 2020-11-11 10:01 ` martin rudalics 2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions. 2020-11-11 10:53 ` martin rudalics 2020-11-11 11:22 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:49 ` martin rudalics 2020-11-11 15:57 ` Eli Zaretskii 2020-11-11 16:16 ` Jean Louis 2020-11-11 17:06 ` martin rudalics 2020-11-11 17:28 ` Gregory Heytings via Emacs development discussions. 2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:06 ` martin rudalics 2020-11-11 17:26 ` Stefan Monnier 2020-11-11 17:37 ` Gregory Heytings via Emacs development discussions. 2020-11-11 15:32 ` Jean Louis 2020-11-11 15:26 ` Jean Louis 2020-11-11 16:06 ` Eli Zaretskii 2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:19 ` Alfred M. Szmidt 2020-11-11 17:44 ` Gregory Heytings via Emacs development discussions. 2020-11-11 17:50 ` Alfred M. Szmidt 2020-11-11 18:14 ` Eli Zaretskii 2020-11-11 18:09 ` Eli Zaretskii 2020-11-11 18:39 ` Gregory Heytings via Emacs development discussions. 2020-11-11 20:21 ` Eli Zaretskii 2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions. 2020-11-11 21:55 ` Ergus 2020-11-11 22:26 ` Jean Louis 2020-11-11 22:59 ` Stefan Monnier 2020-11-12 3:28 ` Eli Zaretskii 2020-11-12 8:50 ` Gregory Heytings via Emacs development discussions. 2020-11-12 14:36 ` Eli Zaretskii 2020-11-12 15:05 ` Gregory Heytings via Emacs development discussions. 2020-11-12 15:36 ` Eli Zaretskii 2020-11-12 16:10 ` Gregory Heytings via Emacs development discussions. 2020-11-12 17:50 ` Eli Zaretskii 2020-11-13 12:40 ` Gregory Heytings via Emacs development discussions. 2020-11-13 12:59 ` Eli Zaretskii 2020-11-13 13:36 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:52 ` Eli Zaretskii 2020-11-13 15:09 ` Stephen Berman 2020-11-13 16:05 ` Eli Zaretskii 2020-11-13 17:31 ` Stephen Berman 2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions. 2020-11-16 17:44 ` Eli Zaretskii 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 2020-11-12 7:58 ` martin rudalics 2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions. 2020-11-12 14:37 ` Eli Zaretskii 2020-11-12 12:39 ` Dmitry Gutov 2020-11-12 19:31 ` Howard Melman 2020-11-11 14:09 ` Jean Louis 2020-11-11 15:51 ` Eli Zaretskii 2020-11-11 16:05 ` Jean Louis 2020-11-11 18:52 ` Drew Adams 2020-11-11 19:10 ` martin rudalics 2020-11-11 19:49 ` Drew Adams 2020-11-12 7:58 ` martin rudalics 2020-11-11 19:51 ` Drew Adams 2020-11-11 16:30 ` Eli Zaretskii 2020-11-12 22:51 ` Andrii Kolomoiets 2020-11-13 8:39 ` Eli Zaretskii 2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:02 ` Eli Zaretskii 2020-11-13 13:44 ` Gregory Heytings via Emacs development discussions. 2020-11-13 13:55 ` Eli Zaretskii 2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions. 2020-11-16 17:40 ` Eli Zaretskii 2020-11-16 17:41 ` Stefan Monnier 2020-11-16 18:24 ` Eli Zaretskii 2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions. 2020-11-17 14:05 ` Stefan Monnier 2020-11-13 19:27 ` Andrii Kolomoiets 2020-11-17 8:59 ` Gregory Heytings via Emacs development discussions. 2020-11-13 20:18 ` Andrii Kolomoiets 2020-11-14 6:17 ` Ergus 2020-11-14 20:36 ` Andrii Kolomoiets 2020-11-15 2:39 ` Ergus 2020-11-15 19:32 ` Andrii Kolomoiets 2020-11-10 20:01 ` Stefan Monnier 2020-11-06 5:52 ` Jean Louis 2020-11-06 12:40 ` Andrii Kolomoiets 2020-11-06 12:59 ` Jean Louis 2020-11-08 20:28 ` Andrii Kolomoiets 2020-11-08 20:50 ` Jean Louis
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).