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

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

[Andrii Kolomoiets]

[-- 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 --]

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

[Stefan Monnier]

> 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

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

[Ergus]

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?

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

[Stefan Monnier]

> 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

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

[Gregory Heytings via Emacs development discussions.]

>
> 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).

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

[Andrii Kolomoiets]

[-- 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

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

[Ergus]

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!

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

[Gregory Heytings via Emacs development discussions.]

>
> 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.

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

[Andrii Kolomoiets]

[-- 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 --]

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

[Ergus]

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

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

[Andrii Kolomoiets]

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.

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

[Gregory Heytings via Emacs development discussions.]

>> 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).

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

[Andrii Kolomoiets]

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!

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

[Eli Zaretskii]

> 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?

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

[Andrii Kolomoiets]

[-- 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

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

[Eli Zaretskii]

> 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?

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

[Andrii Kolomoiets]

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!

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

[Gregory Heytings via Emacs development discussions.]

>
> (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".

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

[Andrii Kolomoiets]

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.

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

[Eli Zaretskii]

> 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?

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

[Gregory Heytings via Emacs development discussions.]

>> (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.

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>>>> (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.

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

[Andrii Kolomoiets]

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.

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

[martin rudalics]

 > 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

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

[Gregory Heytings via Emacs development discussions.]

>> 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).

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

[Jean Louis]

* 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.

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

[Andrii Kolomoiets]

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")

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

[martin rudalics]

 >> 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

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

[Gregory Heytings via Emacs development discussions.]

>>> 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.

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

[martin rudalics]

 >> 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

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

[Gregory Heytings via Emacs development discussions.]

>>> 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).

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

> 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.

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

[Jean Louis]

* 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.

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

[martin rudalics]

 > 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

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

[Gregory Heytings via Emacs development discussions.]

[-- 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)

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

[Gregory Heytings via Emacs development discussions.]

>> 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.

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

[martin rudalics]

 > 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

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

[Stefan Monnier]

> 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

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

[Gregory Heytings via Emacs development discussions.]

>> 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))

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

[Jean Louis]

* 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.

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

[Jean Louis]

* 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."

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>
> 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.

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

[Alfred M. Szmidt]

   > 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.

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

[Gregory Heytings via Emacs development discussions.]

> > > 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...

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

[Alfred M. Szmidt]

   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...

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

[Eli Zaretskii]

> 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.

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>>> 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.

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>
> 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?

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

[Ergus]

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

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

[Jean Louis]

* 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)))))))))

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

[Stefan Monnier]

> 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

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

[Eli Zaretskii]

> 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...

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

[Gregory Heytings via Emacs development discussions.]

>>> 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.

on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-12 11:51]:
> 
> > > > 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.

Helm does not offer minibuffer with vertical completions. Please
observe it again. Helm offers completion. It is related to minibuffer,
but it is not minibuffer with verticla completion. Maybe there is such
option, but it is not there by default which is good thing.

If development of icomplete leans on that misunderstanding then I
recommend reading helm's general concepts:

https://github.com/emacs-helm/helm/wiki

Quote:

People often think helm is just something like ido but displaying
completion in a vertical layout instead of an horizontal one, it is
not, helm is much more powerful than that.

- Helm is able to complete multiple lists dispatched in different
  sources against a pattern.
  
- Helm allows executing an unlimited number of actions on candidates.

- Helm allows marking candidates to execute chosen action against this
  set of candidates.
  
- Helm can display its completion buffer in different window layouts
  and in separate frame.

Read more:

Helm Completion v.s. Emacs Completion

Differences between the two often trip up new users.

Emacs completion is based on the minibuffer. Helm completion is based
on the completion window.

Commentary: The last sentence above declares why it is useful. It does
not rip apart user's interface. Please consider when enlarging
minibuffer that you are already "splitting the window", maybe not
technically but practically as the modeline jumps up. So if you are
already splitting window practically and visibly then you can as well
leave modeline down where it was and do the same and lean on that good
principle of helm completion.

More from helm:

In default Emacs, interactivity happens in the minibuffer.

    Typing new characters filters candidates in the minibuffer.
        <tab> may try to complete the typed characters with a valid candidate.
    Hitting RET selects the current candidate from the minibuffer.

In Helm, interactivity happens in the completion window, not the minibuffer

    Typing new characters filters candidates in the completion window.
        Type until the desired candidate is highlighted, or navigate to it using C-n.
    Hitting RET selects the currently highlighted item in the completion window.


Helm interaction model

Helm’s interactivity makes the <tab> key redundant for completion because the selection candidates are already made visible in the Helm completion window. So, tab completion is not supported. In Helm, <tab> is used to view available actions to be taken on a candidate.

Because the <tab> key is so ingrained in the muscle memory of long-time Emacs users, transition to Helm’s interactive model requires:

    A conscious visual adjustment to look at the completion window, and
    A conscious mental adjustment to avoid using the <tab> key for completion and go straight to <RET> key to select a candidate. Helm’s approach to completion provides better visual cues, takes fewer keystrokes, and is much faster.

Commentary: there is reason why is helm most useful package around for
completion. Those are fundamental concepts it was built on. And I hope
to see those more inside of Emacs.

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Gregory Heytings via Emacs development discussions.]

>> 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.
>
> Helm does not offer minibuffer with vertical completions.
>

I know.  But for the purpose of _this_ discussion (prettyness of a 
vertical presentation of completion candidates by Emacs compared to other 
software) what it does is the same.

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-12 12:20]:
> 
> > > 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.
> > 
> > Helm does not offer minibuffer with vertical completions.
> > 
> 
> I know.  But for the purpose of _this_ discussion (prettyness of a vertical
> presentation of completion candidates by Emacs compared to other software)
> what it does is the same.

icomplete vertical completion is not same to helm completion.

Maybe you did not see or did not observe the difference which is to me
very substantial.

I wish icomplete would be in that sense same to helm, but it is not. I
am asking if it can be made, please if possible. It would be alright
to me if bounties can be made and accepted for work. There is nothing
wrong in supporting people with donations.

Features wanted in ivy or icomplete or anything inside of Emacs or in
GNU ELPA:

- full frame completion with mode line staying where it is

- split window completion as helm does it, with mode line staying
  where it should be

My purpose is to possibly benefit people who will be doing researches
and projects. And that is one of fundamental functions.

It need not be implemented as "minibuffer completion", not at all. It
can be implementd any how. Small buffer for completions can as well
appear on the top of the window while real time displaying and
narrowing is shown below.

I also prefer tabulated-list-mode to have the feature to narrow or
filter lines:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44550

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Gregory Heytings via Emacs development discussions.]

>>>> 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.
>>>
>>> Helm does not offer minibuffer with vertical completions.
>>
>> I know.  But for the purpose of _this_ discussion (prettyness of a 
>> vertical presentation of completion candidates by Emacs compared to 
>> other software) what it does is the same.
>
> icomplete vertical completion is not same to helm completion.
>
> Maybe you did not see or did not observe the difference which is to me 
> very substantial.
>

I'll say it again: I know that they are different.  But for the purpose of 
_this_ discussion, which is about the _visual prettyness_ of a vertical 
presentation of completion candidates compared to other software (and 
therefore _not_ about what you can _do_ / how you can _interact_ with that 
completion candidates list).  And from that viewpoint Helm and Ivy are 
similar: both display completion candidates vertically at the bottom of 
the frame.  Or at least I do not see how one could say that Helm is 
_visually pretty_ and Ivy is not (or the other way around).

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Jean Louis]

[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]

* Gregory Heytings <ghe@sdf.org> [2020-11-12 13:54]:
> 
> > > > > 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.
> > > > 
> > > > Helm does not offer minibuffer with vertical completions.
> > > 
> > > I know.  But for the purpose of _this_ discussion (prettyness of a
> > > vertical presentation of completion candidates by Emacs compared to
> > > other software) what it does is the same.
> > 
> > icomplete vertical completion is not same to helm completion.
> > 
> > Maybe you did not see or did not observe the difference which is to me
> > very substantial.
> > 
> 
> I'll say it again: I know that they are different.  But for the purpose of
> _this_ discussion, which is about the _visual prettyness_ of a vertical
> presentation of completion candidates compared to other software (and
> therefore _not_ about what you can _do_ / how you can _interact_ with that
> completion candidates list).  And from that viewpoint Helm and Ivy are
> similar: both display completion candidates vertically at the bottom of the
> frame.  Or at least I do not see how one could say that Helm is _visually
> pretty_ and Ivy is not (or the other way around).

You may see that if you compare various functions by observing it and
turning off the ideas or preconceptions that you are trained
to. Forget everything, then observe it again.

You may have artists as friends, just find one and ask him what is
difference. Let people observe it for 5 minutes and find differences.

To help in observation there are 5 pictures attached in this email.

Initial condition is picture 01-split-window-before-completion.png
where it is shown with the frame split in two windows. I am searching
in the top window and pressing / to enter into completion feature.

When helm-mode is enabled:

- bottom window is used for completion

- windows do not get disturbed, none is enlarging or disturbing me as
  user

- minibuffer stays mini, does not expand

Compare that to following picture:
03-ivy-disturbes-all-screen-by-default.png when I use default ivy-mode:

- minibuffer expands disturbing all the screen

- bottom split window is shown but is useless. If it is to be
  disturbed then don't show it to me at all. I think but I may be
  wrong, that icomplete works this way last time I tested it.

- minibuffer is not any more there! How should I teach my stuff that
  they have certain control with minibuffer which is normally at
  bottom. I teach my staff by sending them Tutorial to do and info
  files to read. 

- It did expand but it expands too much. It disturbs even the initial
  condition of how windows were split. So it is minimizing my top
  window for the sake of completion. Do I really want that? No. All
  these commentaries are not to make anybody bad, they are for
  thinking and observations when designing these completions.

Better behavior for ivy is on picture:
04-ivy-with-outside-function-enlarges-bottom-window.png

When I use outside function which is not yet in ivy, then at least:

- I get more visibility on the top window

- bottom window is not even visible, I am fine with it so far as I
  complete in the upper window. That bottom window could be very
  necessary for completion is also true but I prefer having cleaner
  screen rather then messed up screen.

- minibuffer remains mini with this outside enhancement to ivy. This
  way I do not think that jumping minibuffer represents the mode line
  for the top window. That really creates confusions.

On picture: 05-selectrum-after-split-window-behaving-better.png I am
also showing Selectrum package that also behaves badly in relation to
interface. After some talk with developers one at least made
enhancements in a separate branch, so Selectrum now behaves with such
non-official enhancement as good as helm:

- minibuffer remains mini

- bottom window is replaced temporary with selections

- window sizes do not get disturbed


[-- Attachment #2: 01-split-window-before-completion.png --]
[-- Type: image/png, Size: 120713 bytes --]

[-- Attachment #3: 02-helm-replaces-bottom-split-window-correctly.png --]
[-- Type: image/png, Size: 110380 bytes --]

[-- Attachment #4: 03-ivy-disturbes-all-screen-by-default.png --]
[-- Type: image/png, Size: 107927 bytes --]

[-- Attachment #5: 04-ivy-with-outside-function-enlarges-bottom-window.png --]
[-- Type: image/png, Size: 116076 bytes --]

[-- Attachment #6: 05-selectrum-after-split-window-behaving-better.png --]
[-- Type: image/png, Size: 92691 bytes --]

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Gregory Heytings via Emacs development discussions.]

>
> Compare that to following picture: 
> 03-ivy-disturbes-all-screen-by-default.png when I use default ivy-mode:
>
> - minibuffer expands disturbing all the screen
>
> - bottom split window is shown but is useless. If it is to be disturbed 
> then don't show it to me at all. I think but I may be wrong, that 
> icomplete works this way last time I tested it.
>
> - minibuffer is not any more there! How should I teach my stuff that 
> they have certain control with minibuffer which is normally at bottom. I 
> teach my staff by sending them Tutorial to do and info files to read.
>
> - It did expand but it expands too much. It disturbs even the initial 
> condition of how windows were split. So it is minimizing my top window 
> for the sake of completion. Do I really want that? No. All these 
> commentaries are not to make anybody bad, they are for thinking and 
> observations when designing these completions.
>

These problems are orthogonal to the way completion candidates are 
displayed.  Given what you write, I'd suggest you to try to use 
ivy-posframe or emacs-mini-frame or emacs-maple-minibuffer, with which the 
existing windows are not "disturbed".

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Jean Louis]

* Gregory Heytings <ghe@sdf.org> [2020-11-12 17:40]:
> > - It did expand but it expands too much. It disturbs even the initial
> > condition of how windows were split. So it is minimizing my top window
> > for the sake of completion. Do I really want that? No. All these
> > commentaries are not to make anybody bad, they are for thinking and
> > observations when designing these completions.
> > 
> 
> These problems are orthogonal to the way completion candidates are
> displayed.  Given what you write, I'd suggest you to try to use ivy-posframe
> or emacs-mini-frame or emacs-maple-minibuffer, with which the existing
> windows are not "disturbed".

I know that I can use what is useful and outside of main Emacs. I know
that and I do. I am suggesting to make main Emacs more useful.

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Eli Zaretskii]

> Date: Thu, 12 Nov 2020 12:13:23 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Eli Zaretskii <eliz@gnu.org>, rudalics@gmx.at, spacibba@aol.com,
>   monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org
> 
> Emacs completion is based on the minibuffer. Helm completion is based
> on the completion window.

No, the default Emacs completion is also based on a separate window
showing the completion candidates in a special buffer *Completions*,
when there are more than one.  It is optional features like icomplete
and ivy that use the minibuffer for showing the completion candidates.

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-12 17:41]:
> > Date: Thu, 12 Nov 2020 12:13:23 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Eli Zaretskii <eliz@gnu.org>, rudalics@gmx.at, spacibba@aol.com,
> >   monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org
> > 
> > Emacs completion is based on the minibuffer. Helm completion is based
> > on the completion window.
> 
> No, the default Emacs completion is also based on a separate window
> showing the completion candidates in a special buffer *Completions*,
> when there are more than one.  It is optional features like icomplete
> and ivy that use the minibuffer for showing the completion candidates.

That sentence above is meant that completion in plain Emacs is taking
place in the minibuffer. Words are expanding in the minibuffer and
words are completed in the minibuffer.

That separate window, as separate and important subject, is opened
during completion process is great feature and I hope icomplete will
adopt it.

Helm completion does not complete in mini buffer. One can write
anything in the mini buffer so words are not expanding in the
minibuffer. Instead person is making choice in the separate window. I
hope you see that.

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator

[Eli Zaretskii]

> Date: Thu, 12 Nov 2020 20:49:18 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: ghe@sdf.org, rudalics@gmx.at, spacibba@aol.com,
>   monnier@iro.umontreal.ca, andreyk.mad@gmail.com, emacs-devel@gnu.org
> 
> That separate window, as separate and important subject, is opened
> during completion process is great feature and I hope icomplete will
> adopt it.

I very much doubt that icomplete will do it, because it goes against
its design principles.

> Helm completion does not complete in mini buffer. One can write
> anything in the mini buffer so words are not expanding in the
> minibuffer. Instead person is making choice in the separate window. I
> hope you see that.

Granted, I do see it, I just think that this is not the Emacs
look-and-feel I'm accustomed to, this is utterly different.  If you
are lobbying for this to become the default, be prepared for an uphill
battle, because it calls for a totally different typing methods, and I
expect many old-timers to dislike the difference.

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

[Eli Zaretskii]

> 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?

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

[Gregory Heytings via Emacs development discussions.]

[-- 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 --]

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

[-- 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 --]

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>
> 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.

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>
> 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.

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

[Eli Zaretskii]

> 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.

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

[Stephen Berman]

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

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

[Eli Zaretskii]

> 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.

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

[Stephen Berman]

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

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

[Gregory Heytings via Emacs development discussions.]

>>> 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.

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>
> 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.

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

[martin rudalics]

 > 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

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

[Gregory Heytings via Emacs development discussions.]

>> 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.

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

[Eli Zaretskii]

> 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.

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

[Dmitry Gutov]

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.

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

[Howard Melman]

[-- 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

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

[Jean Louis]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

* Howard Melman <hmelman@gmail.com> [2020-11-12 22:33]:
> 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?

That is right, people have to try it out.

ivy-posframe is useful for me. It also demonstrates that minibuffer is
just one way of selecting, there can be various ways of selecting.

For me is more logical to watch in the middle of screen for
selections. Not on the bottom and not on pure top. Middle is just
fine.

I do it as it was already decided by design of Emacs that way.

ivy-posframe will not work on console. It is good for X.

> 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

Thank you for references. It looks fancy and useful for the purposes I
have here to show additional information related to hyperlinks (which
are not necessarily WWW hyperlinks).

[-- Attachment #2: Screenshot from 2020-11-12 22-53-40.png --]
[-- Type: image/png, Size: 74072 bytes --]

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

[Jean Louis]

* 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".

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

[Eli Zaretskii]

> 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.

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

[Jean Louis]

* 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.

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

[Drew Adams]

> 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.

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

[martin rudalics]

 > 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

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

[Drew Adams]

>  > 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.

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

[martin rudalics]

 >> 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

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

[Drew Adams]

> that the command tells you what it does, and it's
> up to use whether you use it.
         ^
        you

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

[Eli Zaretskii]

> 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.

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

[Andrii Kolomoiets]

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!

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

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?

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>>> 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?

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

[Eli Zaretskii]

> 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).

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

[Gregory Heytings via Emacs development discussions.]

>>> 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.

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

[Eli Zaretskii]

> 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.

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

[Stefan Monnier]

> 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

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

[Eli Zaretskii]

> 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.

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

[Gregory Heytings via Emacs development discussions.]

>> 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.

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

[Stefan Monnier]

> 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))
 	{

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

[Andrii Kolomoiets]

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).".

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

[Gregory Heytings via Emacs development discussions.]

>>>> 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.

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

[Andrii Kolomoiets]

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!

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

[Ergus]

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

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

[Andrii Kolomoiets]

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.

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

[Ergus]

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?

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

[Andrii Kolomoiets]

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.

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

[Stefan Monnier]

> 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

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

[Jean Louis]

* 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?

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

[Andrii Kolomoiets]

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.

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

[Jean Louis]

* 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.

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

[Andrii Kolomoiets]

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.

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

[Jean Louis]

* 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.

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

[Drew Adams]

[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.)

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

[Drew Adams]

> 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.

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

[Drew Adams]

> 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.