Other details about completion.

Other details about completion.

[Ergus]

Hi all:

After some days using the new completion customs I have found some other
details that maybe could be `improved'.

1) When display-line-numbers is enabled the extra lines (help and
header) produce a mismatch between the line number and the current
candidate.

I know we can live with it... But... maybe there is a way to add a
padding or a property or anything that inhibits the display engine from
producing numbers for some lines or a line range... even if we restrict
it to only the beginning lines and internal use? I know there is some
code to do that with continuation lines...

2) Do we have a property or any way to make the commands in M-x to show
some help? Like the one shown when `completions-detailed` is non-nil in
`C-h f`?

Best,
Ergus

Re: Other details about completion.

[Eli Zaretskii]

> Date: Fri, 1 Apr 2022 17:38:39 +0200
> From: Ergus <spacibba@aol.com>
> 
> 1) When display-line-numbers is enabled the extra lines (help and
> header) produce a mismatch between the line number and the current
> candidate.
> 
> I know we can live with it... But... maybe there is a way to add a
> padding or a property or anything that inhibits the display engine from
> producing numbers for some lines or a line range... even if we restrict
> it to only the beginning lines and internal use? I know there is some
> code to do that with continuation lines...

Sorry, no.  display-line-numbers is a general-purpose feature that
counts lines of text in the buffer.  If some display wants to have
numbers for any other purpose, that display should produce its own
numbers, instead of relying on display-line-numbers, which aren't
meant to do any other job.

Re: Other details about completion.

[Juri Linkov]

> 2) Do we have a property or any way to make the commands in M-x to show
> some help? Like the one shown when `completions-detailed` is non-nil in
> `C-h f`?

M-x already shows some kind of help: key bindings and alias names.

Re: Other details about completion.

[Ergus]

On Fri, Apr 01, 2022 at 07:43:18PM +0300, Juri Linkov wrote:
>> 2) Do we have a property or any way to make the commands in M-x to show
>> some help? Like the one shown when `completions-detailed` is non-nil in
>> `C-h f`?
>
>M-x already shows some kind of help: key bindings and alias names.

Yes I know, But It may be useful to add a description line like in C-h f
<tab> for example...

[PATCH] Re: Other details about completion.

[Ergus]

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

Hi again...

Here I attached a small patch that makes 3 small changes:

1) Remove the trailing newline in completions one-column
2) Use another condition in next-completion to jump to minibuffer.

Normally next-completion with tabs at the end of the buffer needs an
extra tab because it goes to the end of the last completion before
jumping to the minibuffer or wrap.. That extra tab is because the
condition to jump or wrap was eobp/bobp assuming that there is not text
unproppertized after the last candidate.

3) Remove a comment in switch-to-completions. That comment suggested that
the next-completion action must be called inside
minibuffer-completion-help but IMO that is not totally correct when
completion-auto-select has some of the new values.

Please, if anyone could review,correct and push I would be very
grateful.

Best,
Ergus

[-- Attachment #2: next-completion.patch --]
[-- Type: text/plain, Size: 5880 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index d8df1799c9..5ad44a7a2d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2044,7 +2044,8 @@ completion--insert-one-column
               (when title
                 (insert (format completions-group-format title) "\n")))))
         (completion--insert str group-fun)
-        (insert "\n")))))
+        (insert "\n")))
+    (delete-char -1)))
 
 (defun completion--insert (str group-fun)
   (if (not (consp str))
diff --git a/lisp/simple.el b/lisp/simple.el
index c60abcb1f4..7918767a75 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9179,46 +9179,53 @@ next-completion
                 ((/= prev (point))
                  (point))
                 (t prev))))
-  (let ((beg (point-min)) (end (point-max)))
+
+  (let ((beg (point-min))
+        (end (point-max))
+        (tabcommand (member (this-command-keys) '("\t" [backtab])))
+        prop)
     (catch 'bound
       (while (> n 0)
         ;; If in a completion, move to the end of it.
         (when (get-text-property (point) 'mouse-face)
           (goto-char (next-single-property-change (point) 'mouse-face nil end)))
         ;; If at the last completion option, wrap or skip to the
-        ;; minibuffer, if requested.
-        (when (and completion-wrap-movement (eobp))
-          (if (and (member (this-command-keys) '("\t" [backtab]))
-                   completion-auto-select)
+        ;; minibuffer, if requested. We can't use (eobp) because some
+        ;; extra text may be after the last candidate: ex: when
+        ;; completion-detailed
+        (setq prop (next-single-property-change (point) 'mouse-face nil end))
+        (when (and completion-wrap-movement (eq end prop))
+          (if (and completion-auto-select tabcommand)
               (throw 'bound nil)
             (goto-char (point-min))))
         ;; Move to start of next one.
         (unless (get-text-property (point) 'mouse-face)
           (goto-char (next-single-property-change (point) 'mouse-face nil end)))
         (setq n (1- n)))
+
       (while (and (< n 0) (not (bobp)))
-        (let ((prop (get-text-property (1- (point)) 'mouse-face)))
-          ;; If in a completion, move to the start of it.
-          (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
-            (goto-char (previous-single-property-change
-                        (point) 'mouse-face nil beg)))
-          ;; Move to end of the previous completion.
-          (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
-            (goto-char (previous-single-property-change
-                        (point) 'mouse-face nil beg)))
-          ;; If at the first completion option, wrap or skip to the
-          ;; minibuffer, if requested.
-          (when (and completion-wrap-movement (bobp))
-            (if (and (member (this-command-keys) '("\t" [backtab]))
-                     completion-auto-select)
-                (progn
-                  (goto-char (next-single-property-change (point) 'mouse-face nil end))
-                  (throw 'bound nil))
-              (goto-char (point-max))))
-          ;; Move to the start of that one.
+        (setq prop (get-text-property (1- (point)) 'mouse-face))
+        ;; If in a completion, move to the start of it.
+        (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
           (goto-char (previous-single-property-change
-                      (point) 'mouse-face nil beg))
-          (setq n (1+ n)))))
+                      (point) 'mouse-face nil beg)))
+        ;; Move to end of the previous completion.
+        (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
+          (goto-char (previous-single-property-change
+                      (point) 'mouse-face nil beg)))
+        ;; If at the first completion option, wrap or skip to the
+        ;; minibuffer, if requested.
+        (setq prop (previous-single-property-change (point) 'mouse-face nil beg))
+        (when (and completion-wrap-movement (eq beg prop))
+          (if (and completion-auto-select tabcommand)
+              (progn
+                (goto-char (next-single-property-change (point) 'mouse-face nil end))
+                (throw 'bound nil))
+            (goto-char (point-max))))
+        ;; Move to the start of that one.
+        (goto-char (previous-single-property-change
+                    (point) 'mouse-face nil beg))
+        (setq n (1+ n))))
     (when (/= 0 n)
       (switch-to-minibuffer))))
 
@@ -9436,22 +9443,18 @@ completion-setup-function
 (defun switch-to-completions ()
   "Select the completion list window."
   (interactive)
-  (let ((window (or (get-buffer-window "*Completions*" 0)
-		    ;; Make sure we have a completions window.
-                    (progn (minibuffer-completion-help)
-                           (get-buffer-window "*Completions*" 0)))))
-    (when window
-      (select-window window)
+  (when-let ((window (or (get-buffer-window "*Completions*" 0)
+		         ;; Make sure we have a completions window.
+                         (progn (minibuffer-completion-help)
+                                (get-buffer-window "*Completions*" 0)))))
+    (select-window window)
+    (when (bobp)
       (cond
        ((and (memq this-command '(completion-at-point minibuffer-complete))
-             (equal (this-command-keys) [backtab])
-             (bobp))
+             (equal (this-command-keys) [backtab]))
         (goto-char (point-max))
         (previous-completion 1))
-       ;; In the new buffer, go to the first completion.
-       ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
-       ((bobp)
-        (next-completion 1))))))
+       (t (next-completion 1))))))
 
 (defun read-expression-switch-to-completions ()
   "Select the completion list window while reading an expression."

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> Hi again...
>
> Here I attached a small patch that makes 3 small changes:
>
> 1) Remove the trailing newline in completions one-column
> 2) Use another condition in next-completion to jump to minibuffer.
>
> Normally next-completion with tabs at the end of the buffer needs an
> extra tab because it goes to the end of the last completion before
> jumping to the minibuffer or wrap.. That extra tab is because the
> condition to jump or wrap was eobp/bobp assuming that there is not text
> unproppertized after the last candidate.
>
> 3) Remove a comment in switch-to-completions. That comment suggested that
> the next-completion action must be called inside
> minibuffer-completion-help but IMO that is not totally correct when
> completion-auto-select has some of the new values.
>
> Please, if anyone could review,correct and push I would be very
> grateful.

Do you mean that you fixed the problem reported in bug#54374?
I hope Philip could help to verify that your patch works
smoothly with the new features completion-auto-select
and completion-wrap-movement.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Sat, Apr 02, 2022 at 09:09:29PM +0300, Juri Linkov wrote:
>> Hi again...
>>
>> Here I attached a small patch that makes 3 small changes:
>>
>> 1) Remove the trailing newline in completions one-column
>> 2) Use another condition in next-completion to jump to minibuffer.
>>
>> Normally next-completion with tabs at the end of the buffer needs an
>> extra tab because it goes to the end of the last completion before
>> jumping to the minibuffer or wrap.. That extra tab is because the
>> condition to jump or wrap was eobp/bobp assuming that there is not text
>> unproppertized after the last candidate.
>>
>> 3) Remove a comment in switch-to-completions. That comment suggested that
>> the next-completion action must be called inside
>> minibuffer-completion-help but IMO that is not totally correct when
>> completion-auto-select has some of the new values.
>>
>> Please, if anyone could review,correct and push I would be very
>> grateful.
>
>Do you mean that you fixed the problem reported in bug#54374?
I have no idea about bug#54374 I will check when I have some time.

>I hope Philip could help to verify that your patch works
>smoothly with the new features completion-auto-select
>and completion-wrap-movement.
>
Actually I use both... completion-auto-select and
completion-wrap-movement

==========================================

What is annoying for me is that this behavior is limited to TAB and
backtab... I would like to have this same behavior for any interactive
call to next/previous-completion (for example when using arrows or
n/p). I tried this:

In simple.el I changed previous-completion for this:

(defun previous-completion (n)
   "Move to the previous item in the completion list.
With prefix argument N, move back N items (negative N means move
forward)."
   (interactive "p")
   (funcall-interactively next-completion (- n)))

And then in next-completion I changed:

(member (this-command-keys) '("\t" [backtab]))

for this:

(called-interactively-p 'any)

But the second one always return false when using
previous-completion... like ignoring the funcall-interactively... Is
this a issue or intended??

Alternatively I could use:

(memq this-command '(next-completion previous-completion))

But that may be like hiding the called-interactively-p issue under the
carpet if it is an issue.

Best,
Ergus.

Re: [PATCH] Re: Other details about completion.

[Ergus]

May I finally add this patch to master??

On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>Hi again...
>
>Here I attached a small patch that makes 3 small changes:
>
>1) Remove the trailing newline in completions one-column
>2) Use another condition in next-completion to jump to minibuffer.
>
>Normally next-completion with tabs at the end of the buffer needs an
>extra tab because it goes to the end of the last completion before
>jumping to the minibuffer or wrap.. That extra tab is because the
>condition to jump or wrap was eobp/bobp assuming that there is not text
>unproppertized after the last candidate.
>
>3) Remove a comment in switch-to-completions. That comment suggested that
>the next-completion action must be called inside
>minibuffer-completion-help but IMO that is not totally correct when
>completion-auto-select has some of the new values.
>
>Please, if anyone could review,correct and push I would be very
>grateful.
>
>Best,
>Ergus

>diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>index d8df1799c9..5ad44a7a2d 100644
>--- a/lisp/minibuffer.el
>+++ b/lisp/minibuffer.el
>@@ -2044,7 +2044,8 @@ completion--insert-one-column
>               (when title
>                 (insert (format completions-group-format title) "\n")))))
>         (completion--insert str group-fun)
>-        (insert "\n")))))
>+        (insert "\n")))
>+    (delete-char -1)))
>
> (defun completion--insert (str group-fun)
>   (if (not (consp str))
>diff --git a/lisp/simple.el b/lisp/simple.el
>index c60abcb1f4..7918767a75 100644
>--- a/lisp/simple.el
>+++ b/lisp/simple.el
>@@ -9179,46 +9179,53 @@ next-completion
>                 ((/= prev (point))
>                  (point))
>                 (t prev))))
>-  (let ((beg (point-min)) (end (point-max)))
>+
>+  (let ((beg (point-min))
>+        (end (point-max))
>+        (tabcommand (member (this-command-keys) '("\t" [backtab])))
>+        prop)
>     (catch 'bound
>       (while (> n 0)
>         ;; If in a completion, move to the end of it.
>         (when (get-text-property (point) 'mouse-face)
>           (goto-char (next-single-property-change (point) 'mouse-face nil end)))
>         ;; If at the last completion option, wrap or skip to the
>-        ;; minibuffer, if requested.
>-        (when (and completion-wrap-movement (eobp))
>-          (if (and (member (this-command-keys) '("\t" [backtab]))
>-                   completion-auto-select)
>+        ;; minibuffer, if requested. We can't use (eobp) because some
>+        ;; extra text may be after the last candidate: ex: when
>+        ;; completion-detailed
>+        (setq prop (next-single-property-change (point) 'mouse-face nil end))
>+        (when (and completion-wrap-movement (eq end prop))
>+          (if (and completion-auto-select tabcommand)
>               (throw 'bound nil)
>             (goto-char (point-min))))
>         ;; Move to start of next one.
>         (unless (get-text-property (point) 'mouse-face)
>           (goto-char (next-single-property-change (point) 'mouse-face nil end)))
>         (setq n (1- n)))
>+
>       (while (and (< n 0) (not (bobp)))
>-        (let ((prop (get-text-property (1- (point)) 'mouse-face)))
>-          ;; If in a completion, move to the start of it.
>-          (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
>-            (goto-char (previous-single-property-change
>-                        (point) 'mouse-face nil beg)))
>-          ;; Move to end of the previous completion.
>-          (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
>-            (goto-char (previous-single-property-change
>-                        (point) 'mouse-face nil beg)))
>-          ;; If at the first completion option, wrap or skip to the
>-          ;; minibuffer, if requested.
>-          (when (and completion-wrap-movement (bobp))
>-            (if (and (member (this-command-keys) '("\t" [backtab]))
>-                     completion-auto-select)
>-                (progn
>-                  (goto-char (next-single-property-change (point) 'mouse-face nil end))
>-                  (throw 'bound nil))
>-              (goto-char (point-max))))
>-          ;; Move to the start of that one.
>+        (setq prop (get-text-property (1- (point)) 'mouse-face))
>+        ;; If in a completion, move to the start of it.
>+        (when (and prop (eq prop (get-text-property (point) 'mouse-face)))
>           (goto-char (previous-single-property-change
>-                      (point) 'mouse-face nil beg))
>-          (setq n (1+ n)))))
>+                      (point) 'mouse-face nil beg)))
>+        ;; Move to end of the previous completion.
>+        (unless (or (bobp) (get-text-property (1- (point)) 'mouse-face))
>+          (goto-char (previous-single-property-change
>+                      (point) 'mouse-face nil beg)))
>+        ;; If at the first completion option, wrap or skip to the
>+        ;; minibuffer, if requested.
>+        (setq prop (previous-single-property-change (point) 'mouse-face nil beg))
>+        (when (and completion-wrap-movement (eq beg prop))
>+          (if (and completion-auto-select tabcommand)
>+              (progn
>+                (goto-char (next-single-property-change (point) 'mouse-face nil end))
>+                (throw 'bound nil))
>+            (goto-char (point-max))))
>+        ;; Move to the start of that one.
>+        (goto-char (previous-single-property-change
>+                    (point) 'mouse-face nil beg))
>+        (setq n (1+ n))))
>     (when (/= 0 n)
>       (switch-to-minibuffer))))
>
>@@ -9436,22 +9443,18 @@ completion-setup-function
> (defun switch-to-completions ()
>   "Select the completion list window."
>   (interactive)
>-  (let ((window (or (get-buffer-window "*Completions*" 0)
>-		    ;; Make sure we have a completions window.
>-                    (progn (minibuffer-completion-help)
>-                           (get-buffer-window "*Completions*" 0)))))
>-    (when window
>-      (select-window window)
>+  (when-let ((window (or (get-buffer-window "*Completions*" 0)
>+		         ;; Make sure we have a completions window.
>+                         (progn (minibuffer-completion-help)
>+                                (get-buffer-window "*Completions*" 0)))))
>+    (select-window window)
>+    (when (bobp)
>       (cond
>        ((and (memq this-command '(completion-at-point minibuffer-complete))
>-             (equal (this-command-keys) [backtab])
>-             (bobp))
>+             (equal (this-command-keys) [backtab]))
>         (goto-char (point-max))
>         (previous-completion 1))
>-       ;; In the new buffer, go to the first completion.
>-       ;; FIXME: Perhaps this should be done in `minibuffer-completion-help'.
>-       ((bobp)
>-        (next-completion 1))))))
>+       (t (next-completion 1))))))
>
> (defun read-expression-switch-to-completions ()
>   "Select the completion list window while reading an expression."

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> May I finally add this patch to master??

I don't know, maybe Philip has no time to review your patch?

> On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>>Hi again...
>>
>>Here I attached a small patch that makes 3 small changes:
>>
>>1) Remove the trailing newline in completions one-column
>>2) Use another condition in next-completion to jump to minibuffer.
>>
>>Normally next-completion with tabs at the end of the buffer needs an
>>extra tab because it goes to the end of the last completion before
>>jumping to the minibuffer or wrap.. That extra tab is because the
>>condition to jump or wrap was eobp/bobp assuming that there is not text
>>unproppertized after the last candidate.
>>
>>3) Remove a comment in switch-to-completions. That comment suggested that
>>the next-completion action must be called inside
>>minibuffer-completion-help but IMO that is not totally correct when
>>completion-auto-select has some of the new values.
>>
>>Please, if anyone could review,correct and push I would be very
>>grateful.

Re: [PATCH] Re: Other details about completion.

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>> May I finally add this patch to master??
>
> I don't know, maybe Philip has no time to review your patch?

Sorry about that (I was struck down with Corona for the last few days,
so I forgot to respond).  Either way, I don't have any objections
(beyond what was discussed in bug#54374 that it might be a good idea to
rethink that mouse-face approach in general -- but if change 2) solves
this then the issue isn't that urgent).

>> On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>>>Hi again...
>>>
>>>Here I attached a small patch that makes 3 small changes:
>>>
>>>1) Remove the trailing newline in completions one-column
>>>2) Use another condition in next-completion to jump to minibuffer.
>>>
>>>Normally next-completion with tabs at the end of the buffer needs an
>>>extra tab because it goes to the end of the last completion before
>>>jumping to the minibuffer or wrap.. That extra tab is because the
>>>condition to jump or wrap was eobp/bobp assuming that there is not text
>>>unproppertized after the last candidate.
>>>
>>>3) Remove a comment in switch-to-completions. That comment suggested that
>>>the next-completion action must be called inside
>>>minibuffer-completion-help but IMO that is not totally correct when
>>>completion-auto-select has some of the new values.
>>>
>>>Please, if anyone could review,correct and push I would be very
>>>grateful.

-- 
	Philip Kaludercic

Re: [PATCH] Re: Other details about completion.

[Ergus]

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

BTW Juri. Do you finally plan to add the mini-buffer navigate completions features?

On April 4, 2022 9:45:00 PM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>> May I finally add this patch to master??
>
>I don't know, maybe Philip has no time to review your patch?
>
>> On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>>>Hi again...
>>>
>>>Here I attached a small patch that makes 3 small changes:
>>>
>>>1) Remove the trailing newline in completions one-column
>>>2) Use another condition in next-completion to jump to minibuffer.
>>>
>>>Normally next-completion with tabs at the end of the buffer needs an
>>>extra tab because it goes to the end of the last completion before
>>>jumping to the minibuffer or wrap.. That extra tab is because the
>>>condition to jump or wrap was eobp/bobp assuming that there is not text
>>>unproppertized after the last candidate.
>>>
>>>3) Remove a comment in switch-to-completions. That comment suggested that
>>>the next-completion action must be called inside
>>>minibuffer-completion-help but IMO that is not totally correct when
>>>completion-auto-select has some of the new values.
>>>
>>>Please, if anyone could review,correct and push I would be very
>>>grateful.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2036 bytes --]

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Mon, Apr 04, 2022 at 08:31:24PM +0000, Philip Kaludercic wrote:
>Juri Linkov <juri@linkov.net> writes:
>
>>> May I finally add this patch to master??
>>
>> I don't know, maybe Philip has no time to review your patch?
>
>Sorry about that (I was struck down with Corona for the last few days,
>so I forgot to respond).  Either way, I don't have any objections
>(beyond what was discussed in bug#54374 that it might be a good idea to
>rethink that mouse-face approach in general -- 

I already thought on this; it may be possible t do so using other text
properties like intangible or similes so commands like next-completion
may even disapear or fully simplified; but it may affect some specific
use cases like using isearch in the buffer and I am pretty sure someone
will complain about that, so we end up with duplicated code to support a
custom to provide the legacy behavior... SO I am not sure it worth to
try that (sadly).

>but if change 2) solves
>this then the issue isn't that urgent).
>


>>> On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>>>>Hi again...
>>>>
>>>>Here I attached a small patch that makes 3 small changes:
>>>>
>>>>1) Remove the trailing newline in completions one-column
>>>>2) Use another condition in next-completion to jump to minibuffer.
>>>>
>>>>Normally next-completion with tabs at the end of the buffer needs an
>>>>extra tab because it goes to the end of the last completion before
>>>>jumping to the minibuffer or wrap.. That extra tab is because the
>>>>condition to jump or wrap was eobp/bobp assuming that there is not text
>>>>unproppertized after the last candidate.
>>>>
>>>>3) Remove a comment in switch-to-completions. That comment suggested that
>>>>the next-completion action must be called inside
>>>>minibuffer-completion-help but IMO that is not totally correct when
>>>>completion-auto-select has some of the new values.
>>>>
>>>>Please, if anyone could review,correct and push I would be very
>>>>grateful.
>
>-- 
>	Philip Kaludercic
>

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> BTW Juri. Do you finally plan to add the mini-buffer navigate completions
> features?

Now new minibuffer completion navigation commands are pushed to master.
Hope this change doesn't break all completion frameworks.

>     May I finally add this patch to master??
>
> I don't know, maybe Philip has no time to review your patch?
>
>         On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>
>             Hi again...
>
> Here I attached a small patch that makes 3 small changes:

I noticed that your patch broke some corner cases:
when using minibuffer completion navigation commands,
it fails to go to the previous completion at the top.
But since this is now in master, you can see it yourself.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Tue, Apr 05, 2022 at 10:22:11PM +0300, Juri Linkov wrote:
>> BTW Juri. Do you finally plan to add the mini-buffer navigate completions
>> features?
>
>Now new minibuffer completion navigation commands are pushed to master.
>Hope this change doesn't break all completion frameworks.
>
Hi Juri:

Thanks for this... Sadly after trying it for a while I find it very
uncomfortable. :( maybe we can do something to improve it please??

1) I think it is more intuitive to invert and use the M-S-<arrow>
minibuffer-choose-** and M-<arrow> for
minibuffer-{previous|next}-completion for not insert commands...

Alternatively (IMHO much better one):

Maybe you could consider to insert the candidate, but keep the cursor in
the same place and add a shadowed suffix after the cursor in the
minibuffer.  So M-<arrow> navigates, and inserts suffix but if the user
types a letter the suffix disappears and the letter is inserted in the
right place. In contrast if the user press RET, as the candidate is
already inserted the current behavior is unchanged.

2) The M-<up>/M-<down> is not intuitive when completions are not in
one-column format, and the M-<left>/M-<right> cannot be used because
they are already taken.. Do we have any other alternative? I think there
is a problem any way because 2d navigation with this is impossible...

3) I think that the bindings in the minibuffer must be enabled in the
completions buffer as well, otherwise it becomes unconfortable;
specially with completion-auto-select.

>>     May I finally add this patch to master??
>>
>> I don't know, maybe Philip has no time to review your patch?
>>
>>         On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:
>>
>>             Hi again...
>>
>> Here I attached a small patch that makes 3 small changes:
>
>I noticed that your patch broke some corner cases:
>when using minibuffer completion navigation commands,
>it fails to go to the previous completion at the top.
>But since this is now in master, you can see it yourself.
>
My patch can only affect the TAB and backtab commands (look at the if
condition)... So I don't see how it could affect you commands ;(... I
will give it a look tomorrow...

Best,
Ergus

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> Thanks for this... Sadly after trying it for a while I find it very
> uncomfortable. :( maybe we can do something to improve it please??

This is not surprising.  This explains why we still had no such feature
for a long time.  It's because there are too many different expectations
how it should work.  But maybe it would be possible to find a set of
customizable options that will cover most use cases.  As least we could try.

> 1) I think it is more intuitive to invert and use the M-S-<arrow>
> minibuffer-choose-** and M-<arrow> for
> minibuffer-{previous|next}-completion for not insert commands...

Easier to type M-<arrow> were intended as the primary way to use this feature.
Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.

> Alternatively (IMHO much better one):
>
> Maybe you could consider to insert the candidate, but keep the cursor in
> the same place and add a shadowed suffix after the cursor in the
> minibuffer.  So M-<arrow> navigates, and inserts suffix but if the user
> types a letter the suffix disappears and the letter is inserted in the
> right place. In contrast if the user press RET, as the candidate is
> already inserted the current behavior is unchanged.

Isn't this behavior too confusing?  When the suffix is shadowed,
do you think the user will have the clear idea what will happen
after typing RET?  How will it indicate that typing
a self-inserting character will delete the suffix?
Maybe better to activate the region over the suffix?
Then it will follow rules of delete-selection where
a self-inserting character is expected to remove the suffix region.

> 2) The M-<up>/M-<down> is not intuitive when completions are not in
> one-column format,

M-<up>/M-<down> could be rebound to call next-line in the
completions buffer.

> and the M-<left>/M-<right> cannot be used because
> they are already taken.. Do we have any other alternative?

Indeed, horizontal navigation is a problem since M-<left>/M-<right>
can't be used by default, only after enabling a new option.

> I think there is a problem any way because 2d navigation with this
> is impossible...

Why 2d navigation is impossible?  It's possible in the completions
buffer where <right> is next-completion, and <down> is next-line.

> 3) I think that the bindings in the minibuffer must be enabled in the
> completions buffer as well, otherwise it becomes unconfortable;
> specially with completion-auto-select.

Agreed, M-<up>/M-<down> can be bound in the completions buffer.
But what about M-<left>/M-<right> for not one-column format?

>>I noticed that your patch broke some corner cases:
>>when using minibuffer completion navigation commands,
>>it fails to go to the previous completion at the top.
>>But since this is now in master, you can see it yourself.
>
> My patch can only affect the TAB and backtab commands (look at the if
> condition)... So I don't see how it could affect you commands ;(... I
> will give it a look tomorrow...

Sorry, now I can't reproduce the previous problem, it seems to work fine,
except the problem reported in bug#54374.

Re: [PATCH] Re: Other details about completion.

[Lars Ingebrigtsen]

Ergus <spacibba@aol.com> writes:

> 1) I think it is more intuitive to invert and use the M-S-<arrow>
> minibuffer-choose-** and M-<arrow> for
> minibuffer-{previous|next}-completion for not insert commands...

I was a bit surprised at how M-<down> worked -- I had expected it to
work like M-S-<down> works, really.  But after using it a few times, I
think it the M-<down> action makes more ergonomic sense, so I'd rather
keep it the way Juri has it now.

> 2) The M-<up>/M-<down> is not intuitive when completions are not in
> one-column format, and the M-<left>/M-<right> cannot be used because
> they are already taken..

I agree with that -- I expected M-<down> to work on the visually
displayed completions, not the logical order.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Wed, Apr 06, 2022 at 10:35:36AM +0300, Juri Linkov wrote:
>> Thanks for this... Sadly after trying it for a while I find it very
>> uncomfortable. :( maybe we can do something to improve it please??
>
>This is not surprising.  This explains why we still had no such feature
>for a long time.  It's because there are too many different expectations
>how it should work.  But maybe it would be possible to find a set of
>customizable options that will cover most use cases.  As least we could try.
>
>> 1) I think it is more intuitive to invert and use the M-S-<arrow>
>> minibuffer-choose-** and M-<arrow> for
>> minibuffer-{previous|next}-completion for not insert commands...
>
>Easier to type M-<arrow> were intended as the primary way to use this feature.
I know, but such primary behavior is too intrusive IMO.

>Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.
Mi proposal (the suffix one) is basically to avoid the need of M-RET.

>> Alternatively (IMHO much better one):
>>
>> Maybe you could consider to insert the candidate, but keep the cursor in
>> the same place and add a shadowed suffix after the cursor in the
>> minibuffer.  So M-<arrow> navigates, and inserts suffix but if the user
>> types a letter the suffix disappears and the letter is inserted in the
>> right place. In contrast if the user press RET, as the candidate is
>> already inserted the current behavior is unchanged.
>
>Isn't this behavior too confusing?  When the suffix is shadowed,
>do you think the user will have the clear idea what will happen
>after typing RET?
I took the idea basically from some configs around for fish and zsh..

>How will it indicate that typing
>a self-inserting character will delete the suffix?
That's just an option. We could also enable a C-g like in default zsh:

som<tab> -> some
some<tab> -> Completion list with: `someone, something, sometime`.

There is a custom to auto-select the first candidate inmediately or
require a second tab... (similar to our completion auto-select
values...)

Whenever a candidate is selected, the prompt is completed (similar to
your code as now) but the list can be explored with the normal arrows
while it is visible.

The main difference is that the user may cancel at any time with C-g, so
the candidates list is automatically hidden BUT the prompt goes back to
`some` (not cleared as now); so the user can continue typing and <tab>
again.

If the user inserts a letter at any moment with the completion list
visible and a candidate selected, then the candidate is keep and the
letter inserted after a space.

`some<tab>o` will produce `someone  o`
`some<tab><C-g>o will produce `someo`

In any case you will see the full `someone` after the <tab> and the
whole list, so RET will finish the completion and a second RET will use
it...

We can simplify part of this behavior because the emacs minibuffer does
not use multicommands or multientries on a command like: command arg1
arg2 and so on... So RET could maybe complete and use as now...

But OTOH I will strongly recommend the C-g and arrow navigation
behavior... That could be maybe implemented with a set-transient-map...

> Maybe better to activate the region over the suffix?
>Then it will follow rules of delete-selection where
>a self-inserting character is expected to remove the suffix region.
>
>> 2) The M-<up>/M-<down> is not intuitive when completions are not in
>> one-column format,
>
>M-<up>/M-<down> could be rebound to call next-line in the
>completions buffer.
>
>> and the M-<left>/M-<right> cannot be used because
>> they are already taken.. Do we have any other alternative?
>
>Indeed, horizontal navigation is a problem since M-<left>/M-<right>
>can't be used by default, only after enabling a new option.
>
set-transient-map??

>> I think there is a problem any way because 2d navigation with this
>> is impossible...
>
>Why 2d navigation is impossible?  It's possible in the completions
>buffer where <right> is next-completion, and <down> is next-line.
>
Yes, but from minibuffer it will collide with one way or the other
right?

>> 3) I think that the bindings in the minibuffer must be enabled in the
>> completions buffer as well, otherwise it becomes unconfortable;
>> specially with completion-auto-select.
>
>Agreed, M-<up>/M-<down> can be bound in the completions buffer.
>But what about M-<left>/M-<right> for not one-column format?
>
This just confirms me that the initial approach implemented with a minor
mode (or using a set-transient-map) may be a solution.

>>>I noticed that your patch broke some corner cases:
>>>when using minibuffer completion navigation commands,
>>>it fails to go to the previous completion at the top.
>>>But since this is now in master, you can see it yourself.
>>
>> My patch can only affect the TAB and backtab commands (look at the if
>> condition)... So I don't see how it could affect you commands ;(... I
>> will give it a look tomorrow...
>
>Sorry, now I can't reproduce the previous problem, it seems to work fine,
>except the problem reported in bug#54374.

Best,
Ergus

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> 1) I think it is more intuitive to invert and use the M-S-<arrow>
>> minibuffer-choose-** and M-<arrow> for
>> minibuffer-{previous|next}-completion for not insert commands...
>
> I was a bit surprised at how M-<down> worked -- I had expected it to
> work like M-S-<down> works, really.  But after using it a few times, I
> think it the M-<down> action makes more ergonomic sense, so I'd rather
> keep it the way Juri has it now.

I'm still unsure which is better.  Maybe M-<down> should not be different
from M-<PgDown>?  One of them navigates by lines, and another by screenfuls.
But M-<down> inserts the current completion to the minibuffer,
whereas M-<PgDown> does not.  Or maybe M-<PgDown> should insert the
completion as well.

>> 2) The M-<up>/M-<down> is not intuitive when completions are not in
>> one-column format, and the M-<left>/M-<right> cannot be used because
>> they are already taken..
>
> I agree with that -- I expected M-<down> to work on the visually
> displayed completions, not the logical order.

Unfortunately, M-<left>/M-<right> can't be used for visual navigation
from the minibuffer.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

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

>>> 1) I think it is more intuitive to invert and use the M-S-<arrow>
>>> minibuffer-choose-** and M-<arrow> for
>>> minibuffer-{previous|next}-completion for not insert commands...
>>
>> Easier to type M-<arrow> were intended as the primary way to use this feature.
> I know, but such primary behavior is too intrusive IMO.
>
>> Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.
> Mi proposal (the suffix one) is basically to avoid the need of M-RET.

So your proposal is something in between.  Then maybe instead of two sets
of commands (that either insert the current completion or not) we could have
one set of commands bound to M-<up>/M-<down>, and a customizable option with
three values: insert, don't insert, use transient suffix.

> I took the idea basically from some configs around for fish and zsh..
> ...
> But OTOH I will strongly recommend the C-g and arrow navigation
> behavior... That could be maybe implemented with a set-transient-map...

What is also interesting to note is that even every web browser
uses own completion logic:

1. in Firefox: the suffix of the first completion is inserted to the
   address bar as the selected region, but <up>/<down> inserts
   the completion without selecting its suffix, like M-<up>/M-<down>
   currently does in Emacs.  One ESC closes the completions window,
   another ESC clears the address bar.

2. in Chromium: <up>/<down> inserts the completion without any selection,
   like M-<up>/M-<down> currently does in Emacs.  One ESC clears the
   inserted string, another ESC closes the completions window and clears
   the address bar.

>> But what about M-<left>/M-<right> for not one-column format?
>
> This just confirms me that the initial approach implemented with a minor
> mode (or using a set-transient-map) may be a solution.

We started with non-intrusive keybindings.  But indeed, more intrusive keys
should be enabled only depending on a new customizable option.

Here is the next patch that does this and allows using all arrow keys
only when the completions window is visible:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: completion-arrows.patch --]
[-- Type: text/x-diff, Size: 3073 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index ef52006501..bfc268b828 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9151,6 +9151,15 @@ delete-completion-window
       (if (get-buffer-window buf)
 	  (select-window (get-buffer-window buf))))))
 
+(defcustom completion-arrows nil
+  "Non-nil means to use arrows to browse completions from the minibuffer."
+  :type '(choice (const :tag "Don't use arrows" nil)
+                 (const :tag "Use arrows" t)
+                 (const :tag "Use arrows when completions window is visible"
+                        visible))
+  :version "29.1"
+  :group 'completion)
+
 (defcustom completion-wrap-movement t
   "Non-nil means to wrap around when selecting completion options.
 This affects the commands `next-completion' and
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index c79c5a7a5d..ff124e18e9 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2736,6 +2821,15 @@ completion-help-at-point
   (define-key map "\n" 'exit-minibuffer)
   (define-key map "\r" 'exit-minibuffer))
 
+(defun completion-arrows (binding)
+  `(menu-item
+    "" ,binding
+    :filter ,(lambda (cmd)
+               (when (or (eq completion-arrows t)
+                         (and (eq completion-arrows 'visible)
+                              (get-buffer-window "*Completions*" 0)))
+                 cmd))))
+
 (defvar-keymap minibuffer-local-completion-map
   :doc "Local keymap for minibuffer input with completion."
   :parent minibuffer-local-map
@@ -2749,6 +2843,12 @@ minibuffer-local-completion-map
   "<prior>"   #'switch-to-completions
   "M-v"       #'switch-to-completions
   "M-g M-c"   #'switch-to-completions
+
+  "<left>"    (completion-arrows 'minibuffer-previous-completion)
+  "<right>"   (completion-arrows 'minibuffer-next-completion)
+  "<up>"      (completion-arrows 'minibuffer-previous-line-completion)
+  "<down>"    (completion-arrows 'minibuffer-next-line-completion)
+
   "M-<up>"    #'minibuffer-choose-previous-completion
   "M-<down>"  #'minibuffer-choose-next-completion
   "M-S-<up>"   #'minibuffer-previous-completion
@@ -4372,6 +4472,22 @@ minibuffer-next-completion
       (setq-local cursor-face-highlight-nonselected-window t))
     (next-completion n)))
 
+(defun minibuffer-previous-line-completion (&optional n)
+  "Run `previous-line' from the minibuffer in its completions window."
+  (interactive "p")
+  (with-minibuffer-completions-window
+    (when completions-highlight-face
+      (setq-local cursor-face-highlight-nonselected-window t))
+    (forward-line (- n))))
+
+(defun minibuffer-next-line-completion (&optional n)
+  "Run `next-line' from the minibuffer in its completions window."
+  (interactive "p")
+  (with-minibuffer-completions-window
+    (when completions-highlight-face
+      (setq-local cursor-face-highlight-nonselected-window t))
+    (forward-line n)))
+
 (defun minibuffer-choose-previous-completion (&optional n)
   "Run `previous-completion' from the minibuffer in its completions window.
 Also insert the selected completion to the minibuffer."

RE: [External] : Re: [PATCH] Re: Other details about completion.

[Drew Adams]

You'll get there eventually...


1. Cycling highlights the current candidate and
puts it in the minibuffer, replacing whatever was
there - always.  (A key clears the minibuffer; a
key restores previous content.)

2. Cycling order & display order in *Completions*
(if shown) are always the same.  (You can change
the sort order anytime, on the fly.)

3. Options let you choose how to define the region
when cycling - positioning of point & mark wrt the
root that's being completed or the end/beginning
of minibuffer content (current candidate).

4. An option chooses how to handle the default
value for minibuffer reading: whether to insert
it, whether to show it in the prompt; and if
inserted, where to put the cursor and whether to
preselect the value as the active region (e.g.,
for `delete-selection-mode' action).


https://www.emacswiki.org/emacs/Icicles_-_Cycling_Completions

https://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-point-position-in-candidate

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Wed, Apr 06, 2022 at 07:48:40PM +0300, Juri Linkov wrote:
>>>> 1) I think it is more intuitive to invert and use the M-S-<arrow>
>>>> minibuffer-choose-** and M-<arrow> for
>>>> minibuffer-{previous|next}-completion for not insert commands...
>>>
>>> Easier to type M-<arrow> were intended as the primary way to use this feature.
>> I know, but such primary behavior is too intrusive IMO.
>>
>>> Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.
>> Mi proposal (the suffix one) is basically to avoid the need of M-RET.
>
>So your proposal is something in between.  Then maybe instead of two sets
>of commands (that either insert the current completion or not) we could have
>one set of commands bound to M-<up>/M-<down>, and a customizable option with
>three values: insert, don't insert, use transient suffix.
>
I would prefer something simpler even if we need to sacrifice some
functionality or customization...

>> I took the idea basically from some configs around for fish and zsh..
>> ...
>> But OTOH I will strongly recommend the C-g and arrow navigation
>> behavior... That could be maybe implemented with a set-transient-map...
>
>What is also interesting to note is that even every web browser
>uses own completion logic:
>
>1. in Firefox: the suffix of the first completion is inserted to the
>   address bar as the selected region, but <up>/<down> inserts
>   the completion without selecting its suffix, like M-<up>/M-<down>
>   currently does in Emacs.  One ESC closes the completions window,
>   another ESC clears the address bar.
>
>2. in Chromium: <up>/<down> inserts the completion without any selection,
>   like M-<up>/M-<down> currently does in Emacs.  One ESC clears the
>   inserted string, another ESC closes the completions window and clears
>   the address bar.
>
Yes but there are three key differences there: 

1) browsers show the completion list immediately (like icomplete and
it's family), so they don't require a tab to show the completion list or
any binding to jump to/exit the completions list either.

2) the browser completions are shown vertically only, so no horizontal
navigation is needed and not modifiers to the keys are needed either as
there is not any collision of bindings. With the plus that the user can
go to the initial prompt (without completions) just by moving to the
first candidate (up arrow)... so no applicable to us either.

3) The search they perform is on the history, so when the candidate is
unique it is inserted and selected, so easier to erase the suffix if
needed with backspace or insert at the end (right arrow).

In either case 1) there is not a two step to insert+execute 2) there are
not special bindings 3) There is an intuitive way to keep the
completions like it started (remove the suffix) either hiding or keeping
the completion window.

Maybe we must look more at the fish/zsh behaviors than browsers, because
browsers are too far from our infrastructure...

BTW: do we have any sort of history search based on the inserted text
like bash history-search-backward??

>>> But what about M-<left>/M-<right> for not one-column format?
>>
>> This just confirms me that the initial approach implemented with a minor
>> mode (or using a set-transient-map) may be a solution.
>
>We started with non-intrusive keybindings.  But indeed, more intrusive keys
>should be enabled only depending on a new customizable option.
>

>Here is the next patch that does this and allows using all arrow keys
>only when the completions window is visible:
>
I will try this and comment, thanks!!

Best

Re: [PATCH] Re: Other details about completion.

[Ergus]

>
>Here is the next patch that does this and allows using all arrow keys
>only when the completions window is visible:
>

Ok quick check :)

With the new option the behavior gives a much better navigation.

1) There is still the issue with C-g or ESC canceling everything

2) In tabular navigation the down arrow always goes to the first column
which is wrong; maybe it should use next-line or line-move instead of
forward-line?

3) It still needs and extra binding to insert and then to another
execute... RET just removes the highlight and nothing else... which is
un-intuitive because the candidate in principle is already selected.

I am not a good lisper, but I think that an approach with a minor mode
or a transient-map could end up being simpler and more modular without
adding more complexity in the existing code... WDYT?

Best,
And thanks again
Ergus

Re: [External] : Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> You'll get there eventually...
>
> 1. Cycling highlights the current candidate and
> puts it in the minibuffer, replacing whatever was
> there - always.

Thanks, this means by default it could insert the current candidate.

> (A key clears the minibuffer; a key restores previous content.)

I wonder why a special key to clear the minibuffer
when it's easy to type 'C-a C-k' or 'M-h DEL'.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> Yes but there are three key differences there: 1) browsers show the
> completion list immediately (like icomplete and
> it's family), so they don't require a tab to show the completion list or
> any binding to jump to/exit the completions list either.

We could add a new variable or a new value to completion-auto-help
to show the completions buffer on any edit.

> 2) the browser completions are shown vertically only, so no horizontal
> navigation is needed and not modifiers to the keys are needed either as
> there is not any collision of bindings.

<M-left> and <M-right> can be activated in the minibuffer only
when the completions buffer shows more than 1 column.  Maybe
there is already a variable to detect this situation?

> 3) The search they perform is on the history, so when the candidate is
> unique it is inserted and selected, so easier to erase the suffix if
> needed with backspace or insert at the end (right arrow).

This is not what I see, candidates are not selected.
Maybe you use other browsers versions.

> BTW: do we have any sort of history search based on the inserted text
> like bash history-search-backward??

It's just 'C-r C-w' in the minibuffer.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>>Here is the next patch that does this and allows using all arrow keys
>>only when the completions window is visible:
>
> Ok quick check :)
>
> With the new option the behavior gives a much better navigation.
>
> 1) There is still the issue with C-g or ESC canceling everything

Do you mean addition step is needed where first C-g/ESC will clear
the suffix, then another C-g/ESC will exit the minibuffer?

> 2) In tabular navigation the down arrow always goes to the first column
> which is wrong; maybe it should use next-line or line-move instead of
> forward-line?

This is what I tried first, but byte-compiler complained next-line
is only for interactive use.

> 3) It still needs and extra binding to insert and then to another
> execute... RET just removes the highlight and nothing else... which is
> un-intuitive because the candidate in principle is already selected.

Then it should always insert the selected candidate.

> I am not a good lisper, but I think that an approach with a minor mode
> or a transient-map could end up being simpler and more modular without
> adding more complexity in the existing code... WDYT?

A minor mode that adds a hook to minibuffer-setup-hook
that activates another mode with additional keymap?
Looks more complex.  And a transient-map on post-command-hook
is even more complicated.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On April 6, 2022 8:29:13 PM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>> Yes but there are three key differences there: 1) browsers show the
>> completion list immediately (like icomplete and
>> it's family), so they don't require a tab to show the completion list or
>> any binding to jump to/exit the completions list either.
>
>We could add a new variable or a new value to completion-auto-help
>to show the completions buffer on any edit.
>
This will be very complex to do with the current infrastructure. Not for the show, but for the update. I wanted to do it and it required too many changes here and there... Maybe you find a better way.

Any way.. IMHO I think that going in that direction is a bad and more complex approach. For such behavior it may be better to use icomplete and similes...

I would be fine if we mimic zsh or fish, and let the browser like behavior to other completion infrastructures...

>> 2) the browser completions are shown vertically only, so no horizontal
>> navigation is needed and not modifiers to the keys are needed either as
>> there is not any collision of bindings.
>
><M-left> and <M-right> can be activated in the minibuffer only
>when the completions buffer shows more than 1 column.  Maybe
>there is already a variable to detect this situation?
>
I don't think there is anything for that yet... Let's rethink first what we really need.

>> 3) The search they perform is on the history, so when the candidate is
>> unique it is inserted and selected, so easier to erase the suffix if
>> needed with backspace or insert at the end (right arrow).
>
>This is not what I see, candidates are not selected.
>Maybe you use other browsers versions.
>
In my browser I can type and the list is updated; then the arrow down selects, but if I go up with the arrow at some point it goes to the top and disables the extra completion...

>> BTW: do we have any sort of history search based on the inserted text
>> like bash history-search-backward??
>
>It's just 'C-r C-w' in the minibuffer.

Ohh lord

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

RE: [External] : Re: [PATCH] Re: Other details about completion.

[Drew Adams]

> > 1. Cycling highlights the current candidate and
> > puts it in the minibuffer, replacing whatever was
> > there - always.
> 
> Thanks, this means by default it could insert the current candidate.

There's no "current" candidate till you cycle (or
otherwise select a candidate).

> > (A key clears the minibuffer; and
> >  a key restores previous content.)
> 
> I wonder why a special key to clear the minibuffer
> when it's easy to type 'C-a C-k' or 'M-h DEL'.


(This is independent of _completion_, BTW - it's
about any minibuffer.)


1. Neither `C-a C-k' nor `M-h DEL' clears all
minibuffer content, which can be anything, including
any number of lines of text.  `C-a C-k' clears only
the current line.  And `M-h DEL' clears only the
paragraph before point.

(A more useful command for removing a bunch of
minibuffer text, but not necessarily all, is
`backward-kill-sexp' - e.g., `C-M-backspace'.)


2. Clearing the minibuffer is very frequent,
especially when various other minibuffer-content
manipulations are added to the mix.

In particular, Icicles has multi-commands, where a
single command invocation can invoke the command
(or carry out other actions) on multiple completion
candidates.  So it's not unusual to stay in the
minibuffer, performing different editing operations,
including changing the current input to complete
against different sets or kinds of candidates.

Similarly, for progressive completion, where you
complete against a set of completions using
different patterns, progressively narrowing the set. 


3. `M-S-delete' and `M-S-backspace' clear the
minibuffer.  But `M-k' is what you usually use.

It too clears the minibuffer content.  But if you're
currently using (e.g. cycling) a minibuffer history,
it deletes the current history element.

[There's also `M-K', which prompts you for history
entries to delete, or with `C-u' deletes the whole
history (current history variable).]


4. As for keys restoring previous minibuffer content:

a. `C-l' restores last minibuffer input (repeatable).

This includes text you _entered_ (e.g. with `RET'),
i.e., what's in a minibuffer history.

But it also includes input you type in the minibuffer
during completion, but that you don't enter (`RET').

It includes candidates you've cycled and text you've
typed or deleted in the minibuffer - e.g., editing of
a candidate you cycled into the minibuffer.

Editing remembers what's in the minibuffer as your
last real "input".  If you want to replace a cycled
candidate and go back to editing the input you had
typed before cycling, use `C-l' (instead of just
deleting chars from the cycled candidate).

Input you type during completion but you don't enter
(e.g. `RET') is remembered because you might want to
retrieve it.  This can be because you cycled among
candidates or because completing has expanded your
input in some way.

[By default, your input is automatically to the
_common match_ among all matching candidates.  You
can use `C-l' to remove that expansion, leaving just
what completion of a single (the current) candidate
produces.]

For example, suppose you use `C-h v hook' to examine
various hook variables, and you use cycle through
their doc (e.g. `C-down').  If you end the command
with `C-g', so your input (`hook') is never really
entered (`RET'), then it's not in the minibuffer
history (e.g. `M-p').  Nevertheless, in a subsequent
command you can retrieve it - with `C-l'.

b. `C-L' (aka `C-S-l') does the same as `C-l', but
with reverse chronology.

c. An option lets `C-l' and `C-L' use completion,
instead of cycling, to retrieve a past input (in the
sense above).  Just as with cycling with these keys,
a previous input replaces the minibuffer content.
This uses a recursive minibuffer, so you can cancel
it with `C-g'.  (`C-l' or `C-L' with a prefix arg
flips cycling vs completion.)
 

Re: [PATCH] Re: Other details about completion.

[Ergus]

On April 6, 2022 8:34:12 PM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>>>Here is the next patch that does this and allows using all arrow keys
>>>only when the completions window is visible:
>>
>> Ok quick check :)
>>
>> With the new option the behavior gives a much better navigation.
>>
>> 1) There is still the issue with C-g or ESC canceling everything
>
>Do you mean addition step is needed where first C-g/ESC will clear
>the suffix, then another C-g/ESC will exit the minibuffer?
>
We need a simple handy way to restore the mini-buffer as it was before the navigation attempt...


Maybe, let's look more at zsh and similes... That's already tested to be intuitive so we don't need to reinvent the wheel and their users already know.


>> 2) In tabular navigation the down arrow always goes to the first column
>> which is wrong; maybe it should use next-line or line-move instead of
>> forward-line?
>
>This is what I tried first, but byte-compiler complained next-line
>is only for interactive use.
>
Then it should probably be line-move but forward-line goes to column zero.

>> 3) It still needs and extra binding to insert and then to another
>> execute... RET just removes the highlight and nothing else... which is
>> un-intuitive because the candidate in principle is already selected.
>
>Then it should always insert the selected candidate.
>
At the end I think that I will stay with completion-auto-select second-tab+ completion-auto-help visible... It is closer to my desired behavior as is. There are just some missing details probably I will try to solve step by step if they become annoying enough.

I don't like that this is getting complex and full of customs and variants that will be hard to support in the future... I would recommend to revert all this changes from master and move them to a branch untill we clarify what we want and what is possible to implement cleanly .

>> I am not a good lisper, but I think that an approach with a minor mode
>> or a transient-map could end up being simpler and more modular without
>> adding more complexity in the existing code... WDYT?
>
>A minor mode that adds a hook to minibuffer-setup-hook
>that activates another mode with additional keymap?
>Looks more complex.  And a transient-map on post-command-hook
>is even more complicated.

But mixing all these bindings behaviors and features all together is something that will break sonner than later. And the hybrid behavior will end up not being good enough for user who want a zsh experience and will bother the ones who don't.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Wed, Apr 06, 2022 at 09:29:13PM +0300, Juri Linkov wrote:
>> BTW: do we have any sort of history search based on the inserted text
>> like bash history-search-backward??
>
>It's just 'C-r C-w' in the minibuffer.
>
Just in case:

Reading the code I found two functions in simple.el not documented in
the manual:

next-complete-history-element and previous-complete-history-element

They are undocumented and I didn't find any reference to them in the
Emacs manual, but so far they do what I asked for; so I finally did
this:

(keymap-set minibuffer-local-map "<down>" #'next-complete-history-element)
(keymap-set minibuffer-local-map "<up>" #'previous-complete-history-element)

Which gives a better experience than the default to complete from
history. As I said: `like bash history-search-backward`

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> We could add a new variable or a new value to completion-auto-help
>> to show the completions buffer on any edit.
>
> This will be very complex to do with the current infrastructure.  Not
> for the show, but for the update.  I wanted to do it and it required
> too many changes here and there... Maybe you find a better way.
>
> Any way.. IMHO I think that going in that direction is a bad and more
> complex approach.  For such behavior it may be better to use
> icomplete and similes...

icomplete is based on post-command-hook, so zcomplete would need it too.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> Do you mean addition step is needed where first C-g/ESC will clear
>> the suffix, then another C-g/ESC will exit the minibuffer?
>
> We need a simple handy way to restore the mini-buffer as it was before
> the navigation attempt...
>
> Maybe, let's look more at zsh and similes... That's already tested to
> be intuitive so we don't need to reinvent the wheel and their users
> already know.

C-g in the completions buffer closes the completions window,
then the second C-g in the minibuffer exits the minibuffer.

So C-g in the minibuffer could be two-step as well:
first C-g closes the completions window and clears the suffix,
second C-g exits the minibuffer.

>>> 2) In tabular navigation the down arrow always goes to the first column
>>> which is wrong; maybe it should use next-line or line-move instead of
>>> forward-line?
>>
>> This is what I tried first, but byte-compiler complained next-line
>> is only for interactive use.
>
> Then it should probably be line-move but forward-line goes to column zero.

Neither of them wraps to the beginning like next-completion does.
This means we need a new command next-completion-vertical.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 10:39:16AM +0300, Juri Linkov wrote:
>>> Do you mean addition step is needed where first C-g/ESC will clear
>>> the suffix, then another C-g/ESC will exit the minibuffer?
>>
>> We need a simple handy way to restore the mini-buffer as it was before
>> the navigation attempt...
>>
>> Maybe, let's look more at zsh and similes... That's already tested to
>> be intuitive so we don't need to reinvent the wheel and their users
>> already know.
>
>C-g in the completions buffer closes the completions window,
>then the second C-g in the minibuffer exits the minibuffer.
>
>So C-g in the minibuffer could be two-step as well:
>first C-g closes the completions window and clears the suffix,
>second C-g exits the minibuffer.
>
The most I go into this the most convinced I get that
completion-auto-select and selecting the Completions windows is the
simplest and cleaner way to go.

>>>> 2) In tabular navigation the down arrow always goes to the first column
>>>> which is wrong; maybe it should use next-line or line-move instead of
>>>> forward-line?
>>>
>>> This is what I tried first, but byte-compiler complained next-line
>>> is only for interactive use.
>>
>> Then it should probably be line-move but forward-line goes to column zero.
>
>Neither of them wraps to the beginning like next-completion does.

The wrap behavior is only set for tab and backtab commands (yes, it is
hardcoded there... don't blame me) not even for all next-completion
uses. I prefer not to touch that code anymore or add more stuff
there... At some point we will decide to fix/replace the mouse-face
approach there and all this will be a nightmare to support the legacy
behavior. 

>This means we need a new command next-completion-vertical.

I already tried that in the first version of zcomplete I did long time
ago. And you said (and I agreed) that it was too complicated.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 10:35:24AM +0300, Juri Linkov wrote:
>>> We could add a new variable or a new value to completion-auto-help
>>> to show the completions buffer on any edit.
>>
>> This will be very complex to do with the current infrastructure.  Not
>> for the show, but for the update.  I wanted to do it and it required
>> too many changes here and there... Maybe you find a better way.
>>
>> Any way.. IMHO I think that going in that direction is a bad and more
>> complex approach.  For such behavior it may be better to use
>> icomplete and similes...
>
>icomplete is based on post-command-hook, so zcomplete would need it too.
>
Sorry, not agree here. If zcomplete intention is to emulate the zsh
behavior then it is not needed to use post-command-hook. Completions are
shown on demand <tab>... post-command-hook is for a behavior more like
browsers... We already have helm, ivy, icomplete, vertico, selectrum,
ido, fido (with the vertical variants too) and all the others... I don't
think we need more of that and reinvent the well once again.

Simple in better than complicated ;)

Re: [PATCH] Re: Other details about completion.

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I'm still unsure which is better.  Maybe M-<down> should not be different
> from M-<PgDown>?  One of them navigates by lines, and another by screenfuls.
> But M-<down> inserts the current completion to the minibuffer,
> whereas M-<PgDown> does not.  Or maybe M-<PgDown> should insert the
> completion as well.

Having M-<PgDown> insert the completion, too, would be sorta more
consistent.  But it doesn't feel natural.  Playing around a bit with the
current key bindings you have now, the actions feel quite natural to me.

>>> 2) The M-<up>/M-<down> is not intuitive when completions are not in
>>> one-column format, and the M-<left>/M-<right> cannot be used because
>>> they are already taken..
>>
>> I agree with that -- I expected M-<down> to work on the visually
>> displayed completions, not the logical order.
>
> Unfortunately, M-<left>/M-<right> can't be used for visual navigation
> from the minibuffer.

Yes, that's a problem.  And we can't rebind M-<left>/<right> there in
general, because it'd be disruptive.

Rebinding them after M-<down> might be an option?  But...  Probably not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>>>> 2) The M-<up>/M-<down> is not intuitive when completions are not in
>>>> one-column format, and the M-<left>/M-<right> cannot be used because
>>>> they are already taken..
>>>
>>> I agree with that -- I expected M-<down> to work on the visually
>>> displayed completions, not the logical order.
>>
>> Unfortunately, M-<left>/M-<right> can't be used for visual navigation
>> from the minibuffer.
>
> Yes, that's a problem.  And we can't rebind M-<left>/<right> there in
> general, because it'd be disruptive.
>
> Rebinding them after M-<down> might be an option?  But...  Probably not.

Why not, set-transient-map could activate M-<left>/<right> after M-<down>.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> So C-g in the minibuffer could be two-step as well:
>> first C-g closes the completions window and clears the suffix,
>> second C-g exits the minibuffer.
>
> The most I go into this the most convinced I get that
> completion-auto-select and selecting the Completions windows is the
> simplest and cleaner way to go.

Earlier you said that it should work like zsh.  But does zsh
really select the Completions window?  I see that typing a letter
while a completion candidate is highlighted in zsh, inserts both
the highlighted completion candidate and the letter.
This looks like it never leaves the command line
that corresponds to the minibuffer in Emacs.
So why do you think that switching to the Completions window
is required to select a completion candidate?

>>> Then it should probably be line-move but forward-line goes to column zero.
>>
>> Neither of them wraps to the beginning like next-completion does.
>
> The wrap behavior is only set for tab and backtab commands (yes, it is
> hardcoded there... don't blame me) not even for all next-completion
> uses. I prefer not to touch that code anymore or add more stuff
> there... At some point we will decide to fix/replace the mouse-face
> approach there and all this will be a nightmare to support the legacy
> behavior. >This means we need a new command next-completion-vertical.
>
> I already tried that in the first version of zcomplete I did long time
> ago. And you said (and I agreed) that it was too complicated.

But in zsh <up> and <down> wrap to the top/bottom of the same column.

Also in zsh TAB moves vertically when columns are sorted vertically.
Shouldn't TAB in Emacs move vertically too when 'completions-format'
is 'vertical'?

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> icomplete is based on post-command-hook, so zcomplete would need it too.
>
> Sorry, not agree here. If zcomplete intention is to emulate the zsh
> behavior then it is not needed to use post-command-hook. Completions are
> shown on demand <tab>... post-command-hook is for a behavior more like
> browsers... We already have helm, ivy, icomplete, vertico, selectrum,
> ido, fido (with the vertical variants too) and all the others... I don't
> think we need more of that and reinvent the well once again.
>
> Simple in better than complicated ;)

Earlier you suggested to add a new minor mode, but now you say
that a minor mode is complicated.  Isn't this a contradiction? ;)

And the same find-as-you-type autocompletion like in browsers
is supported by zsh as well:
https://github.com/marlonrichert/zsh-autocomplete

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 07:50:28PM +0300, Juri Linkov wrote:
>>> So C-g in the minibuffer could be two-step as well:
>>> first C-g closes the completions window and clears the suffix,
>>> second C-g exits the minibuffer.
>>
>> The most I go into this the most convinced I get that
>> completion-auto-select and selecting the Completions windows is the
>> simplest and cleaner way to go.
>
>Earlier you said that it should work like zsh.  But does zsh
>really select the Completions window?  I see that typing a letter
>while a completion candidate is highlighted in zsh, inserts both
>the highlighted completion candidate and the letter.
>This looks like it never leaves the command line
>that corresponds to the minibuffer in Emacs.
>So why do you think that switching to the Completions window
>is required to select a completion candidate?
>
Basically because we don't need that exact behavior in all the details
as our use case is a bit different different (and simpler). we use
single commands most if the time. I mean, most of the completion we need
are for single commands/candidates/files because we can't do things
like: "M-x find-file /my/file/path" in a single line. (there are some
exceptions line shell-commands or so... but those are the exception, not
the rule)

But also because emulating that from completions is straight forward
considering that Completions is read-only and any edit attempt (insert a
letter) will emit an error we can handle moving to the minibuffer and
executing there whatever we need.

zsh adds an extra space before the letter so even if it does not leave
the command line completely there is a switch to a state where arrows
navigate, a letter inserts a space and C-g restores to the initial... So
there is a mode and context change.


>>>> Then it should probably be line-move but forward-line goes to column zero.
>>>
>>> Neither of them wraps to the beginning like next-completion does.
>>
>> The wrap behavior is only set for tab and backtab commands (yes, it is
>> hardcoded there... don't blame me) not even for all next-completion
>> uses. I prefer not to touch that code anymore or add more stuff
>> there... At some point we will decide to fix/replace the mouse-face
>> approach there and all this will be a nightmare to support the legacy
>> behavior. >This means we need a new command next-completion-vertical.
>>
>> I already tried that in the first version of zcomplete I did long time
>> ago. And you said (and I agreed) that it was too complicated.
>
>But in zsh <up> and <down> wrap to the top/bottom of the same column.
>
Yes, I already implemented that and you didn't liked because it was a
bit long ;p... Now this is getting longer and longer....

>Also in zsh TAB moves vertically when columns are sorted vertically.
>Shouldn't TAB in Emacs move vertically too when 'completions-format'
>is 'vertical'?
>
Actually yes... But implementation will be long and ugly... I don't
think it worth it...

The ideal case may be to have some modes completions-vertical,
completions-horizontal and completions-one-column that will handle all
the pack together (bindings, order, formats)... but may break some of
the external packages. Otherwise we will end with a code full of if-else
and hard to maintain or extend...

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 07:53:33PM +0300, Juri Linkov wrote:
>>> icomplete is based on post-command-hook, so zcomplete would need it too.
>>
>> Sorry, not agree here. If zcomplete intention is to emulate the zsh
>> behavior then it is not needed to use post-command-hook. Completions are
>> shown on demand <tab>... post-command-hook is for a behavior more like
>> browsers... We already have helm, ivy, icomplete, vertico, selectrum,
>> ido, fido (with the vertical variants too) and all the others... I don't
>> think we need more of that and reinvent the well once again.
>>
>> Simple in better than complicated ;)
>
>Earlier you suggested to add a new minor mode, but now you say
>that a minor mode is complicated.  Isn't this a contradiction? ;)
>
You said it was and I didn't want to argue on that... Remember lisp is a
sort of magician... so I always assume there are quick solutions but I
tend to reinvent the well myself. For example... That menu-item+filter
solution you proposed for me is black magic and I couldn't even find
what a menu-item.

>And the same find-as-you-type autocompletion like in browsers
>is supported by zsh as well:
>https://github.com/marlonrichert/zsh-autocomplete
>
Yes, I know it. I tried it when I had zsh some time ago... But 1) it is
an external thing not in zsh 2) it will be simpler to implement with
icomplete and that family of completion engines.

Also the zle engine is much more robust and simple than what we have in
emacs now because it only needs to support their use case; and written
from the scratch for them.

In emacs there is already vertico to do more or less what you want and
it ended up being a bit more complex that what we want in vanilla but
with more or less 800 lines... If we want vertico, then just add vertico
to vanilla, lets not re-implement it right?

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> So why do you think that switching to the Completions window
>> is required to select a completion candidate?
>
> Basically because we don't need that exact behavior in all the details
> as our use case is a bit different different (and simpler). we use
> single commands most if the time. I mean, most of the completion we need
> are for single commands/candidates/files because we can't do things
> like: "M-x find-file /my/file/path" in a single line. (there are some
> exceptions line shell-commands or so... but those are the exception, not
> the rule)
>
> But also because emulating that from completions is straight forward
> considering that Completions is read-only and any edit attempt (insert a
> letter) will emit an error we can handle moving to the minibuffer and
> executing there whatever we need.
>
> zsh adds an extra space before the letter so even if it does not leave
> the command line completely there is a switch to a state where arrows
> navigate, a letter inserts a space and C-g restores to the initial... So
> there is a mode and context change.

So inserting a letter from the Completions buffer is the only thing
that you miss from zsh?  But you also said above that this feature is
not important because such cases are rare: "M-x find-file /my/file/path".

In all other regards, currently it works exactly like in zsh:
'TAB TAB' selects the Completions window, and C-g cancels it.

>> But in zsh <up> and <down> wrap to the top/bottom of the same column.
>
> Yes, I already implemented that and you didn't liked because it was a
> bit long ;p... Now this is getting longer and longer....

Indeed, its logic looks complicated.  But maybe we could implement
simple rules like in zsh?  Then <up> ans <down> in the Completions
buffer could be bound to new commands.

>> Also in zsh TAB moves vertically when columns are sorted vertically.
>> Shouldn't TAB in Emacs move vertically too when 'completions-format'
>> is 'vertical'?
>
> Actually yes... But implementation will be long and ugly... I don't
> think it worth it...
>
> The ideal case may be to have some modes completions-vertical,
> completions-horizontal and completions-one-column that will handle all
> the pack together (bindings, order, formats)... but may break some of
> the external packages. Otherwise we will end with a code full of if-else
> and hard to maintain or extend...

Looks like the right thing to do.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> And the same find-as-you-type autocompletion like in browsers
>> is supported by zsh as well:
>> https://github.com/marlonrichert/zsh-autocomplete
>
> Yes, I know it. I tried it when I had zsh some time ago... But
> 1) it is an external thing not in zsh

Actually, there is internal customization in zsh as well:

1. zstyle ':completion:*' menu select interactive
   - allows typing a letter that immediately
   updates the list of completions.

2. zstyle ':completion:*' menu select search
   - shows the prompt "isearch:" where typing letters
   searches them incrementally in the list of completions.

> 2) it will be simpler to implement with
> icomplete and that family of completion engines.

Agreed, this would be the best thing to do.

> In emacs there is already vertico to do more or less what you want and
> it ended up being a bit more complex that what we want in vanilla but
> with more or less 800 lines... If we want vertico, then just add vertico
> to vanilla, lets not re-implement it right?

Does vertico show completions in the *Completions* window?

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 08:57:17PM +0300, Juri Linkov wrote:
>>> So why do you think that switching to the Completions window
>>> is required to select a completion candidate?
>>
>> Basically because we don't need that exact behavior in all the details
>> as our use case is a bit different different (and simpler). we use
>> single commands most if the time. I mean, most of the completion we need
>> are for single commands/candidates/files because we can't do things
>> like: "M-x find-file /my/file/path" in a single line. (there are some
>> exceptions line shell-commands or so... but those are the exception, not
>> the rule)
>>
>> But also because emulating that from completions is straight forward
>> considering that Completions is read-only and any edit attempt (insert a
>> letter) will emit an error we can handle moving to the minibuffer and
>> executing there whatever we need.
>>
>> zsh adds an extra space before the letter so even if it does not leave
>> the command line completely there is a switch to a state where arrows
>> navigate, a letter inserts a space and C-g restores to the initial... So
>> there is a mode and context change.
>
>So inserting a letter from the Completions buffer is the only thing
>that you miss from zsh? 

Actually yes, that and remove the mode-line to completions...

>But you also said above that this feature is
>not important because such cases are rare: "M-x find-file /my/file/path".
>
I can live with that. Lets say in our case adding a space does not make
much sense, but just inserting the letter in place without completion
may be a better behavior... But again... I can live with this.

>In all other regards, currently it works exactly like in zsh:
>'TAB TAB' selects the Completions window, and C-g cancels it.
>
Yes...

>>> But in zsh <up> and <down> wrap to the top/bottom of the same column.
>>
>> Yes, I already implemented that and you didn't liked because it was a
>> bit long ;p... Now this is getting longer and longer....
>
>Indeed, its logic looks complicated.  But maybe we could implement
>simple rules like in zsh?  Then <up> ans <down> in the Completions
>buffer could be bound to new commands.
>
Let's cleanup master and move to our own branch then??

>>> Also in zsh TAB moves vertically when columns are sorted vertically.
>>> Shouldn't TAB in Emacs move vertically too when 'completions-format'
>>> is 'vertical'?
>>
>> Actually yes... But implementation will be long and ugly... I don't
>> think it worth it...
>>
>> The ideal case may be to have some modes completions-vertical,
>> completions-horizontal and completions-one-column that will handle all
>> the pack together (bindings, order, formats)... but may break some of
>> the external packages. Otherwise we will end with a code full of if-else
>> and hard to maintain or extend...
>
>Looks like the right thing to do.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Thu, Apr 07, 2022 at 09:04:12PM +0300, Juri Linkov wrote:
>>> And the same find-as-you-type autocompletion like in browsers
>>> is supported by zsh as well:
>>> https://github.com/marlonrichert/zsh-autocomplete
>>
>> Yes, I know it. I tried it when I had zsh some time ago... But
>> 1) it is an external thing not in zsh
>
>Actually, there is internal customization in zsh as well:
>
>1. zstyle ':completion:*' menu select interactive
>   - allows typing a letter that immediately
>   updates the list of completions.
>
Yes, but that may be complicated because completions calls a function
that will try first to complete the common part and then update the
completions. (Look what happens when you press a letter and tab
immediately). There are few ways to go around that without braking half
of the Universe. Look where I added the code for the
completion-auto-help visible and always... there is where the magic
happens.

Maybe you will find a better way to manage what you want.

>2. zstyle ':completion:*' menu select search
>   - shows the prompt "isearch:" where typing letters
>   searches them incrementally in the list of completions.
>
>> 2) it will be simpler to implement with
>> icomplete and that family of completion engines.
>
>Agreed, this would be the best thing to do.
>
For that we have fido and similes... What we are trying to improve a bit
is the default completion engine. Then the user will choose fido, ido or
something external... it is up to him.

>> In emacs there is already vertico to do more or less what you want and
>> it ended up being a bit more complex that what we want in vanilla but
>> with more or less 800 lines... If we want vertico, then just add vertico
>> to vanilla, lets not re-implement it right?
>
>Does vertico show completions in the *Completions* window?

I don't think so but I am not sure... Most of these tools stay in the
minibuffer for completions... so they don't need to switch context.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> 1. zstyle ':completion:*' menu select interactive
>>    - allows typing a letter that immediately
>>    updates the list of completions.
>
> Yes, but that may be complicated because completions calls a function
> that will try first to complete the common part and then update the
> completions. (Look what happens when you press a letter and tab
> immediately). There are few ways to go around that without braking half
> of the Universe. Look where I added the code for the
> completion-auto-help visible and always... there is where the magic
> happens.
>
> Maybe you will find a better way to manage what you want.

Indeed, this is why I proposed to create zcomplete-mode
that works exactly like icomplete-mode, but updates completions
in the Completions window instead of the minibuffer.

>> 2. zstyle ':completion:*' menu select search
>>    - shows the prompt "isearch:" where typing letters
>>    searches them incrementally in the list of completions.
>
>>> 2) it will be simpler to implement with
>>> icomplete and that family of completion engines.
>>
>> Agreed, this would be the best thing to do.
>
> For that we have fido and similes... What we are trying to improve a bit
> is the default completion engine. Then the user will choose fido, ido or
> something external... it is up to him.

fido, ido and others use the minibuffer, but zcomplete-mode will use
the Completions window.

>> Does vertico show completions in the Completions window?
>
> I don't think so but I am not sure... Most of these tools stay in the
> minibuffer for completions... so they don't need to switch context.

They stay in the minibuffer and display completions in the minibuffer,
whereas zcomplete-mode will display completions in the Completions window
while staying in the minibuffer, like zsh does.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>> So inserting a letter from the Completions buffer is the only thing
>> that you miss from zsh?
>
> Actually yes, that and remove the mode-line to completions...
>
>> But you also said above that this feature is
>> not important because such cases are rare: "M-x find-file /my/file/path".
>
> I can live with that. Lets say in our case adding a space does not make
> much sense, but just inserting the letter in place without completion
> may be a better behavior... But again... I can live with this.

Indeed, there is a problem with staying in the Completions buffer
and typing a letter.  When this letter will update the completion,
then the Completions buffer should be updated that causes more problems
such as where to move point after such buffer reverting, since
the Completions buffer is the current buffer, etc.

>> In all other regards, currently it works exactly like in zsh:
>> 'TAB TAB' selects the Completions window, and C-g cancels it.
>
> Yes...

So we have two possible cases: selecting a completion candidate
when the Completions buffer is the current buffer, and the second
case is when the minibuffer is current.  The first case now works fine,
and we need to improve the second case.  The new mode zcomplete-mode
will help to do this.

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Fri, Apr 08, 2022 at 10:40:33AM +0300, Juri Linkov wrote:
>>> 1. zstyle ':completion:*' menu select interactive
>>>    - allows typing a letter that immediately
>>>    updates the list of completions.
>>
>> Yes, but that may be complicated because completions calls a function
>> that will try first to complete the common part and then update the
>> completions. (Look what happens when you press a letter and tab
>> immediately). There are few ways to go around that without braking half
>> of the Universe. Look where I added the code for the
>> completion-auto-help visible and always... there is where the magic
>> happens.
>>
>> Maybe you will find a better way to manage what you want.
>
>Indeed, this is why I proposed to create zcomplete-mode
>that works exactly like icomplete-mode, but updates completions
>in the Completions window instead of the minibuffer.
>
IIRC Helm already uses that approach?

>>> 2. zstyle ':completion:*' menu select search
>>>    - shows the prompt "isearch:" where typing letters
>>>    searches them incrementally in the list of completions.
>>
>>>> 2) it will be simpler to implement with
>>>> icomplete and that family of completion engines.
>>>
>>> Agreed, this would be the best thing to do.
>>
>> For that we have fido and similes... What we are trying to improve a bit
>> is the default completion engine. Then the user will choose fido, ido or
>> something external... it is up to him.
>
>fido, ido and others use the minibuffer, but zcomplete-mode will use
>the Completions window.
>
Then my question will be... what's the advantage/difference from the
user point of view compared with putting the completions in the
minibuffer like icomplete/fido/ivy/ido do?

I mean, in general fido/icomplete/ivy work fine and comfortable. The
only difference with zsh in general will be the tabular vs vertical
view... but that can be implemented in icomplete more or less easily if
you really want to...

>>> Does vertico show completions in the Completions window?
>>
>> I don't think so but I am not sure... Most of these tools stay in the
>> minibuffer for completions... so they don't need to switch context.
>
>They stay in the minibuffer and display completions in the minibuffer,
>whereas zcomplete-mode will display completions in the Completions window
>while staying in the minibuffer, like zsh does.
>
As I said... whats the practical benefit?

Best,
Ergus

Re: [PATCH] Re: Other details about completion.

[Ergus]

On Fri, Apr 08, 2022 at 10:45:48AM +0300, Juri Linkov wrote:
>>> So inserting a letter from the Completions buffer is the only thing
>>> that you miss from zsh?
>>
>> Actually yes, that and remove the mode-line to completions...
>>
>>> But you also said above that this feature is
>>> not important because such cases are rare: "M-x find-file /my/file/path".
>>
>> I can live with that. Lets say in our case adding a space does not make
>> much sense, but just inserting the letter in place without completion
>> may be a better behavior... But again... I can live with this.
>
>Indeed, there is a problem with staying in the Completions buffer
>and typing a letter.  When this letter will update the completion,
>then the Completions buffer should be updated that causes more problems
>such as where to move point after such buffer reverting, since
>the Completions buffer is the current buffer, etc.
>
>>> In all other regards, currently it works exactly like in zsh:
>>> 'TAB TAB' selects the Completions window, and C-g cancels it.
>>
>> Yes...
>
>So we have two possible cases: selecting a completion candidate
>when the Completions buffer is the current buffer, and the second
>case is when the minibuffer is current.  The first case now works fine,
>and we need to improve the second case.  The new mode zcomplete-mode
>will help to do this.

The advantage of using the minibuffer for everything as icomplete does
is that there is no context switching, so it is a single case, single
map etc... The inly liitation we have there then is that completins are
not shown on demand, but automatically; but I am not sure if that is
actually a bad or good thing...

Re: [PATCH] Re: Other details about completion.

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>> 1. zstyle ':completion:*' menu select interactive
>>>    - allows typing a letter that immediately
>>>    updates the list of completions.
>>
>> Yes, but that may be complicated because completions calls a function
>> that will try first to complete the common part and then update the
>> completions. (Look what happens when you press a letter and tab
>> immediately). There are few ways to go around that without braking half
>> of the Universe. Look where I added the code for the
>> completion-auto-help visible and always... there is where the magic
>> happens.
>>
>> Maybe you will find a better way to manage what you want.
>
> Indeed, this is why I proposed to create zcomplete-mode
> that works exactly like icomplete-mode, but updates completions
> in the Completions window instead of the minibuffer.

Only on input in the minibuffer?  I think it would also be convenient if
self-insert commands could optionally be rebound to also do narrowing in
the Completions window.

-- 
	Philip Kaludercic

Re: [PATCH] Re: Other details about completion.

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Rebinding them after M-<down> might be an option?  But...  Probably not.
>
> Why not, set-transient-map could activate M-<left>/<right> after M-<down>.

I mean, we could, but I think that would probably be confusing.  But I
guess we could try it and see what it feels like -- UI things like this
are hard to predict how they'll feel like until you've used them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: [PATCH] Re: Other details about completion.

[Drew Adams]

> >Indeed, this is why I proposed to create zcomplete-mode
> >that works exactly like icomplete-mode, but updates completions
> >in the Completions window instead of the minibuffer.
>
> IIRC Helm already uses that approach?

Icicles has done that much longer, FWIW.

Icicles predates Ido (but not IswitchB or Icomplete).
For a very long time, `icomplete-mode' just _showed_
(some) candidates - you couldn't do anything with them.

> >They stay in the minibuffer and display completions in the minibuffer,
> >whereas zcomplete-mode will display completions in the Completions window
> >while staying in the minibuffer, like zsh does.

That's what Emacs (and Icicles, FWIW) has always done.

And nothing makes anything "stay" anywhere, including
in the minibuffer.  You can move focus to *Completions*
anytime.  Besides using a mouse etc., you can do that
in Icicles using `C-<insert>' (it also moves back).

There should be no particular _need_ to move focus to
*Completions*, however - everything should be possible
with the focus in the minibuffer.

If the aim is to force users to move to *Completions*
to act on candidates, that would be a step backward.

But it should be possible to do _some_ things in
*Completions* - such as marking candidates for actions,
either together as a group or separately) - including
doing so by selecting them with the region.

RE: [External] : Re: [PATCH] Re: Other details about completion.

[Drew Adams]

> >So we have two possible cases: selecting a completion candidate
> >when the Completions buffer is the current buffer, and the second
> >case is when the minibuffer is current.  The first case now works fine,
> >and we need to improve the second case.  The new mode zcomplete-mode
> >will help to do this.
> 
> The advantage of using the minibuffer for everything as icomplete does
> is that there is no context switching, so it is a single case, single
> map etc... 

For every action, yes.  But Icomplete (like Ido) also
uses the minibuffer to display candidates.  A better
model is the standard Emacs one (also Icicles): show
in *Completions*, act in the minibuffer.

> The only limitation we have there then is that completins are
> not shown on demand, but automatically; but I am not sure if that is
> actually a bad or good thing...

It's both a good and a bad thing (should be obvious).
IOW, such a choice should be available to users at
preference-configuration time, or even on the fly,
not decided by Emacs designers at Emacs design time.

Icicles gives users the choice:

https://www.emacswiki.org/emacs/Icicles_-_Icompletion#IncrementalCompletion

1. An option for whether *Completions* is updated
   incrementally as you type.

2. Two options control the delay before automatic
   incremental completion takes effect: # of seconds
   to wait, which takes effect only when there are
   at least N candidates.  This lets you type ahead,
   before an candidate redisplay occurs.

#1 provides several possibilities (cycle with `C-#'):

   `t': Update *Completions* only if already displayed.

   `nil': Never update *Completions* automatically.
          Do so only on demand.

   Other non-nil: Show and update *Completions*
          whenever there's more than one candidate.

   `t' is the default: show *Completions* on demand,
   but once shown, automatically update it.  When
   there's only one candidate, remove it.

3. Another option says whether to show *Completions*
   even before you type any minibuffer input.  Useful
   in some contexts where it makes sense to show you
   the possibilities at the outset, like a menu.  Some
   users like this behavior all the time.

4. You can turn off incremental completion for a given
   command, by putting a non-nil property on its symbol
   (property `icicle-turn-off-incremental-completion').

5. Besides incremental completion in *Completions*,
   there's whether or not input is completed/expanded
   in the minibuffer.  (Cycle with `C-M-"'.)
___

Expansion (#5) is to the longest common match for all
candidates: a substring common to all candidates
matched by your input, but a substring that also
matches your input.  It's described here:

https://www.emacswiki.org/emacs/Icicles_-_Expanded-Common-Match_Completion

 0 - Never expand (similar to Ido).  Just look to
     *Completions* for the completions.  Fits well
     with non-nil & non-t value for #1, above.
 1 - Expand only on demand, when you ask to complete.
 2 - Like 1, but also expand when only one match.
 3 - Like 4, but don't expand for regexp completion.
 4 - Expand whenever completed in *Completions*.

3 & 4 are the most useful, I think.  Cycle with `C-"'.

RE: [External] : Re: [PATCH] Re: Other details about completion.

[Drew Adams]

> > Indeed, this is why I proposed to create zcomplete-mode
> > that works exactly like icomplete-mode, but updates completions
> > in the Completions window instead of the minibuffer.
> 
> Only on input in the minibuffer?  I think it would also be convenient
> if self-insert commands could optionally be rebound to also do narrowing
> in the Completions window.

Why do you think so?  Have you experimented with that?

Please describe/specify the behavior you're requesting.

Narrowing is about refining matches using an input
pattern.  How would editing (self-inserting chars) in
*Completions* help with that?

Why are people thinking it's good to make users move
to *Completions* to carry out completion actions and
actions on candidates?

(My crystal ball whispers "a step backward".)

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>>>> 1. zstyle ':completion:*' menu select interactive
>>>>    - allows typing a letter that immediately
>>>>    updates the list of completions.
>>>
>>> Yes, but that may be complicated because completions calls a function
>>> that will try first to complete the common part and then update the
>>> completions. (Look what happens when you press a letter and tab
>>> immediately). There are few ways to go around that without braking half
>>> of the Universe. Look where I added the code for the
>>> completion-auto-help visible and always... there is where the magic
>>> happens.
>>>
>>> Maybe you will find a better way to manage what you want.
>>
>> Indeed, this is why I proposed to create zcomplete-mode
>> that works exactly like icomplete-mode, but updates completions
>> in the Completions window instead of the minibuffer.
>
> IIRC Helm already uses that approach?

Helm uses own buffer, not the standard *Completions* buffer.

>>>> 2. zstyle ':completion:*' menu select search
>>>>    - shows the prompt "isearch:" where typing letters
>>>>    searches them incrementally in the list of completions.
>>>
>>>>> 2) it will be simpler to implement with
>>>>> icomplete and that family of completion engines.
>>>>
>>>> Agreed, this would be the best thing to do.
>>>
>>> For that we have fido and similes... What we are trying to improve a bit
>>> is the default completion engine. Then the user will choose fido, ido or
>>> something external... it is up to him.
>>
>> fido, ido and others use the minibuffer, but zcomplete-mode will use
>> the Completions window.
>
> Then my question will be... what's the advantage/difference from the
> user point of view compared with putting the completions in the
> minibuffer like icomplete/fido/ivy/ido do?

The advantage is that it's easy to switch to the *Completions* buffer,
and use all available navigation keys and isearch capabilities.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

>>>> 1. zstyle ':completion:*' menu select interactive
>>>>    - allows typing a letter that immediately
>>>>    updates the list of completions.
>>>
>>> Yes, but that may be complicated because completions calls a function
>>> that will try first to complete the common part and then update the
>>> completions. (Look what happens when you press a letter and tab
>>> immediately). There are few ways to go around that without braking half
>>> of the Universe. Look where I added the code for the
>>> completion-auto-help visible and always... there is where the magic
>>> happens.
>>>
>>> Maybe you will find a better way to manage what you want.
>>
>> Indeed, this is why I proposed to create zcomplete-mode
>> that works exactly like icomplete-mode, but updates completions
>> in the Completions window instead of the minibuffer.
>
> Only on input in the minibuffer?  I think it would also be convenient if
> self-insert commands could optionally be rebound to also do narrowing in
> the Completions window.

You are welcome to try doing this.  However, I already envision such a problem
that updating the content of the current buffer *Completions* will relocate
point to random places as it does when a buffer is reverted without keeping
the previous position of the cursor.

Re: [PATCH] Re: Other details about completion.

[Juri Linkov]

> The advantage of using the minibuffer for everything as icomplete does
> is that there is no context switching, so it is a single case, single
> map etc... The inly liitation we have there then is that completins are
> not shown on demand, but automatically; but I am not sure if that is
> actually a bad or good thing...

Ok, so tomorrow I will work on implementing zcomplete-mode,
then you will see how good it is.

Re: [PATCH] Re: Other details about completion.

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>>>> 1. zstyle ':completion:*' menu select interactive
>>>>>    - allows typing a letter that immediately
>>>>>    updates the list of completions.
>>>>
>>>> Yes, but that may be complicated because completions calls a function
>>>> that will try first to complete the common part and then update the
>>>> completions. (Look what happens when you press a letter and tab
>>>> immediately). There are few ways to go around that without braking half
>>>> of the Universe. Look where I added the code for the
>>>> completion-auto-help visible and always... there is where the magic
>>>> happens.
>>>>
>>>> Maybe you will find a better way to manage what you want.
>>>
>>> Indeed, this is why I proposed to create zcomplete-mode
>>> that works exactly like icomplete-mode, but updates completions
>>> in the Completions window instead of the minibuffer.
>>
>> Only on input in the minibuffer?  I think it would also be convenient if
>> self-insert commands could optionally be rebound to also do narrowing in
>> the Completions window.
>
> You are welcome to try doing this.  

OK, I will as soon as you update your proposal.

>                                     However, I already envision such a problem
> that updating the content of the current buffer *Completions* will relocate
> point to random places as it does when a buffer is reverted without keeping
> the previous position of the cursor.

True, but I don't think that this is unsolvable.  If narrowing doesn't
remove a selection option, then you ensure that the point remains on the
same word.  Otherwise you try to find the closest remaining neighbour?

-- 
	Philip Kaludercic