all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#59486: completion-auto-wrap disobeyed by vertical navigation
@ 2022-11-22 17:38 Juri Linkov
  2022-11-23 18:49 ` Juri Linkov
  0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-22 17:38 UTC (permalink / raw)
  To: 59486

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

In a multi-column layout, the keys <left> and <right>
wrap to the beginning/end of the completions buffer,
but <up> and <down> don't.  Here is a patch that supports
completion-auto-wrap for wrapping to the top/bottom:


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

diff --git a/lisp/simple.el b/lisp/simple.el
index 0f44b14948c..459af2fcf55 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9572,6 +9574,8 @@ completion-list-mode-map
     (define-key map "\C-m" 'choose-completion)
     (define-key map "\e\e\e" 'delete-completion-window)
     (define-key map [remap keyboard-quit] #'delete-completion-window)
+    (define-key map [up] 'previous-line-completion)
+    (define-key map [down] 'next-line-completion)
     (define-key map [left] 'previous-completion)
     (define-key map [right] 'next-completion)
     (define-key map [?\t] 'next-completion)
@@ -9736,6 +9740,77 @@ next-completion
     (when (/= 0 n)
       (switch-to-minibuffer))))
 
+(defun previous-line-completion (&optional n)
+  "Move to the item on the previous line in the completion list.
+With prefix argument N, move back N items line-wise (negative N
+means move forward).
+
+Also see the `completion-auto-wrap' variable."
+  (interactive "p")
+  (next-line-completion (- n)))
+
+(defun next-line-completion (&optional n)
+  "Move to the item on the next line in the completion list.
+With prefix argument N, move N items line-wise (negative N
+means move backward).
+
+Also see the `completion-auto-wrap' variable."
+  (interactive "p")
+  (let ((column (current-column))
+        pos)
+    (catch 'bound
+      (while (> n 0)
+        (setq pos nil)
+        (save-excursion
+          (while (and (not pos) (not (eobp)))
+            (forward-line 1)
+            (when (and (not (eobp))
+                       (eq (move-to-column column) column)
+                       (get-text-property (point) 'mouse-face))
+              (setq pos (point)))))
+        (if pos
+            (goto-char pos)
+          (when completion-auto-wrap
+            (let ((column (current-column)))
+              (save-excursion
+                (goto-char (point-min))
+                (when (and (eq (move-to-column column) column)
+                           (get-text-property (point) 'mouse-face))
+                  (setq pos (point)))
+                (while (and (not pos) (not (eobp)))
+                  (forward-line 1)
+                  (when (and (eq (move-to-column column) column)
+                             (get-text-property (point) 'mouse-face))
+                    (setq pos (point)))))
+              (if pos (goto-char pos)))))
+        (setq n (1- n)))
+
+      (while (< n 0)
+        (setq pos nil)
+        (save-excursion
+          (while (and (not pos) (not (bobp)))
+            (forward-line -1)
+            (when (and (not (bobp))
+                       (eq (move-to-column column) column)
+                       (get-text-property (point) 'mouse-face))
+              (setq pos (point)))))
+        (if pos
+            (goto-char pos)
+          (when completion-auto-wrap
+            (let ((column (current-column)))
+              (save-excursion
+                (goto-char (point-max))
+                (when (and (eq (move-to-column column) column)
+                           (get-text-property (point) 'mouse-face))
+                  (setq pos (point)))
+                (while (and (not pos) (not (bobp)))
+                  (forward-line -1)
+                  (when (and (eq (move-to-column column) column)
+                             (get-text-property (point) 'mouse-face))
+                    (setq pos (point)))))
+              (if pos (goto-char pos)))))
+        (setq n (1+ n))))))
+
 (defun choose-completion (&optional event no-exit no-quit)
   "Choose the completion at point.
 If EVENT, use EVENT's position to determine the starting position.

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-22 17:38 bug#59486: completion-auto-wrap disobeyed by vertical navigation Juri Linkov
@ 2022-11-23 18:49 ` Juri Linkov
  2022-11-24  7:59   ` Juri Linkov
  0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-23 18:49 UTC (permalink / raw)
  To: 59486

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

> In a multi-column layout, the keys <left> and <right>
> wrap to the beginning/end of the completions buffer,
> but <up> and <down> don't.  Here is a patch that supports
> completion-auto-wrap for wrapping to the top/bottom:

Now pushed.  And here are the corresponding commands for
navigating the completions buffer from the minibuffer:


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

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6bb0fa3ae98..ea1e88c7234 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -4452,7 +4456,7 @@ minibuffer-completion-auto-choose
   :type 'boolean
   :version "29.1")
 
-(defun minibuffer-next-completion (&optional n)
+(defun minibuffer-next-completion (&optional n vertical)
   "Move to the next item in its completions window from the minibuffer.
 When `minibuffer-completion-auto-choose' is non-nil, then also
 insert the selected completion to the minibuffer."
@@ -4461,7 +4465,9 @@ minibuffer-next-completion
     (with-minibuffer-completions-window
       (when completions-highlight-face
         (setq-local cursor-face-highlight-nonselected-window t))
-      (next-completion (or n 1))
+      (if vertical
+          (next-line-completion (or n 1))
+        (next-completion (or n 1)))
       (when auto-choose
         (let ((completion-use-base-affixes t))
           (choose-completion nil t t))))))
@@ -4473,6 +4479,20 @@ minibuffer-previous-completion
   (interactive "p")
   (minibuffer-next-completion (- (or n 1))))
 
+(defun minibuffer-next-line-completion (&optional n)
+  "Move to the next completion line from the minibuffer.
+When `minibuffer-completion-auto-choose' is non-nil, then also
+insert the selected completion to the minibuffer."
+  (interactive "p")
+  (minibuffer-next-completion (or n 1) t))
+
+(defun minibuffer-previous-line-completion (&optional n)
+  "Move to the previous completion line from the minibuffer.
+When `minibuffer-completion-auto-choose' is non-nil, then also
+insert the selected completion to the minibuffer."
+  (interactive "p")
+  (minibuffer-next-completion (- (or n 1)) t))
+
 (defun minibuffer-choose-completion (&optional no-exit no-quit)
   "Run `choose-completion' from the minibuffer in its completions window.
 With prefix argument NO-EXIT, insert the completion at point to the

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-23 18:49 ` Juri Linkov
@ 2022-11-24  7:59   ` Juri Linkov
  2022-11-24  8:13     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-24  7:59 UTC (permalink / raw)
  To: 59486

> And here are the corresponding commands for navigating
> the completions buffer from the minibuffer:
>
> +(defun minibuffer-next-line-completion (&optional n)
> +(defun minibuffer-previous-line-completion (&optional n)

It seems there commands can't be bound in the minibuffer.
Ideally, these keybindings could be added to
minibuffer-local-completion-map:

  "M-<left>"  #'minibuffer-previous-completion
  "M-<right>" #'minibuffer-next-completion
  "M-<up>"    #'minibuffer-previous-line-completion
  "M-<down>"  #'minibuffer-next-line-completion

But maybe 'M-<left>' and 'M-<right>' can't be taken from moving by words
even when 'C-<left>' and 'C-<right>' are duplicate keys that are doing
the same.  Or to bind 'M-<left>' and 'M-<right>' only in
completion-in-region-mode-map that is more transient by nature
and is active only as long as the completions buffer is shown.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-24  7:59   ` Juri Linkov
@ 2022-11-24  8:13     ` Eli Zaretskii
  2022-11-24 18:30       ` Juri Linkov
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-24  8:13 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 59486

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 24 Nov 2022 09:59:52 +0200
> 
> > And here are the corresponding commands for navigating
> > the completions buffer from the minibuffer:
> >
> > +(defun minibuffer-next-line-completion (&optional n)
> > +(defun minibuffer-previous-line-completion (&optional n)
> 
> It seems there commands can't be bound in the minibuffer.
> Ideally, these keybindings could be added to
> minibuffer-local-completion-map:
> 
>   "M-<left>"  #'minibuffer-previous-completion
>   "M-<right>" #'minibuffer-next-completion
>   "M-<up>"    #'minibuffer-previous-line-completion
>   "M-<down>"  #'minibuffer-next-line-completion
> 
> But maybe 'M-<left>' and 'M-<right>' can't be taken from moving by words
> even when 'C-<left>' and 'C-<right>' are duplicate keys that are doing
> the same.  Or to bind 'M-<left>' and 'M-<right>' only in
> completion-in-region-mode-map that is more transient by nature
> and is active only as long as the completions buffer is shown.

Please don't usurp M-<LEFT> and M-<RIGHT>, as they are needed on TTY frames
where C-<LEFT> and C-<RIGHT> are not available.

I don't really understand the difference between minibuffer-previous-* and
minibuffer-previous-line-* commands (the available documentation is minimal
and doesn't explain this difference), so it's hard to suggest an
alternative.  But one immediate alternative is to use <LEFT> and <RIGHT> for
the minibuffer-previous-* family, like previous-completion does.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-24  8:13     ` Eli Zaretskii
@ 2022-11-24 18:30       ` Juri Linkov
  2022-11-24 18:43         ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-24 18:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59486

> I don't really understand the difference between minibuffer-previous-* and
> minibuffer-previous-line-* commands (the available documentation is minimal
> and doesn't explain this difference), so it's hard to suggest an alternative.

minibuffer-previous-* are intended to navigate the completion list
horizontally while the minibuffer is active, and minibuffer-previous-line-*
vertically.

> But one immediate alternative is to use <LEFT> and <RIGHT> for
> the minibuffer-previous-* family, like previous-completion does.

<LEFT> and <RIGHT> are useful to move point in the minibuffer.
But do you think it would be okay to use <LEFT> and <RIGHT>
for navigation of completions from the minibuffer after
adding a new user option, when is non-nil (disabled by default)?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-24 18:30       ` Juri Linkov
@ 2022-11-24 18:43         ` Eli Zaretskii
  2022-11-25  7:47           ` Juri Linkov
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-24 18:43 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 59486

> From: Juri Linkov <juri@linkov.net>
> Cc: 59486@debbugs.gnu.org
> Date: Thu, 24 Nov 2022 20:30:00 +0200
> 
> > I don't really understand the difference between minibuffer-previous-* and
> > minibuffer-previous-line-* commands (the available documentation is minimal
> > and doesn't explain this difference), so it's hard to suggest an alternative.
> 
> minibuffer-previous-* are intended to navigate the completion list
> horizontally while the minibuffer is active, and minibuffer-previous-line-*
> vertically.

Then the names could be simplified as minibuffer-up-line and
minibuffer-down-line.  It will also make the names less confusing, IMO.

> > But one immediate alternative is to use <LEFT> and <RIGHT> for
> > the minibuffer-previous-* family, like previous-completion does.
> 
> <LEFT> and <RIGHT> are useful to move point in the minibuffer.

Then maybe PgUp and PgDn?

> But do you think it would be okay to use <LEFT> and <RIGHT>
> for navigation of completions from the minibuffer after
> adding a new user option, when is non-nil (disabled by default)?

If the arrow keys are already taken, having an option that will change their
effect would be confusing, I think.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-24 18:43         ` Eli Zaretskii
@ 2022-11-25  7:47           ` Juri Linkov
  2022-11-25  8:38             ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-25  7:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59486

>> minibuffer-previous-* are intended to navigate the completion list
>> horizontally while the minibuffer is active, and minibuffer-previous-line-*
>> vertically.
>
> Then the names could be simplified as minibuffer-up-line and
> minibuffer-down-line.  It will also make the names less confusing, IMO.

It's not only about the minibuffer, but also about completions,
so the commands names should also include the word "completion".

>> > But one immediate alternative is to use <LEFT> and <RIGHT> for
>> > the minibuffer-previous-* family, like previous-completion does.
>> 
>> <LEFT> and <RIGHT> are useful to move point in the minibuffer.
>
> Then maybe PgUp and PgDn?

PgUp and PgDn are used to scroll the completions buffer from the minibuffer.

>> But do you think it would be okay to use <LEFT> and <RIGHT>
>> for navigation of completions from the minibuffer after
>> adding a new user option, when is non-nil (disabled by default)?
>
> If the arrow keys are already taken, having an option that will change their
> effect would be confusing, I think.

It does the same as icomplete-vertical-mode where the arrow keys
are not confusing.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-25  7:47           ` Juri Linkov
@ 2022-11-25  8:38             ` Eli Zaretskii
  2022-11-28  7:56               ` Juri Linkov
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-25  8:38 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 59486

> From: Juri Linkov <juri@linkov.net>
> Cc: 59486@debbugs.gnu.org
> Date: Fri, 25 Nov 2022 09:47:29 +0200
> 
> >> minibuffer-previous-* are intended to navigate the completion list
> >> horizontally while the minibuffer is active, and minibuffer-previous-line-*
> >> vertically.
> >
> > Then the names could be simplified as minibuffer-up-line and
> > minibuffer-down-line.  It will also make the names less confusing, IMO.
> 
> It's not only about the minibuffer, but also about completions,
> so the commands names should also include the word "completion".

minibuffer-up-completions-line is still shorter and less confusing.

> >> > But one immediate alternative is to use <LEFT> and <RIGHT> for
> >> > the minibuffer-previous-* family, like previous-completion does.
> >> 
> >> <LEFT> and <RIGHT> are useful to move point in the minibuffer.
> >
> > Then maybe PgUp and PgDn?
> 
> PgUp and PgDn are used to scroll the completions buffer from the minibuffer.

That's a bad idea, IMO: scrolling another window should use something like
M-PgDn and C-M-v, like we do with other windows elsewhere.

> > If the arrow keys are already taken, having an option that will change their
> > effect would be confusing, I think.
> 
> It does the same as icomplete-vertical-mode where the arrow keys
> are not confusing.

icomplete-vertical-mode is a an opt-in feature, so what it does is less
relevant to the issue at point, IMO.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59486: completion-auto-wrap disobeyed by vertical navigation
  2022-11-25  8:38             ` Eli Zaretskii
@ 2022-11-28  7:56               ` Juri Linkov
  0 siblings, 0 replies; 9+ messages in thread
From: Juri Linkov @ 2022-11-28  7:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59486

>> >> minibuffer-previous-* are intended to navigate the completion list
>> >> horizontally while the minibuffer is active, and minibuffer-previous-line-*
>> >> vertically.
>> >
>> > Then the names could be simplified as minibuffer-up-line and
>> > minibuffer-down-line.  It will also make the names less confusing, IMO.
>>
>> It's not only about the minibuffer, but also about completions,
>> so the commands names should also include the word "completion".
>
> minibuffer-up-completions-line is still shorter and less confusing.

'minibuffer-previous-line-completion' is named after 'previous-line'
that is not named 'up-line'.  There are 'left-char', 'left-word', etc.
only in horizontal direction, but no 'up-line' in vertical direction.
So it makes no sense to propagate this inconsistency to completion
command names where there are only 'previous-completion', but no
'left-completion'.

>> It does the same as icomplete-vertical-mode where the arrow keys
>> are not confusing.
>
> icomplete-vertical-mode is a an opt-in feature, so what it does is less
> relevant to the issue at point, IMO.

The proposed feature is also opt-in.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-11-28  7:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-22 17:38 bug#59486: completion-auto-wrap disobeyed by vertical navigation Juri Linkov
2022-11-23 18:49 ` Juri Linkov
2022-11-24  7:59   ` Juri Linkov
2022-11-24  8:13     ` Eli Zaretskii
2022-11-24 18:30       ` Juri Linkov
2022-11-24 18:43         ` Eli Zaretskii
2022-11-25  7:47           ` Juri Linkov
2022-11-25  8:38             ` Eli Zaretskii
2022-11-28  7:56               ` Juri Linkov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.