unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* completions - remove window after use?
@ 2009-11-11 19:45 David Reitter
  2009-11-11 20:28 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: David Reitter @ 2009-11-11 19:45 UTC (permalink / raw)
  To: Emacs development discussions

When showing a *completions* buffer in a new window opened for it (TAB in find-file minibuffer for instance), I wonder why the window doesn't get deleted when completion has finished.  For instance, when an existing file is found, the *Completions* buffer is buried, but I see a split frame with the original buffer in the top window and _some other_ buffer in the lower window.

Shouldn't the window for the completions buffer be removed whenever it has been popped up just for the buffer?





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

* Re: completions - remove window after use?
  2009-11-11 19:45 completions - remove window after use? David Reitter
@ 2009-11-11 20:28 ` Stefan Monnier
  2009-11-11 21:26   ` Štěpán Němec
  2009-11-12  3:00 ` Xavier Maillard
  2009-11-12  8:19 ` martin rudalics
  2 siblings, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2009-11-11 20:28 UTC (permalink / raw)
  To: David Reitter; +Cc: Emacs development discussions

> When showing a *completions* buffer in a new window opened for it (TAB
> in find-file minibuffer for instance), I wonder why the window doesn't
> get deleted when completion has finished.  For instance, when an
> existing file is found, the *Completions* buffer is buried, but I see
> a split frame with the original buffer in the top window and _some
> other_ buffer in the lower window.

> Shouldn't the window for the completions buffer be removed whenever it
> has been popped up just for the buffer?

I'd tend to agree, but haven't touched it because my usage is
clearly atypical.


        Stefan




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

* Re: completions - remove window after use?
  2009-11-11 20:28 ` Stefan Monnier
@ 2009-11-11 21:26   ` Štěpán Němec
  2009-11-11 23:21     ` Stefan Monnier
  0 siblings, 1 reply; 43+ messages in thread
From: Štěpán Němec @ 2009-11-11 21:26 UTC (permalink / raw)
  To: emacs-devel

On Wed, Nov 11, 2009 at 03:28:09PM -0500, Stefan Monnier wrote:
> > When showing a *completions* buffer in a new window opened for it (TAB
> > in find-file minibuffer for instance), I wonder why the window doesn't
> > get deleted when completion has finished.  For instance, when an
> > existing file is found, the *Completions* buffer is buried, but I see
> > a split frame with the original buffer in the top window and _some
> > other_ buffer in the lower window.
> 
> > Shouldn't the window for the completions buffer be removed whenever it
> > has been popped up just for the buffer?
> 
> I'd tend to agree, but haven't touched it because my usage is
> clearly atypical.
> 
> 
>         Stefan
> 
> 
Please do touch it, I don't think the current behaviour makes much (read
any) sense either.

And speaking about *Completions*, would it be possible to fill the
completions column-first, not row-first as it is now?  I find it quite
unreasonable, as the display is column-wise, but not so filling, making
it harder to quickly skim through the list.

(my English is not perfect, so in case it is not clear from the above
description:
currently, the completions come like this:
aaaa    aaaab
abb     abbbb
bbb     bccc
ccc     dddd

whereas more sensible (because of the column-wise display) IMHO would be:
aaaa    bbb
aaaab   bccc
abb     ccc
abbbb   dddd
)

Regards,


    Štěpán




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

* Re: completions - remove window after use?
  2009-11-11 21:26   ` Štěpán Němec
@ 2009-11-11 23:21     ` Stefan Monnier
  2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
  2009-11-12 13:30       ` completions - remove window after use? Lluís
  0 siblings, 2 replies; 43+ messages in thread
From: Stefan Monnier @ 2009-11-11 23:21 UTC (permalink / raw)
  To: emacs-devel

> Please do touch it, I don't think the current behaviour makes much (read
> any) sense either.

I'd first hear of other users.

> And speaking about *Completions*, would it be possible to fill the
> completions column-first, not row-first as it is now?  I find it quite
> unreasonable, as the display is column-wise, but not so filling, making
> it harder to quickly skim through the list.

I'm not sure why you find it unreasonable, but I'd find it inconvenient
when the list overflows the window, to have a column-first listing since
I couldn't then first scroll to the interesting area.


        Stefan




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

* Re: completions - remove window after use?
  2009-11-11 19:45 completions - remove window after use? David Reitter
  2009-11-11 20:28 ` Stefan Monnier
@ 2009-11-12  3:00 ` Xavier Maillard
  2009-11-12  8:19 ` martin rudalics
  2 siblings, 0 replies; 43+ messages in thread
From: Xavier Maillard @ 2009-11-12  3:00 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel


   When showing a *completions* buffer in a new window opened for
   it (TAB in find-file minibuffer for instance), I wonder why
   the window doesn't get deleted when completion has finished.
   For instance, when an existing file is found, the
   *Completions* buffer is buried, but I see a split frame with
   the original buffer in the top window and _some other_ buffer
   in the lower window.

   Shouldn't the window for the completions buffer be removed
   whenever it has been popped up just for the buffer?

You could hook a function that does this on `minibuffer-exit-hook'.

For example, (100% untested solution):

(add-hook 'minibuffer-exit-hook
	  '(lambda ()
	     (let ((comp "*Completions*"))
	       (and (get-buffer comp)
		    (kill-buffer )))))


	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org




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

* Re: completions - remove window after use?
  2009-11-11 19:45 completions - remove window after use? David Reitter
  2009-11-11 20:28 ` Stefan Monnier
  2009-11-12  3:00 ` Xavier Maillard
@ 2009-11-12  8:19 ` martin rudalics
  2009-11-12 22:36   ` Xavier Maillard
  2 siblings, 1 reply; 43+ messages in thread
From: martin rudalics @ 2009-11-12  8:19 UTC (permalink / raw)
  To: David Reitter; +Cc: Emacs development discussions

 > When showing a *completions* buffer in a new window opened for
 > it (TAB in find-file minibuffer for instance), I wonder why the
 > window doesn't get deleted when completion has finished.  For
 > instance, when an existing file is found, the *Completions*
 > buffer is buried, but I see a split frame with the original
 > buffer in the top window and _some other_ buffer in the lower
 > window.  Shouldn't the window for the completions buffer be
 > removed whenever it has been popped up just for the buffer?

This should not happen and doesn't happen with my older builds.  Could
you please (1) make sure that the behavior also happens with Emacs -Q,
(2) try to find out when it appeared for the first time, and (3) make a
corresponding bug report.

Thanks, martin




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

* Vertical completions (was: completions - remove window after use?)
  2009-11-11 23:21     ` Stefan Monnier
@ 2009-11-12  9:57       ` Juri Linkov
  2009-11-12 10:09         ` Deniz Dogan
                           ` (2 more replies)
  2009-11-12 13:30       ` completions - remove window after use? Lluís
  1 sibling, 3 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-12  9:57 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> And speaking about *Completions*, would it be possible to fill the
>> completions column-first, not row-first as it is now?  I find it quite
>> unreasonable, as the display is column-wise, but not so filling, making
>> it harder to quickly skim through the list.
>
> I'm not sure why you find it unreasonable, but I'd find it inconvenient
> when the list overflows the window, to have a column-first listing since
> I couldn't then first scroll to the interesting area.

It's easier to skim through a list when completions are sorted
vertically in columns down the screen.

That's what `ls' does by default for the list of files unless
`-x' (`--format=horizontal') is specified.  As well as readline
completions in bash unless `print-completions-horizontally' is `On'.

The same would be desirable in Emacs, but it has a problem -
if columns were sorted vertically, Isearch will still visit matches
horizontally.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Vertical completions (was: completions - remove window after  use?)
  2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
@ 2009-11-12 10:09         ` Deniz Dogan
  2009-11-17 17:45           ` Vertical completions Juri Linkov
  2009-11-12 10:29         ` Vertical completions (was: completions - remove window after use?) Štěpán Němec
  2009-11-12 19:26         ` Eli Zaretskii
  2 siblings, 1 reply; 43+ messages in thread
From: Deniz Dogan @ 2009-11-12 10:09 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel

2009/11/12 Juri Linkov <juri@jurta.org>:
>>> And speaking about *Completions*, would it be possible to fill the
>>> completions column-first, not row-first as it is now?  I find it quite
>>> unreasonable, as the display is column-wise, but not so filling, making
>>> it harder to quickly skim through the list.
>>
>> I'm not sure why you find it unreasonable, but I'd find it inconvenient
>> when the list overflows the window, to have a column-first listing since
>> I couldn't then first scroll to the interesting area.
>
> It's easier to skim through a list when completions are sorted
> vertically in columns down the screen.
>
> That's what `ls' does by default for the list of files unless
> `-x' (`--format=horizontal') is specified.  As well as readline
> completions in bash unless `print-completions-horizontally' is `On'.
>
> The same would be desirable in Emacs, but it has a problem -
> if columns were sorted vertically, Isearch will still visit matches
> horizontally.
>
> --
> Juri Linkov
> http://www.jurta.org/emacs/
>
>
>

If it's not too problematic to implement, I'm all for the change (or
rather an option to have it).

-- 
Deniz Dogan




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

* Re: Vertical completions (was: completions - remove window after use?)
  2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
  2009-11-12 10:09         ` Deniz Dogan
@ 2009-11-12 10:29         ` Štěpán Němec
  2009-11-12 19:26         ` Eli Zaretskii
  2 siblings, 0 replies; 43+ messages in thread
From: Štěpán Němec @ 2009-11-12 10:29 UTC (permalink / raw)
  To: emacs-devel

On Thu, Nov 12, 2009 at 11:57:33AM +0200, Juri Linkov wrote:
> >> And speaking about *Completions*, would it be possible to fill the
> >> completions column-first, not row-first as it is now?  I find it quite
> >> unreasonable, as the display is column-wise, but not so filling, making
> >> it harder to quickly skim through the list.
> >
> > I'm not sure why you find it unreasonable, but I'd find it inconvenient
> > when the list overflows the window, to have a column-first listing since
> > I couldn't then first scroll to the interesting area.
> 
> It's easier to skim through a list when completions are sorted
> vertically in columns down the screen.
> 
> That's what `ls' does by default for the list of files unless
> `-x' (`--format=horizontal') is specified.  As well as readline
> completions in bash unless `print-completions-horizontally' is `On'.
> 
> The same would be desirable in Emacs, but it has a problem -
> if columns were sorted vertically, Isearch will still visit matches
> horizontally.

I wouldn't really see that as a problem -- it's quite expectable; I
think it could be actually rather confusing if the search would go in
columns, too -- after all, the columns are just how the text is
displayed, there is no "real" boundary between them.




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

* Re: completions - remove window after use?
  2009-11-11 23:21     ` Stefan Monnier
  2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
@ 2009-11-12 13:30       ` Lluís
  2009-11-12 14:40         ` David Reitter
  2009-11-12 15:15         ` Stefan Monnier
  1 sibling, 2 replies; 43+ messages in thread
From: Lluís @ 2009-11-12 13:30 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> I'd first hear of other users.

I also am for it.

> I'm not sure why you find it unreasonable, but I'd find it inconvenient
> when the list overflows the window, to have a column-first listing since
> I couldn't then first scroll to the interesting area.

Well, window height can be calculated, so that it's filled up like:

1 4
2 5
3 5
---- page boundary
6 9
7 10
8

Still not sure if this is a good idea, as it would make not much sense when
user moves in a line-by-line basis through the buffer. But again, the
"show next bunch of completions" moves to next "page", so it would behave
as expected.

Also, layout should be recalculated when user changes window height...

As for searching, it's "page-wise", so not much problem would arise from
here.

Lluis

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth




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

* Re: completions - remove window after use?
  2009-11-12 13:30       ` completions - remove window after use? Lluís
@ 2009-11-12 14:40         ` David Reitter
  2009-11-12 15:15         ` Stefan Monnier
  1 sibling, 0 replies; 43+ messages in thread
From: David Reitter @ 2009-11-12 14:40 UTC (permalink / raw)
  To: Lluís; +Cc: Stefan Monnier, emacs-devel

On Nov 12, 2009, at 8:30 AM, Lluís wrote:
> 1 4
> 2 5
> 3 5
> ---- page boundary
> 6 9
> 7 10
> 8
> 
> Still not sure if this is a good idea, as it would make not much sense when
> user moves in a line-by-line basis through the buffer.

Not a good idea for the reason you've stated.  We don't really have "page boundaries" as an enforced concept, since a buffer is not a piece of paper.  The only thing that happens is window-wise "paging" with tab, but the buffer can still be used line by line.  Think of someone scrolling with the mouse scroll wheel.

> Also, layout should be recalculated when user changes window height...

So, is it worth the effort?

> As for searching, it's "page-wise", so not much problem would arise from
> here.

It introduces more paging.



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

* Re: completions - remove window after use?
  2009-11-12 13:30       ` completions - remove window after use? Lluís
  2009-11-12 14:40         ` David Reitter
@ 2009-11-12 15:15         ` Stefan Monnier
  2009-11-14  0:30           ` Richard Stallman
  1 sibling, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2009-11-12 15:15 UTC (permalink / raw)
  To: Lluís; +Cc: emacs-devel

> Well, window height can be calculated, so that it's filled up like:

> 1 4
> 2 5
> 3 5
> ---- page boundary
> 6 9
> 7 10
> 8

Actually, with faces and whatnot, computing the amount of text that will
fit is *very* difficult (the "simple" solution will work in most cases,
tho).


        Stefan




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

* Re: Vertical completions (was: completions - remove window after use?)
  2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
  2009-11-12 10:09         ` Deniz Dogan
  2009-11-12 10:29         ` Vertical completions (was: completions - remove window after use?) Štěpán Němec
@ 2009-11-12 19:26         ` Eli Zaretskii
  2009-11-12 22:00           ` Lennart Borgman
  2 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2009-11-12 19:26 UTC (permalink / raw)
  To: Juri Linkov; +Cc: monnier, emacs-devel

> From: Juri Linkov <juri@jurta.org>
> Date: Thu, 12 Nov 2009 11:57:33 +0200
> Cc: emacs-devel@gnu.org
> 
> It's easier to skim through a list when completions are sorted
> vertically in columns down the screen.

"Easier" is in the eyes of the beholder, I think.  I find the
horizontal arrangement much more friendly.

> That's what `ls' does by default for the list of files unless
> `-x' (`--format=horizontal') is specified.

Right, which is why I always alias `ls' to "ls -x".

> The same would be desirable in Emacs, but it has a problem -
> if columns were sorted vertically, Isearch will still visit matches
> horizontally.

I don't see any reason for such a change, certainly not to change the
order of Isearch on top of that.




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

* Re: Vertical completions (was: completions - remove window after  use?)
  2009-11-12 19:26         ` Eli Zaretskii
@ 2009-11-12 22:00           ` Lennart Borgman
  0 siblings, 0 replies; 43+ messages in thread
From: Lennart Borgman @ 2009-11-12 22:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Juri Linkov, monnier, emacs-devel

On Thu, Nov 12, 2009 at 8:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Juri Linkov <juri@jurta.org>
>> Date: Thu, 12 Nov 2009 11:57:33 +0200
>> Cc: emacs-devel@gnu.org
>>
>> It's easier to skim through a list when completions are sorted
>> vertically in columns down the screen.
>
> "Easier" is in the eyes of the beholder, I think.  I find the
> horizontal arrangement much more friendly.


I agree. Especially if the alternatives are many this is better since
it matches the vertical scrolling better.




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

* Re: completions - remove window after use?
  2009-11-12  8:19 ` martin rudalics
@ 2009-11-12 22:36   ` Xavier Maillard
  0 siblings, 0 replies; 43+ messages in thread
From: Xavier Maillard @ 2009-11-12 22:36 UTC (permalink / raw)
  To: martin rudalics; +Cc: david.reitter, emacs-devel


    > When showing a *completions* buffer in a new window opened for
    > it (TAB in find-file minibuffer for instance), I wonder why the
    > window doesn't get deleted when completion has finished.  For
    > instance, when an existing file is found, the *Completions*
    > buffer is buried, but I see a split frame with the original
    > buffer in the top window and _some other_ buffer in the lower
    > window.  Shouldn't the window for the completions buffer be
    > removed whenever it has been popped up just for the buffer?

   This should not happen and doesn't happen with my older builds.  Could
   you please (1) make sure that the behavior also happens with Emacs -Q,
   (2) try to find out when it appeared for the first time, and (3) make a
   corresponding bug report.

Gha, I did not notice he was talking about a *window*. Sorry for
the noise. At least I tested my code and it worked. :D

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org




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

* Re: completions - remove window after use?
  2009-11-12 15:15         ` Stefan Monnier
@ 2009-11-14  0:30           ` Richard Stallman
  0 siblings, 0 replies; 43+ messages in thread
From: Richard Stallman @ 2009-11-14  0:30 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: xscript, emacs-devel

    Actually, with faces and whatnot, computing the amount of text that will
    fit is *very* difficult (the "simple" solution will work in most cases,
    tho).

Primitives to do this computation have been in etc/TODO for many
years.  Would anyone like to please start writing them?




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

* Re: Vertical completions
  2009-11-12 10:09         ` Deniz Dogan
@ 2009-11-17 17:45           ` Juri Linkov
  2009-11-18  8:11             ` martin rudalics
                               ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-17 17:45 UTC (permalink / raw)
  To: Deniz Dogan; +Cc: Stefan Monnier, emacs-devel

>>>> And speaking about *Completions*, would it be possible to fill the
>>>> completions column-first, not row-first as it is now?  I find it quite
>>>> unreasonable, as the display is column-wise, but not so filling, making
>>>> it harder to quickly skim through the list.
>>
>> It's easier to skim through a list when completions are sorted
>> vertically in columns down the screen.
>>
>> That's what `ls' does by default for the list of files unless
>> `-x' (`--format=horizontal') is specified.  As well as readline
>> completions in bash unless `print-completions-horizontally' is `On'.
>
> If it's not too problematic to implement, I'm all for the change (or
> rather an option to have it).

Not problematic at all.  Below is a small patch that implements
a new option for vertical completions with the default to
traditional horizontal completions, of course.

Index: lisp/minibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v
retrieving revision 1.96
diff -c -w -b -r1.96 minibuffer.el
*** lisp/minibuffer.el	12 Nov 2009 23:10:06 -0000	1.96
--- lisp/minibuffer.el	17 Nov 2009 17:44:46 -0000
***************
*** 778,783 ****
--- 778,793 ----
  (defface completions-annotations '((t :inherit italic))
    "Face to use for annotations in the *Completions* buffer.")
  
+ (defcustom completions-format nil
+   "Define the appearance and sorting of completions.
+ If the value is `vertical', display completions sorted vertically
+ in columns in the *Completions* buffer.
+ If the value is `horizontal' or nil, display completions sorted
+ horizontally in alphabetical order, rather than down the screen."
+   :type '(choice (const nil) (const horizontal) (const vertical))
+   :group 'minibuffer
+   :version "23.2")
+ 
  (defun completion--insert-strings (strings)
    "Insert a list of STRINGS into the current buffer.
  Uses columns to keep the listing readable but compact.
***************
*** 800,805 ****
--- 810,817 ----
  		     (max 1 (/ (length strings) 2))))
  	   (colwidth (/ wwidth columns))
             (column 0)
+ 	   (rows (/ (length strings) columns))
+ 	   (row 0)
  	   (laststring nil))
        ;; The insertion should be "sensible" no matter what choices were made
        ;; for the parameters above.
***************
*** 810,815 ****
--- 822,840 ----
                              (+ (string-width (car str))
                                 (string-width (cadr str)))
                            (string-width str))))
+             (cond
+ 	     ((eq completions-format 'vertical)
+ 	      ;; Vertical format
+ 	      (when (> row rows)
+ 		(forward-line (- -1 rows))
+ 		(setq row 0 column (setq column (+ column colwidth))))
+ 	      (when (> column 0)
+ 		(end-of-line)
+ 		(insert " \t")
+ 		(set-text-properties (- (point) 1) (point)
+ 				     `(display (space :align-to ,column)))))
+ 	     (t
+ 	      ;; Horizontal format
  	      (unless (bolp)
  		(if (< wwidth (+ (max colwidth length) column))
  		    ;; No space for `str' at point, move to next line.
***************
*** 823,829 ****
                                       ;; completion-setup-function will kill all
                                       ;; local variables :-(
                                       `(display (space :align-to ,column)))
!                 nil))
              (if (not (consp str))
                  (put-text-property (point) (progn (insert str) (point))
                                     'mouse-face 'highlight)
--- 848,854 ----
  				       ;; completion-setup-function will kill all
  				       ;; local variables :-(
  				       `(display (space :align-to ,column)))
! 		  nil))))
              (if (not (consp str))
                  (put-text-property (point) (progn (insert str) (point))
                                     'mouse-face 'highlight)
***************
*** 832,841 ****
                (add-text-properties (point) (progn (insert (cadr str)) (point))
                                     '(mouse-face nil
                                       face completions-annotations)))
              ;; Next column to align to.
              (setq column (+ column
                              ;; Round up to a whole number of columns.
!                             (* colwidth (ceiling length colwidth))))))))))
  
  (defvar completion-common-substring nil)
  (make-obsolete-variable 'completion-common-substring nil "23.1")
--- 857,875 ----
                (add-text-properties (point) (progn (insert (cadr str)) (point))
                                     '(mouse-face nil
  						face completions-annotations)))
+ 	    (cond
+ 	     ((eq completions-format 'vertical)
+ 	      ;; Vertical format
+ 	      (if (> column 0)
+ 		  (forward-line)
+ 		(insert "\n"))
+ 	      (setq row (1+ row)))
+ 	     (t
+ 	      ;; Horizontal format
  	      ;; Next column to align to.
  	      (setq column (+ column
  			      ;; Round up to a whole number of columns.
! 			      (* colwidth (ceiling length colwidth))))))))))))
  
  (defvar completion-common-substring nil)
  (make-obsolete-variable 'completion-common-substring nil "23.1")

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Vertical completions
  2009-11-17 17:45           ` Vertical completions Juri Linkov
@ 2009-11-18  8:11             ` martin rudalics
  2009-11-18  9:59               ` Juri Linkov
  2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
  2009-11-18  9:52             ` switch-to-completions (was: Vertical completions) Juri Linkov
  2 siblings, 1 reply; 43+ messages in thread
From: martin rudalics @ 2009-11-18  8:11 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel, Stefan Monnier, Deniz Dogan

 > Not problematic at all.  Below is a small patch that implements
 > a new option for vertical completions with the default to
 > traditional horizontal completions, of course.

It might make sense to preferably split windows horizontally for
displaying "vertical completions".

martin




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

* Backward completions (was: Vertical completions)
  2009-11-17 17:45           ` Vertical completions Juri Linkov
  2009-11-18  8:11             ` martin rudalics
@ 2009-11-18  9:47             ` Juri Linkov
  2009-11-18 15:06               ` Drew Adams
                                 ` (2 more replies)
  2009-11-18  9:52             ` switch-to-completions (was: Vertical completions) Juri Linkov
  2 siblings, 3 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-18  9:47 UTC (permalink / raw)
  To: emacs-devel

>>> It's easier to skim through a list when completions are sorted
>>> vertically in columns down the screen.
>>
>> If it's not too problematic to implement, I'm all for the change (or
>> rather an option to have it).
>
> Not problematic at all.  Below is a small patch that implements
> a new option for vertical completions with the default to
> traditional horizontal completions, of course.

Scrolling the *Completions* buffer a full screen with the <TAB> key
is convenient to find a desirable item in a long list.

However, typing the <backtab> key doesn't reverse the scrolling
direction like this key does in other places in Emacs.  So to return to
the previous screen requires scrolling to the end of the *Completions*
buffer, wrapping to the beginning and scrolling forward from the
beginning, looking carefully to not miss the previous screen again.

The following patch binds <backtab> to `minibuffer-complete-backward'
that is an alias of `minibuffer-complete'.  But maybe code in
`minibuffer-complete' is so small, so it could be copied to a new
function `minibuffer-complete-backward' (with small modifications)
instead of creating an alias?

Index: lisp/minibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v
retrieving revision 1.96
diff -c -w -b -r1.96 minibuffer.el
*** lisp/minibuffer.el	12 Nov 2009 23:10:06 -0000	1.96
--- lisp/minibuffer.el	18 Nov 2009 09:45:59 -0000
***************
*** 516,524 ****
  If you repeat this command after it displayed such a list,
  scroll the window of possible completions."
    (interactive)
!   ;; If the previous command was not this,
    ;; mark the completion buffer obsolete.
!   (unless (eq this-command last-command)
      (setq minibuffer-scroll-window nil))
  
    (let ((window minibuffer-scroll-window))
--- 516,528 ----
  If you repeat this command after it displayed such a list,
  scroll the window of possible completions."
    (interactive)
!   ;; If the previous command (or its alias) was not this,
    ;; mark the completion buffer obsolete.
!   (unless (or (eq this-command last-command)
! 	      (and (memq this-command '(minibuffer-complete
! 					minibuffer-complete-backward))
! 		   (memq last-command '(minibuffer-complete
! 					minibuffer-complete-backward))))
      (setq minibuffer-scroll-window nil))
  
    (let ((window minibuffer-scroll-window))
***************
*** 526,536 ****
      ;; and this command is repeated, scroll that window.
      (if (window-live-p window)
          (with-current-buffer (window-buffer window)
            (if (pos-visible-in-window-p (point-max) window)
  	      ;; If end is in view, scroll up to the beginning.
  	      (set-window-start window (point-min) nil)
  	    ;; Else scroll down one screen.
! 	    (scroll-other-window))
  	  nil)
  
        (case (completion--do-completion)
--- 530,550 ----
      ;; and this command is repeated, scroll that window.
      (if (window-live-p window)
          (with-current-buffer (window-buffer window)
+           (if (eq this-command 'minibuffer-complete-backward)
+ 	      ;; Scroll completions backward.
+ 	      (if (pos-visible-in-window-p (point-min) window)
+ 		  ;; If beginning is in view, scroll down to the end.
+ 		  (with-selected-window window
+ 		    (goto-char (point-max))
+ 		    (recenter -1))
+ 		;; Else scroll up one screen.
+ 		(scroll-other-window-down nil))
+ 	    ;; Scroll completions forward.
  	    (if (pos-visible-in-window-p (point-max) window)
  		;; If end is in view, scroll up to the beginning.
  		(set-window-start window (point-min) nil)
  	      ;; Else scroll down one screen.
! 	      (scroll-other-window)))
  	  nil)
  
        (case (completion--do-completion)
***************
*** 541,546 ****
--- 555,568 ----
                 t)
          (t     t)))))
  
+ (defalias 'minibuffer-complete-backward 'minibuffer-complete
+   "Like `minibuffer-complete', but scroll completions backward.
+ If you repeat this command after `minibuffer-complete' or
+ `minibuffer-complete-backward' displayed a list of possible
+ completions, it scrolls the window of possible completions a full
+ screen in the direction opposite to the scrolling direction of
+ `minibuffer-complete'.")
+ 
  (defvar completion-all-sorted-completions nil)
  (make-variable-buffer-local 'completion-all-sorted-completions)

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* switch-to-completions (was: Vertical completions)
  2009-11-17 17:45           ` Vertical completions Juri Linkov
  2009-11-18  8:11             ` martin rudalics
  2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
@ 2009-11-18  9:52             ` Juri Linkov
  2009-11-18 15:48               ` switch-to-completions Stefan Monnier
  2 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2009-11-18  9:52 UTC (permalink / raw)
  To: emacs-devel

After scrolling with the help of `minibuffer-complete' or
`minibuffer-complete-backward' to the middle of a long list
of completions, and typing `M-v' or <prior> (bound to
`switch-to-completions') to select a completion item using
keyboard, point jumps to the beginning of the *Completions*
buffer, thus requiring to scroll to the middle of the list
again.  I suppose moving point to the first item is necessary
only in the new *Completions* buffer:

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.1030
diff -c -r1.1030 simple.el
*** lisp/simple.el	15 Nov 2009 15:32:18 -0000	1.1030
--- lisp/simple.el	18 Nov 2009 09:50:52 -0000
***************
*** 6032,6045 ****
    "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)
!       (goto-char (point-min))
!       (search-forward "\n\n" nil t)
!       (forward-line 1))))
  \f
  ;;; Support keyboard commands to turn on various modifiers.
  
--- 6057,6071 ----
    "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)
!       ;; In the new buffer, go to the first completion.
!       (when (bobp)
! 	(search-forward "\n\n" nil t)
! 	(forward-line 1)))))
  \f
  ;;; Support keyboard commands to turn on various modifiers.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Vertical completions
  2009-11-18  8:11             ` martin rudalics
@ 2009-11-18  9:59               ` Juri Linkov
  0 siblings, 0 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-18  9:59 UTC (permalink / raw)
  To: martin rudalics; +Cc: emacs-devel, Stefan Monnier, Deniz Dogan

>> Not problematic at all.  Below is a small patch that implements
>> a new option for vertical completions with the default to
>> traditional horizontal completions, of course.
>
> It might make sense to preferably split windows horizontally for
> displaying "vertical completions".

In a wide frame, displaying completions splits windows horizontally.
So I think everything is fine already in this regard.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* RE: Backward completions (was: Vertical completions)
  2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
@ 2009-11-18 15:06               ` Drew Adams
  2009-11-18 15:47                 ` Lennart Borgman
  2009-11-18 15:45               ` Stefan Monnier
  2009-11-18 19:50               ` Backward completions (was: Vertical completions) Dan Nicolaescu
  2 siblings, 1 reply; 43+ messages in thread
From: Drew Adams @ 2009-11-18 15:06 UTC (permalink / raw)
  To: 'Juri Linkov', emacs-devel

> The following patch binds <backtab> to `minibuffer-complete-backward'

I wish you wouldn't do that - just a wish. <backtab> is essentially S-TAB. I
would prefer that Emacs leave TAB combinations alone, so that users and
libraries can make use of them without stepping on standard bindings.

FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for scrolling
completions than do TAB and <backtab>.





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

* Re: Backward completions
  2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
  2009-11-18 15:06               ` Drew Adams
@ 2009-11-18 15:45               ` Stefan Monnier
  2009-11-18 19:01                 ` Juri Linkov
  2009-11-18 19:50               ` Backward completions (was: Vertical completions) Dan Nicolaescu
  2 siblings, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2009-11-18 15:45 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> The following patch binds <backtab> to `minibuffer-complete-backward'
> that is an alias of `minibuffer-complete'.  But maybe code in
> `minibuffer-complete' is so small, so it could be copied to a new
> function `minibuffer-complete-backward' (with small modifications)
> instead of creating an alias?

I'm not convinced it makes sense for backtab to do completion.  
And we already have M-prior to scroll backward.


        Stefan




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

* Re: Backward completions (was: Vertical completions)
  2009-11-18 15:06               ` Drew Adams
@ 2009-11-18 15:47                 ` Lennart Borgman
  2009-11-18 19:02                   ` Backward completions Juri Linkov
  0 siblings, 1 reply; 43+ messages in thread
From: Lennart Borgman @ 2009-11-18 15:47 UTC (permalink / raw)
  To: Drew Adams; +Cc: Juri Linkov, emacs-devel

On Wed, Nov 18, 2009 at 4:06 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> The following patch binds <backtab> to `minibuffer-complete-backward'
>
> I wish you wouldn't do that - just a wish. <backtab> is essentially S-TAB. I
> would prefer that Emacs leave TAB combinations alone, so that users and
> libraries can make use of them without stepping on standard bindings.

This is used extensively in org-mode.

> FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for scrolling
> completions than do TAB and <backtab>.

Page Up/Down?




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

* Re: switch-to-completions
  2009-11-18  9:52             ` switch-to-completions (was: Vertical completions) Juri Linkov
@ 2009-11-18 15:48               ` Stefan Monnier
  2009-11-18 19:04                 ` switch-to-completions Juri Linkov
  0 siblings, 1 reply; 43+ messages in thread
From: Stefan Monnier @ 2009-11-18 15:48 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> After scrolling with the help of `minibuffer-complete' or
> `minibuffer-complete-backward' to the middle of a long list
> of completions, and typing `M-v' or <prior> (bound to
> `switch-to-completions') to select a completion item using
> keyboard, point jumps to the beginning of the *Completions*
> buffer, thus requiring to scroll to the middle of the list
> again.  I suppose moving point to the first item is necessary
> only in the new *Completions* buffer:

Yes, that makes sense.  An alternative would be to make
minibuffer-completion-help itself do the (search-forward "\n\n" nil t),
which would seem to make more sense (e.g. minibuffer-completion-help is
the function that fills the buffer and presumably knows that this \n\n
exists and is it the right place, whereas switch-to-completions only can
assume that minibuffer-completion-help places a \n\n at the right place).


        Stefan




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

* Re: Backward completions
  2009-11-18 15:45               ` Stefan Monnier
@ 2009-11-18 19:01                 ` Juri Linkov
  0 siblings, 0 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-18 19:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> The following patch binds <backtab> to `minibuffer-complete-backward'
>> that is an alias of `minibuffer-complete'.  But maybe code in
>> `minibuffer-complete' is so small, so it could be copied to a new
>> function `minibuffer-complete-backward' (with small modifications)
>> instead of creating an alias?
>
> I'm not convinced it makes sense for backtab to do completion.
> And we already have M-prior to scroll backward.

Actually I rarely scroll a large list of completions using <TAB> since
it's more convenient to switch to the *Completions* buffer and to use
normal scrolling keys.  So I don't insist on the <backtab> key.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-18 15:47                 ` Lennart Borgman
@ 2009-11-18 19:02                   ` Juri Linkov
  2009-11-18 19:36                     ` Lennart Borgman
  0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2009-11-18 19:02 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Drew Adams, emacs-devel

>>> The following patch binds <backtab> to `minibuffer-complete-backward'
>>
>> I wish you wouldn't do that - just a wish. <backtab> is essentially S-TAB. I
>> would prefer that Emacs leave TAB combinations alone, so that users and
>> libraries can make use of them without stepping on standard bindings.
>
> This is used extensively in org-mode.

For minibuffer completions?

>> FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for scrolling
>> completions than do TAB and <backtab>.
>
> Page Up/Down?

<PgUp> and M-v are bound to `switch-to-completions', so they can't be used
for scrolling.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: switch-to-completions
  2009-11-18 15:48               ` switch-to-completions Stefan Monnier
@ 2009-11-18 19:04                 ` Juri Linkov
  2009-11-19  1:12                   ` switch-to-completions Stefan Monnier
  0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2009-11-18 19:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> After scrolling with the help of `minibuffer-complete' or
>> `minibuffer-complete-backward' to the middle of a long list
>> of completions, and typing `M-v' or <prior> (bound to
>> `switch-to-completions') to select a completion item using
>> keyboard, point jumps to the beginning of the *Completions*
>> buffer, thus requiring to scroll to the middle of the list
>> again.  I suppose moving point to the first item is necessary
>> only in the new *Completions* buffer:
>
> Yes, that makes sense.  An alternative would be to make
> minibuffer-completion-help itself do the (search-forward "\n\n" nil t),
> which would seem to make more sense (e.g. minibuffer-completion-help is
> the function that fills the buffer and presumably knows that this \n\n
> exists and is it the right place, whereas switch-to-completions only can
> assume that minibuffer-completion-help places a \n\n at the right place).

I'm not sure what function should take care about finding the right place
since creation of the *Completions* buffer is shared among several functions:
`display-completion-list' inserts the text "Possible completions are:\n",
`completion-setup-function' inserts the help text with one newline or
two newlines depending on `(display-mouse-p)' or no help text if
`completion-show-help' is nil.  And there are many packages that
don't call `minibuffer-completion-help' - they use something like
(with-output-to-temp-buffer "*Completions*" (display-completion-list ...

Maybe `switch-to-completions' should simply call `(next-completion 1)'?
It seems this is the most reliable way to move point to the first completion.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-18 19:02                   ` Backward completions Juri Linkov
@ 2009-11-18 19:36                     ` Lennart Borgman
  2009-11-19 17:36                       ` Juri Linkov
  0 siblings, 1 reply; 43+ messages in thread
From: Lennart Borgman @ 2009-11-18 19:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Drew Adams, emacs-devel

On Wed, Nov 18, 2009 at 8:02 PM, Juri Linkov <juri@jurta.org> wrote:
>>>> The following patch binds <backtab> to `minibuffer-complete-backward'
>>>
>>> I wish you wouldn't do that - just a wish. <backtab> is essentially S-TAB. I
>>> would prefer that Emacs leave TAB combinations alone, so that users and
>>> libraries can make use of them without stepping on standard bindings.
>>
>> This is used extensively in org-mode.
>
> For minibuffer completions?

Eh, sorry ... ;-)


>>> FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for scrolling
>>> completions than do TAB and <backtab>.
>>
>> Page Up/Down?
>
> <PgUp> and M-v are bound to `switch-to-completions', so they can't be used
> for scrolling.

But normal scrolling keys would be more convenient for scrolling, wouldn't they?




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

* Re: Backward completions (was: Vertical completions)
  2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
  2009-11-18 15:06               ` Drew Adams
  2009-11-18 15:45               ` Stefan Monnier
@ 2009-11-18 19:50               ` Dan Nicolaescu
  2009-11-19 17:32                 ` Backward completions Juri Linkov
  2 siblings, 1 reply; 43+ messages in thread
From: Dan Nicolaescu @ 2009-11-18 19:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

Juri Linkov <juri@jurta.org> writes:

  > >>> It's easier to skim through a list when completions are sorted
  > >>> vertically in columns down the screen.
  > >>
  > >> If it's not too problematic to implement, I'm all for the change (or
  > >> rather an option to have it).
  > >
  > > Not problematic at all.  Below is a small patch that implements
  > > a new option for vertical completions with the default to
  > > traditional horizontal completions, of course.
  > 
  > Scrolling the *Completions* buffer a full screen with the <TAB> key
  > is convenient to find a desirable item in a long list.
  > 
  > However, typing the <backtab> key doesn't reverse the scrolling
  > direction like this key does in other places in Emacs.  So to return to
  > the previous screen requires scrolling to the end of the *Completions*
  > buffer, wrapping to the beginning and scrolling forward from the
  > beginning, looking carefully to not miss the previous screen again.
  > 
  > The following patch binds <backtab> to `minibuffer-complete-backward'
  > that is an alias of `minibuffer-complete'.  But maybe code in
  > `minibuffer-complete' is so small, so it could be copied to a new
  > function `minibuffer-complete-backward' (with small modifications)
  > instead of creating an alias?

IMHO <backtab> would be nice to have here.

Maybe when looking at this problem people want to look that the approach
in  search-completions.el (that I've been using for a while): use C-s to
move to the *Completions* buffer and do an incremental search there.
Not perfect, but it might be a useful source of inspiration.


The package is this:

;; search-completions
;; Description:  runs isearch in *Completions* buffer, and returns the
;;               completion point is on when the isearch terminates.
;;               Narrows completions interactively with regexp matches.
;; Author:    Radey Shouman              <rshouman@chpc.utexas.edu>
;; File:      search-completions.el
;; $modified: Fri Mar 25 15:09:03 1994 by rshouman $
;;
;; Modified 2003-04-10: lawrence mitchell <wence@gmx.li> to work with
;; Emacs 21.
;;




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

* Re: switch-to-completions
  2009-11-18 19:04                 ` switch-to-completions Juri Linkov
@ 2009-11-19  1:12                   ` Stefan Monnier
  0 siblings, 0 replies; 43+ messages in thread
From: Stefan Monnier @ 2009-11-19  1:12 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

> I'm not sure what function should take care about finding the right place
> since creation of the *Completions* buffer is shared among several functions:
> `display-completion-list' inserts the text "Possible completions are:\n",
> `completion-setup-function' inserts the help text with one newline or
> two newlines depending on `(display-mouse-p)' or no help text if
> `completion-show-help' is nil.

Good point, maybe minibuffer-completion-help is not the best place, but
it's closer than switch-to-completions.

> And there are many packages that
> don't call `minibuffer-completion-help' - they use something like
> (with-output-to-temp-buffer "*Completions*" (display-completion-list ...

Yes, this redundancy sucks, but it's another problem.

> Maybe `switch-to-completions' should simply call `(next-completion 1)'?
> It seems this is the most reliable way to move point to the first completion.

Fine by me.  Install your patch for now, but please include a comment
explaining that the cursor-movement should really be done elsewhere.


        Stefan




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

* Re: Backward completions
  2009-11-18 19:50               ` Backward completions (was: Vertical completions) Dan Nicolaescu
@ 2009-11-19 17:32                 ` Juri Linkov
  2009-11-19 18:29                   ` Dan Nicolaescu
  0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2009-11-19 17:32 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

> IMHO <backtab> would be nice to have here.
>
> Maybe when looking at this problem people want to look that the approach
> in search-completions.el (that I've been using for a while):

I see search-completions.el uses C-v and M-v to scroll completions
from the minibuffer.

> use C-s to move to the *Completions* buffer and do an incremental
> search there.  Not perfect, but it might be a useful source
> of inspiration.

But then you can't use C-s to search in the minibuffer history.

This is the same problem as in bug#3746 where we need the same key C-s
to search in the comint history and in the comint output buffer.

PS: You can see the implementation of isearch in comint mode
I just sent to bug#3746.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-18 19:36                     ` Lennart Borgman
@ 2009-11-19 17:36                       ` Juri Linkov
  2009-11-19 17:58                         ` Lennart Borgman
  2009-11-19 18:24                         ` Drew Adams
  0 siblings, 2 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-19 17:36 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Drew Adams, emacs-devel

>>>> FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for
>>>> scrolling completions than do TAB and <backtab>.
>>>
>>> Page Up/Down?
>>
>> <PgUp> and M-v are bound to `switch-to-completions', so they can't be
>> used for scrolling.
>
> But normal scrolling keys would be more convenient for scrolling,
> wouldn't they?

Then you have to find a convenient key for switching to the
*Completions* buffer (instead of <PgUp> and M-v).

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-19 17:36                       ` Juri Linkov
@ 2009-11-19 17:58                         ` Lennart Borgman
  2009-11-19 18:24                         ` Drew Adams
  1 sibling, 0 replies; 43+ messages in thread
From: Lennart Borgman @ 2009-11-19 17:58 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Drew Adams, emacs-devel

On Thu, Nov 19, 2009 at 6:36 PM, Juri Linkov <juri@jurta.org> wrote:
>>>>> FWIW, C-v and M-v make more sense (yes, in the minibuffer too) for
>>>>> scrolling completions than do TAB and <backtab>.
>>>>
>>>> Page Up/Down?
>>>
>>> <PgUp> and M-v are bound to `switch-to-completions', so they can't be
>>> used for scrolling.
>>
>> But normal scrolling keys would be more convenient for scrolling,
>> wouldn't they?
>
> Then you have to find a convenient key for switching to the
> *Completions* buffer (instead of <PgUp> and M-v).


Yes, but that would be less surprising to most (new) users.




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

* RE: Backward completions
  2009-11-19 17:36                       ` Juri Linkov
  2009-11-19 17:58                         ` Lennart Borgman
@ 2009-11-19 18:24                         ` Drew Adams
  2009-11-20  9:27                           ` Juri Linkov
  2009-11-20 17:29                           ` Juri Linkov
  1 sibling, 2 replies; 43+ messages in thread
From: Drew Adams @ 2009-11-19 18:24 UTC (permalink / raw)
  To: 'Juri Linkov', 'Lennart Borgman'; +Cc: emacs-devel

> >>>> FWIW, C-v and M-v make more sense (yes, in the 
> >>>> minibuffer too) for scrolling completions than
> >>>> do TAB and <backtab>.
> >>>
> >>> Page Up/Down?
> >>
> >> <PgUp> and M-v are bound to `switch-to-completions', so 
> >> they can't be used for scrolling.
> >
> > But normal scrolling keys would be more convenient for scrolling,
> > wouldn't they?
> 
> Then you have to find a convenient key for switching to the
> *Completions* buffer (instead of <PgUp> and M-v).

FWIW, Icicles uses `C-insert' to switch back and forth between *Completions* and
the minibuffer. (Yes, that key sequence is not necessarily available on a
console.) "Insert" is relevant here (Icicles) because moving to the minibuffer
inserts the completion at point from *Completions*.

One possibility might be to make `C-x o' move to *Completions*. It currently
does not do that directly, but you can usually get to *Completions* by repeating
`C-x o'.

In general, it makes sense to use a key for this that is typically associated
with switching windows or buffers (e.g. `C-x o'), not a key that is typically
associated with scrolling (e.g. `M-v' or `prior' aka `PgUp').

And it makes sense to use normal scrolling keys (`C-v', `M-v') to scroll
*Completions*.








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

* Re: Backward completions
  2009-11-19 17:32                 ` Backward completions Juri Linkov
@ 2009-11-19 18:29                   ` Dan Nicolaescu
  2009-11-19 18:36                     ` Drew Adams
  0 siblings, 1 reply; 43+ messages in thread
From: Dan Nicolaescu @ 2009-11-19 18:29 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

Juri Linkov <juri@jurta.org> writes:

  > > IMHO <backtab> would be nice to have here.
  > >
  > > Maybe when looking at this problem people want to look that the approach
  > > in search-completions.el (that I've been using for a while):
  > 
  > I see search-completions.el uses C-v and M-v to scroll completions
  > from the minibuffer.
  > 
  > > use C-s to move to the *Completions* buffer and do an incremental
  > > search there.  Not perfect, but it might be a useful source
  > > of inspiration.
  > 
  > But then you can't use C-s to search in the minibuffer history.

How about C-s searches minibuffer history when *Completions* not shown,
and searches *Completions* when shown?





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

* RE: Backward completions
  2009-11-19 18:29                   ` Dan Nicolaescu
@ 2009-11-19 18:36                     ` Drew Adams
  2009-11-19 19:26                       ` Dan Nicolaescu
  0 siblings, 1 reply; 43+ messages in thread
From: Drew Adams @ 2009-11-19 18:36 UTC (permalink / raw)
  To: 'Dan Nicolaescu', 'Juri Linkov'; +Cc: emacs-devel

> How about C-s searches minibuffer history when *Completions* 
> not shown, and searches *Completions* when shown?

Sounds like a terrible idea, to me.
Just invites confusion.





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

* Re: Backward completions
  2009-11-19 18:36                     ` Drew Adams
@ 2009-11-19 19:26                       ` Dan Nicolaescu
  2009-11-19 19:30                         ` Drew Adams
  0 siblings, 1 reply; 43+ messages in thread
From: Dan Nicolaescu @ 2009-11-19 19:26 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Juri Linkov', emacs-devel

"Drew Adams" <drew.adams@oracle.com> writes:

  > > How about C-s searches minibuffer history when *Completions* 
  > > not shown, and searches *Completions* when shown?
  > 
  > Sounds like a terrible idea, to me.
  > Just invites confusion.

I disagree, it's very much similar to the many DWIM things that we have.




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

* RE: Backward completions
  2009-11-19 19:26                       ` Dan Nicolaescu
@ 2009-11-19 19:30                         ` Drew Adams
  0 siblings, 0 replies; 43+ messages in thread
From: Drew Adams @ 2009-11-19 19:30 UTC (permalink / raw)
  To: 'Dan Nicolaescu'; +Cc: 'Juri Linkov', emacs-devel

>   > > How about C-s searches minibuffer history when *Completions* 
>   > > not shown, and searches *Completions* when shown?
>   > 
>   > Sounds like a terrible idea, to me.
>   > Just invites confusion.
> 
> I disagree, it's very much similar to the many DWIM things 
> that we have.

Exactly (cough cough). ;-)





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

* Re: Backward completions
  2009-11-19 18:24                         ` Drew Adams
@ 2009-11-20  9:27                           ` Juri Linkov
  2009-11-20 17:29                           ` Juri Linkov
  1 sibling, 0 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-20  9:27 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Lennart Borgman', emacs-devel

>> >>>> FWIW, C-v and M-v make more sense (yes, in the minibuffer too)
>> >>>> for scrolling completions than do TAB and <backtab>.
>> >>>
>> >>> Page Up/Down?
>> >>
>> >> <PgUp> and M-v are bound to `switch-to-completions', so
>> >> they can't be used for scrolling.
>> >
>> > But normal scrolling keys would be more convenient for scrolling,
>> > wouldn't they?
>>
>> Then you have to find a convenient key for switching to the
>> *Completions* buffer (instead of <PgUp> and M-v).
>
> FWIW, Icicles uses `C-insert' to switch back and forth between
> *Completions* and the minibuffer. (Yes, that key sequence is not
> necessarily available on a console.) "Insert" is relevant here
> (Icicles) because moving to the minibuffer inserts the completion at
> point from *Completions*.

There is a lack of the necessary command.  There is a command to accept
the completion in the *Completions* buffer (`choose-completion', `RET'),
but no command to insert the completion to the minibuffer without
accepting it.

> One possibility might be to make `C-x o' move to *Completions*.
> It currently does not do that directly, but you can usually get to
> *Completions* by repeating `C-x o'.

This is another problem.  Sometimes `C-x o' doesn't move directly to
*Completions*.  And sometimes `M-prior' in the minibuffer scrolls
the wrong buffer instead of *Completions*.  I suppose this depends
on the window order.

> In general, it makes sense to use a key for this that is typically
> associated with switching windows or buffers (e.g. `C-x o'), not a key that
> is typically associated with scrolling (e.g. `M-v' or `prior' aka `PgUp').
>
> And it makes sense to use normal scrolling keys (`C-v', `M-v') to scroll
> *Completions*.

I agree, but first we have to find a key replacement for `M-v'
to switch to *Completions*.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-19 18:24                         ` Drew Adams
  2009-11-20  9:27                           ` Juri Linkov
@ 2009-11-20 17:29                           ` Juri Linkov
  2009-11-20 17:49                             ` Lennart Borgman
  2009-11-20 21:26                             ` Drew Adams
  1 sibling, 2 replies; 43+ messages in thread
From: Juri Linkov @ 2009-11-20 17:29 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Lennart Borgman', emacs-devel

> In general, it makes sense to use a key for this that is typically
> associated with switching windows or buffers (e.g. `C-x o'), not a key
> that is typically associated with scrolling (e.g. `M-v' or `prior' aka
> `PgUp').

Please don't forget that *Completions* can be invoked not only from
the minibuffer, but from any buffer that supports completions (via
`lisp-complete-symbol', etc.)

So we can't steal `C-v' and `M-v' as completions scrolling keys instead
of their normal meaning.  Also `M-v' doesn't work for switching to
*Completions* from normal buffers.  So we need a separate dedicated key
to switch to *Completions* from any buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/




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

* Re: Backward completions
  2009-11-20 17:29                           ` Juri Linkov
@ 2009-11-20 17:49                             ` Lennart Borgman
  2009-11-20 21:26                             ` Drew Adams
  1 sibling, 0 replies; 43+ messages in thread
From: Lennart Borgman @ 2009-11-20 17:49 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Drew Adams, emacs-devel

On Fri, Nov 20, 2009 at 6:29 PM, Juri Linkov <juri@jurta.org> wrote:
>> In general, it makes sense to use a key for this that is typically
>> associated with switching windows or buffers (e.g. `C-x o'), not a key
>> that is typically associated with scrolling (e.g. `M-v' or `prior' aka
>> `PgUp').
>
> Please don't forget that *Completions* can be invoked not only from
> the minibuffer, but from any buffer that supports completions (via
> `lisp-complete-symbol', etc.)
>
> So we can't steal `C-v' and `M-v' as completions scrolling keys instead
> of their normal meaning.  Also `M-v' doesn't work for switching to
> *Completions* from normal buffers.  So we need a separate dedicated key
> to switch to *Completions* from any buffer.


Would it be possible to arrange so that <M-prior/next> (ie
M-PgUp/Down) could be used?

They call scroll-other-window(-down). Maybe those functions can
changed to something that takes into account that *Completions* are
visible?




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

* RE: Backward completions
  2009-11-20 17:29                           ` Juri Linkov
  2009-11-20 17:49                             ` Lennart Borgman
@ 2009-11-20 21:26                             ` Drew Adams
  1 sibling, 0 replies; 43+ messages in thread
From: Drew Adams @ 2009-11-20 21:26 UTC (permalink / raw)
  To: 'Juri Linkov'; +Cc: 'Lennart Borgman', emacs-devel

> > In general, it makes sense to use a key for this that is typically
> > associated with switching windows or buffers (e.g. `C-x 
> > o'), not a key that is typically associated with scrolling (e.g.
> > `M-v' or `prior' aka `PgUp').
> 
> Please don't forget that *Completions* can be invoked not only from
> the minibuffer, but from any buffer that supports completions (via
> `lisp-complete-symbol', etc.)

True.

> So we can't steal `C-v' and `M-v' as completions scrolling 
> keys instead of their normal meaning.

You can for the minibuffer use, in any case.

And I wouldn't be surprised if `C-x o' worked in the other cases, so `C-x o C-v'
etc. And perhaps `C-M-v' (`scroll-other-window') works also - dunno.

> Also `M-v' doesn't work for switching to
> *Completions* from normal buffers.

Don't know what you mean here. Why "also"? I thought your first point was that a
minibuffer binding for M-v won't affect the non-minibuffer uses. And of course
M-v doesn't switch buffers - it scrolls the current buffer.

> So we need a separate dedicated key
> to switch to *Completions* from any buffer.

Such a "need" doesn't follow.





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

end of thread, other threads:[~2009-11-20 21:26 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-11 19:45 completions - remove window after use? David Reitter
2009-11-11 20:28 ` Stefan Monnier
2009-11-11 21:26   ` Štěpán Němec
2009-11-11 23:21     ` Stefan Monnier
2009-11-12  9:57       ` Vertical completions (was: completions - remove window after use?) Juri Linkov
2009-11-12 10:09         ` Deniz Dogan
2009-11-17 17:45           ` Vertical completions Juri Linkov
2009-11-18  8:11             ` martin rudalics
2009-11-18  9:59               ` Juri Linkov
2009-11-18  9:47             ` Backward completions (was: Vertical completions) Juri Linkov
2009-11-18 15:06               ` Drew Adams
2009-11-18 15:47                 ` Lennart Borgman
2009-11-18 19:02                   ` Backward completions Juri Linkov
2009-11-18 19:36                     ` Lennart Borgman
2009-11-19 17:36                       ` Juri Linkov
2009-11-19 17:58                         ` Lennart Borgman
2009-11-19 18:24                         ` Drew Adams
2009-11-20  9:27                           ` Juri Linkov
2009-11-20 17:29                           ` Juri Linkov
2009-11-20 17:49                             ` Lennart Borgman
2009-11-20 21:26                             ` Drew Adams
2009-11-18 15:45               ` Stefan Monnier
2009-11-18 19:01                 ` Juri Linkov
2009-11-18 19:50               ` Backward completions (was: Vertical completions) Dan Nicolaescu
2009-11-19 17:32                 ` Backward completions Juri Linkov
2009-11-19 18:29                   ` Dan Nicolaescu
2009-11-19 18:36                     ` Drew Adams
2009-11-19 19:26                       ` Dan Nicolaescu
2009-11-19 19:30                         ` Drew Adams
2009-11-18  9:52             ` switch-to-completions (was: Vertical completions) Juri Linkov
2009-11-18 15:48               ` switch-to-completions Stefan Monnier
2009-11-18 19:04                 ` switch-to-completions Juri Linkov
2009-11-19  1:12                   ` switch-to-completions Stefan Monnier
2009-11-12 10:29         ` Vertical completions (was: completions - remove window after use?) Štěpán Němec
2009-11-12 19:26         ` Eli Zaretskii
2009-11-12 22:00           ` Lennart Borgman
2009-11-12 13:30       ` completions - remove window after use? Lluís
2009-11-12 14:40         ` David Reitter
2009-11-12 15:15         ` Stefan Monnier
2009-11-14  0:30           ` Richard Stallman
2009-11-12  3:00 ` Xavier Maillard
2009-11-12  8:19 ` martin rudalics
2009-11-12 22:36   ` Xavier Maillard

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).