completions - remove window after use?

completions - remove window after use?

[David Reitter]

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?

Re: completions - remove window after use?

[Stefan Monnier]

> 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

Re: completions - remove window after use?

[Štěpán Němec]

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

Re: completions - remove window after use?

[Stefan Monnier]

> 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

Vertical completions (was: completions - remove window after use?)

[Juri Linkov]

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

Re: Vertical completions (was: completions - remove window after use?)

[Deniz Dogan]

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

Re: Vertical completions

[Juri Linkov]

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

Re: Vertical completions

[martin rudalics]

 > 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

Re: Vertical completions

[Juri Linkov]

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

Backward completions (was: Vertical completions)

[Juri Linkov]

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

RE: Backward completions (was: Vertical completions)

[Drew Adams]

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

Re: Backward completions (was: Vertical completions)

[Lennart Borgman]

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?

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions

[Lennart Borgman]

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?

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions

[Lennart Borgman]

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.

RE: Backward completions

[Drew Adams]

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

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions

[Lennart Borgman]

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?

RE: Backward completions

[Drew Adams]

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

Re: Backward completions

[Stefan Monnier]

> 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

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions (was: Vertical completions)

[Dan Nicolaescu]

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

Re: Backward completions

[Juri Linkov]

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

Re: Backward completions

[Dan Nicolaescu]

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?

RE: Backward completions

[Drew Adams]

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

Re: Backward completions

[Dan Nicolaescu]

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

RE: Backward completions

[Drew Adams]

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

switch-to-completions (was: Vertical completions)

[Juri Linkov]

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/

Re: switch-to-completions

[Stefan Monnier]

> 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

Re: switch-to-completions

[Juri Linkov]

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

Re: switch-to-completions

[Stefan Monnier]

> 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

Re: Vertical completions (was: completions - remove window after use?)

[Štěpán Němec]

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.

Re: Vertical completions (was: completions - remove window after use?)

[Eli Zaretskii]

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

Re: Vertical completions (was: completions - remove window after use?)

[Lennart Borgman]

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.

Re: completions - remove window after use?

[Lluís]

> 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

Re: completions - remove window after use?

[David Reitter]

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.

Re: completions - remove window after use?

[Stefan Monnier]

> 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

Re: completions - remove window after use?

[Richard Stallman]

    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?

Re: completions - remove window after use?

[Xavier Maillard]

   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

Re: completions - remove window after use?

[martin rudalics]

 > 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

bug#4914: completions - remove window after use?

[David Reitter]

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


On Nov 12, 2009, at 3:19 AM, martin rudalics wrote:

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


I reproduce this with a current build, with emacs -nw -Q.

When reverting to revision e78283bb (Tue Aug 18, just before minibuffer-hide-completions was introduced), the problem goes away and the *Completions* buffer continuous to be shown in the extra window.
I think it's now burying the buffer, but doesn't delete the window.

Again, the desired behavior would be to remove windows (or frames) that were created to display the *Completions* buffer rather than to leave them visible.

bug#4914: completions - remove window after use?

[martin rudalics]

 > When reverting to revision e78283bb (Tue Aug 18, just before
 > minibuffer-hide-completions was introduced), the problem goes away and
 > the *Completions* buffer continuous to be shown in the extra window.
 > I think it's now burying the buffer, but doesn't delete the window.

I wasn't aware of that.  Is the new behavior anywhere documented?

 > Again, the desired behavior would be to remove windows (or frames)
 > that were created to display the *Completions* buffer rather than to
 > leave them visible.

Deleting the window isn't necessarily the right thing either - think of
the case where displaying the *completions* buffer reuses an existing
window instead of popping up a new one.  I'm currently experimenting
with a generic solution for this problem.

martin

bug#4914: completions - remove window after use?

[David Reitter]

On Nov 12, 2009, at 12:40 PM, martin rudalics wrote:
> > Again, the desired behavior would be to remove windows (or frames)
> > that were created to display the *Completions* buffer rather than to
> > leave them visible.
> 
> Deleting the window isn't necessarily the right thing either - think of
> the case where displaying the *completions* buffer reuses an existing
> window instead of popping up a new one.  I'm currently experimenting
> with a generic solution for this problem.

That would be good.  Quite generally, those windows/frames that are created (e.g. via pop-to-buffer) for a specific window should be removed after we're done with the interaction (see also quit-window).   I've had a kludge for this in Aquamacs for a long time (via an advice to bury-buffer), but it's quite difficult to do consistently when Emacs and 3rd-part packages aren't aware that this is happening.

Are dedicated windows the way to go?

bug#4914: completions - remove window after use?

[martin rudalics]

 > That would be good.  Quite generally, those windows/frames that are
 > created (e.g. via pop-to-buffer) for a specific window should be
 > removed after we're done with the interaction (see also quit-window).
 > I've had a kludge for this in Aquamacs for a long time (via an advice
 > to bury-buffer), but it's quite difficult to do consistently when
 > Emacs and 3rd-part packages aren't aware that this is happening.

It's practically impossible to find a solution that satisfies all needs
in this area.  Basically, `display-buffer' would set a special slot for
any window it pops up and `quit-window' would try to delete a window if
it has that slot set and still shows the argument of `display-buffer'.

The more difficult part is what to do when `display-buffer' has reused
an existing window.  In that case quitting that window should display
the previous buffer with the old start position and the old point.  All
these values would have to be recorded in the window structure and in
saved window configurations.  Now once we have all these values we could
have `bury-buffer' use them instead of doing a `switch-to-buffer' but
that's too tricky for the moment.

 > Are dedicated windows the way to go?

The completions window could be dedicated so `quit-window' would
automatically delete it.  Windows that may live longer should generally
not be dedicated.

martin

bug#4914: completions - remove window after use?

[Stefan Monnier]

>> That would be good.  Quite generally, those windows/frames that are
>> created (e.g. via pop-to-buffer) for a specific window should be
>> removed after we're done with the interaction (see also quit-window).
>> I've had a kludge for this in Aquamacs for a long time (via an advice
>> to bury-buffer), but it's quite difficult to do consistently when
>> Emacs and 3rd-part packages aren't aware that this is happening.

> It's practically impossible to find a solution that satisfies all needs
> in this area.  Basically, `display-buffer' would set a special slot for
> any window it pops up and `quit-window' would try to delete a window if
> it has that slot set and still shows the argument of `display-buffer'.

How 'bout the patch below?


        Stefan "whose .emacs would have
                (setq display-buffer-mark-dedicated 'soft)"


Index: lisp/minibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v
retrieving revision 1.96
diff -u -r1.96 minibuffer.el
--- lisp/minibuffer.el	12 Nov 2009 23:10:06 -0000	1.96
+++ lisp/minibuffer.el	17 Nov 2009 22:56:12 -0000
@@ -965,9 +965,14 @@
     (if (and completions
              (or (consp (cdr completions))
                  (not (equal (car completions) string))))
-        (with-output-to-temp-buffer "*Completions*"
           (let* ((last (last completions))
-                 (base-size (cdr last)))
+               (base-size (cdr last))
+               ;; If the *Completions* buffer is shown in a new
+               ;; window, mark it as softly-dedicated, so bury-buffer in
+               ;; minibuffer-hide-completions will know whether to
+               ;; delete the window or not.
+               (display-buffer-mark-dedicated 'soft))
+          (with-output-to-temp-buffer "*Completions*"
             ;; Remove the base-size tail because `sort' requires a properly
             ;; nil-terminated list.
             (when last (setcdr last nil))
Index: lisp/window.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/window.el,v
retrieving revision 1.185
diff -u -r1.185 window.el
--- lisp/window.el	13 Nov 2009 22:19:56 -0000	1.185
+++ lisp/window.el	17 Nov 2009 22:56:12 -0000
@@ -1042,6 +1042,11 @@
     (set-window-buffer window buffer)
     (window--display-buffer-1 window)))
 
+(defvar display-buffer-mark-dedicated nil
+  "If non-nil, `display-buffer' marks the windows it creates as dedicated.
+The actual non-nil value of this variable will be copied to the
+`window-dedicated-p' flag.")
+
 (defun display-buffer (buffer-or-name &optional not-this-window frame)
   "Make buffer BUFFER-OR-NAME appear in some window but don't select it.
 BUFFER-OR-NAME must be a buffer or the name of an existing
@@ -1133,8 +1133,10 @@
 			buffer (if (listp pars) pars))))))
      ((or use-pop-up-frames (not frame-to-use))
       ;; We want or need a new frame.
-      (window--display-buffer-2
-       buffer (frame-selected-window (funcall pop-up-frame-function))))
+      (let ((win (frame-selected-window (funcall pop-up-frame-function))))
+        (when display-buffer-mark-dedicated
+          (set-window-dedicated-p win display-buffer-mark-dedicated))
+        (window--display-buffer-2 buffer win)))
      ((and pop-up-windows
 	   ;; Make a new window.
 	   (or (not (frame-parameter frame-to-use 'unsplittable))
@@ -1149,8 +1149,10 @@
 		 (or (window--try-to-split-window
 		      (get-largest-window frame-to-use t))
 		     (window--try-to-split-window
-		      (get-lru-window frame-to-use t))))
-	   (window--display-buffer-2 buffer window-to-use)))
+		      (get-lru-window frame-to-use t)))))
+      (when display-buffer-mark-dedicated
+        (set-window-dedicated-p window-to-use display-buffer-mark-dedicated))
+      (window--display-buffer-2 buffer window-to-use))
      ((let ((window-to-undedicate
 	     ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate
 	     ;; the selected window to its buffer, to avoid that some of

bug#4914: completions - remove window after use?

[martin rudalics]

 >> It's practically impossible to find a solution that satisfies all needs
 >> in this area.  Basically, `display-buffer' would set a special slot for
 >> any window it pops up and `quit-window' would try to delete a window if
 >> it has that slot set and still shows the argument of `display-buffer'.
 >
 > How 'bout the patch below?
 >
 >
 >         Stefan "whose .emacs would have
 >                 (setq display-buffer-mark-dedicated 'soft)"

This reveals a general problem with all `display-buffer' related (and
maybe all) options.  We really should settle on a policy that strictly
separates user provided settings from application provided ones.  In
particular

 > +               ;; If the *Completions* buffer is shown in a new
 > +               ;; window, mark it as softly-dedicated, so bury-buffer in
 > +               ;; minibuffer-hide-completions will know whether to
 > +               ;; delete the window or not.
 > +               (display-buffer-mark-dedicated 'soft))
 > +          (with-output-to-temp-buffer "*Completions*"
 >              ;; Remove the base-size tail because `sort' requires a properly
 >              ;; nil-terminated list.
 >              (when last (setcdr last nil))

overrides the intentions of a user who has an explicit

(setq display-buffer-mark-dedicated nil)

in her .emacs.  Also I suppose that with your .emacs `display-buffer'
won't be able to reuse a window it popped up earlier for displaying
another buffer.  In the case at hand this would prevent the Completions
window's contents getting overwritten by those of some other buffer
which is good.  But in general this might be a bad idea leading to "more
important" windows getting reused and/or new windows and frames popped
up all the time.

Also note that the greater problem is still how to "correctly" quit a
window that has been reused (instead of popped up) by `display-buffer'.

martin

bug#4914: completions - remove window after use?

[David Reitter]

On Nov 17, 2009, at 6:00 PM, Stefan Monnier wrote:
> How 'bout the patch below?
>                (setq display-buffer-mark-dedicated 'soft)"

Didn't work that well for me - the window doesn't disappear. Perhaps the other bug (switching away from *Completions*) would need to be fixed first.

bug#4914: completions - remove window after use?

[Stefan Monnier]

> Are dedicated windows the way to go?

Yes, soft-dedicated windows might be the way to go.
But the change you refer to (in revision e78283bb, whatever that is) was
not intentional, so we could/should start by fixing that change.


        Stefan

bug#4914: completions - remove window after use?

[Chong Yidong]

> > 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 reproduce this with a current build, with emacs -nw -Q.

Do you still see this bug?  I think it's been fixed for a while now (at
least I don't experience it).

bug#4914: completions - remove window after use?

[David Reitter]

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

On Jan 18, 2010, at 10:07 AM, David Reitter wrote:

> I recall the general case being discussed but not addressed (closing windows which have popped open just for a specific buffer), but I'll file a separate report when I observe a striking example.

Actually, it seems to be working:  C-h f foo RET C-x o C-x k RET pops up and removes the window,  iff (eq display-buffer-mark-dedicated 'soft).  I guess that was Stefan's patch.  Very nice.  I can get rid of my kill-buffer kludges now.  Thanks again.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

bug#4914: marked as done (completions - remove window after use?)

[Emacs bug Tracking System]

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

Your message dated Mon, 18 Jan 2010 10:07:53 -0500
with message-id <5C420BAC-187B-4B19-BF13-CC1A71745D59@gmail.com>
and subject line Re: completions - remove window after use?
has caused the Emacs bug report #4914,
regarding completions - remove window after use?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
4914: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4914
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 4705 bytes --]

From: David Reitter <david.reitter@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: Re: completions - remove window after use?
Date: Thu, 12 Nov 2009 08:31:52 -0500
Message-ID: <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com>

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


On Nov 12, 2009, at 3:19 AM, martin rudalics wrote:

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


I reproduce this with a current build, with emacs -nw -Q.

When reverting to revision e78283bb (Tue Aug 18, just before minibuffer-hide-completions was introduced), the problem goes away and the *Completions* buffer continuous to be shown in the extra window.
I think it's now burying the buffer, but doesn't delete the window.

Again, the desired behavior would be to remove windows (or frames) that were created to display the *Completions* buffer rather than to leave them visible.

[-- Attachment #3: Type: message/rfc822, Size: 4369 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 412 bytes --]

On Jan 17, 2010, at 6:41 PM, Chong Yidong wrote:
> Do you still see this bug?  I think it's been fixed for a while now (at
> least I don't experience it).

Yes, this particular case has been fixed, thank you. 

I recall the general case being discussed but not addressed (closing windows which have popped open just for a specific buffer), but I'll file a separate report when I observe a striking example.

[-- Attachment #3.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: completions - remove window after use?

[Xavier Maillard]

    > 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