unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Completion: minibuffer.el vs comint.el
@ 2010-11-14 16:44 Андрей Парамонов
  0 siblings, 0 replies; 7+ messages in thread
From: Андрей Парамонов @ 2010-11-14 16:44 UTC (permalink / raw)
  To: emacs-devel; +Cc: martin rudalics

Hello!

I'm investigating possibilities to use Emacs Python IDE. Before I used
Emacs for writing programs in R language, with the help of ESS
package. Both ESS mode and Python mode have helper inferior modes to
interact with interpreter. Also, both have very decent completion.

I've found out that ESS mode completion works via comint.el 's
comint-dynamic-complete, while Python mode (and, in fact, the majority
of modes including Emacs Lisp mode and Semantic) completion works via
minibuffer.el 's completion-at-point. Why bother, may you ask? In
fact, I would never bother about internals and even wouldn't notice
any difference if not subtle, but extremely annoying detail. It's
about how display-buffer acts in presence of *Completions* buffer.

To reproduce:

0) Make sure pop-up-frames is nil (the default).

1) comint.el completion (this required you to press a key in the
middle of program -- it there a way to make this testcase fully
automated?):

(global-set-key [(f12)] '(lambda() (interactive)
			   (progn
			     (if (window-dedicated-p (get-buffer-window "*Completions*"))
				 (message "*Completions* is dedicated")
			       (message "*Completions* is NOT dedicated"))
			     (display-buffer "bar" t))))

(require 'comint)
(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (comint-dynamic-list-completions (list "alice" "anastasia" "anna"))
  ;; The following display-buffer call is impossible because we want
  ;; to display-buffer while *Completions* is visible. Press F12.
  ;; (display-buffer bar t)
  )

On pressing F12, you will see buffer "bar" open in place of
*Completions* window. This is the expected thing, actually.

2) minibuffer.el completion:

(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (emacs-lisp-mode)
  (insert "(a")
  (completion-at-point)
  (if (window-dedicated-p (get-buffer-window "*Completions*"))
      (message "*Completions* is dedicated")
    (message "*Completions* is NOT dedicated"))
  (display-buffer bar t))

You will see buffer "bar" open in a new frame despite pop-up-frames
being nil (documentation says: if nil, never make a separate frame!).
Also you will see why it happens: *Completions* window is "dedicated".
This is damn annoying!

I have limited experience in elisp so I can't understand why and where
*Completions* buffer becomes dedicated (set-window-dedicated-p is a
built-in function in `C source code' -- is there a way to set a
breakpoint for it?). If it's intentional, is there a reason for it?
comint.el doesn't set "dedicated" flag, and seems to work just fine.

See also debbugs.gnu.org/7368 .

Best wishes,
Andrey Paramonov



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

* Re: Completion: minibuffer.el vs comint.el
       [not found] <20101114173358.683A6628353@mail.cs.ucr.edu>
@ 2010-11-15 21:56 ` Andrew Helsley
  2011-03-28 14:11   ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Andrew Helsley @ 2010-11-15 21:56 UTC (permalink / raw)
  To: emacs-devel

Hi,

I think it may become dedicated in the function `minibuffer-completion-help'
in `minibuffer.el'. Notice the local binding of the variable 
`display-buffer-mark-dedicated'.  From the documentation of the variable:

 	If non-nil, `display-buffer' marks the windows it creates as dedicated.

`display-buffer' itself is called from the `with-output-to-temp-buffer' C
function (at least that is what `with-output-...'s docs suggest).

Unfortunately as for intent/reason behind this behavior, I don't have a clue.
There are some comments in the `minibuffer-completion-help' function that may
provide further insight.  Hopefully seeing where it makes the window dedicated
can help you find your reason or reasonably conclude that it can be safely be
changed to be more like comint.el.

--------
regards,
Andy


On Sun, 14 Nov 2010, cmr.pent@gmail.com wrote:

> Date: Sun, 14 Nov 2010 19:44:52 +0300
> From: ?????? ????????? 	<cmr.pent@gmail.com>
> Subject: Completion: minibuffer.el vs comint.el
> To: emacs-devel@gnu.org
> Cc: martin rudalics <rudalics@gmx.at>
> Message-ID:
> 	<AANLkTinrm12uLLEMbhb1yxRbzB+zQs77P0=m-Kiq84nE@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello!
>
> I'm investigating possibilities to use Emacs Python IDE. Before I used
> Emacs for writing programs in R language, with the help of ESS
> package. Both ESS mode and Python mode have helper inferior modes to
> interact with interpreter. Also, both have very decent completion.
>
> I've found out that ESS mode completion works via comint.el 's
> comint-dynamic-complete, while Python mode (and, in fact, the majority
> of modes including Emacs Lisp mode and Semantic) completion works via
> minibuffer.el 's completion-at-point. Why bother, may you ask? In
> fact, I would never bother about internals and even wouldn't notice
> any difference if not subtle, but extremely annoying detail. It's
> about how display-buffer acts in presence of *Completions* buffer.
>
> To reproduce:
>
> 0) Make sure pop-up-frames is nil (the default).
>
> 1) comint.el completion (this required you to press a key in the
> middle of program -- it there a way to make this testcase fully
> automated?):
>
> (global-set-key [(f12)] '(lambda() (interactive)
> 			   (progn
> 			     (if (window-dedicated-p (get-buffer-window "*Completions*"))
> 				 (message "*Completions* is dedicated")
> 			       (message "*Completions* is NOT dedicated"))
> 			     (display-buffer "bar" t))))
>
> (require 'comint)
> (let ((foo (get-buffer-create "foo"))
>      (bar (get-buffer-create "bar")))
>  (switch-to-buffer foo)
>  (delete-other-windows)
>  (comint-dynamic-list-completions (list "alice" "anastasia" "anna"))
>  ;; The following display-buffer call is impossible because we want
>  ;; to display-buffer while *Completions* is visible. Press F12.
>  ;; (display-buffer bar t)
>  )
>
> On pressing F12, you will see buffer "bar" open in place of
> *Completions* window. This is the expected thing, actually.
>
> 2) minibuffer.el completion:
>
> (let ((foo (get-buffer-create "foo"))
>      (bar (get-buffer-create "bar")))
>  (switch-to-buffer foo)
>  (delete-other-windows)
>  (emacs-lisp-mode)
>  (insert "(a")
>  (completion-at-point)
>  (if (window-dedicated-p (get-buffer-window "*Completions*"))
>      (message "*Completions* is dedicated")
>    (message "*Completions* is NOT dedicated"))
>  (display-buffer bar t))
>
> You will see buffer "bar" open in a new frame despite pop-up-frames
> being nil (documentation says: if nil, never make a separate frame!).
> Also you will see why it happens: *Completions* window is "dedicated".
> This is damn annoying!
>
> I have limited experience in elisp so I can't understand why and where
> *Completions* buffer becomes dedicated (set-window-dedicated-p is a
> built-in function in `C source code' -- is there a way to set a
> breakpoint for it?). If it's intentional, is there a reason for it?
> comint.el doesn't set "dedicated" flag, and seems to work just fine.
>
> See also debbugs.gnu.org/7368 .
>
> Best wishes,
> Andrey Paramonov
>
>
>
> ------------------------------
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>



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

* Re: Completion: minibuffer.el vs comint.el
  2010-11-15 21:56 ` Completion: minibuffer.el vs comint.el Andrew Helsley
@ 2011-03-28 14:11   ` Stefan Monnier
  2011-03-29  9:14     ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2011-03-28 14:11 UTC (permalink / raw)
  To: Andrew Helsley; +Cc: emacs-devel

> I think it may become dedicated in the function `minibuffer-completion-help'
> in `minibuffer.el'. Notice the local binding of the variable
> display-buffer-mark-dedicated'.  From the documentation of the variable:

> 	If non-nil, `display-buffer' marks the windows it creates as dedicated.

> `display-buffer' itself is called from the `with-output-to-temp-buffer' C
> function (at least that is what `with-output-...'s docs suggest).

> Unfortunately as for intent/reason behind this behavior, I don't have
> a clue.

This is so as to know whether to delete the window when the *Completions*
buffer is hidden/buried.

Maybe we should use another approach (hi Martin ;-).  E.g. just add
a flag "created for *Completions*" when we create the window, that would
work similarly to `dedicated' w.r.t bury-buffer but which would not
prevent display-buffer from reusing that window for some other buffer.


        Stefan



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

* Re: Completion: minibuffer.el vs comint.el
  2011-03-28 14:11   ` Stefan Monnier
@ 2011-03-29  9:14     ` martin rudalics
  2011-03-29 13:39       ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2011-03-29  9:14 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andrew Helsley, emacs-devel

>> I think it may become dedicated in the function `minibuffer-completion-help'
>> in `minibuffer.el'. Notice the local binding of the variable
>> display-buffer-mark-dedicated'.  From the documentation of the variable:
>
>> 	If non-nil, `display-buffer' marks the windows it creates as dedicated.
>
>> `display-buffer' itself is called from the `with-output-to-temp-buffer' C
>> function (at least that is what `with-output-...'s docs suggest).
>
>> Unfortunately as for intent/reason behind this behavior, I don't have
>> a clue.
>
> This is so as to know whether to delete the window when the *Completions*
> buffer is hidden/buried.
>
> Maybe we should use another approach (hi Martin ;-).  E.g. just add
> a flag "created for *Completions*" when we create the window, that would
> work similarly to `dedicated' w.r.t bury-buffer but which would not
> prevent display-buffer from reusing that window for some other buffer.

The dedicated window method works well for displaying a buffer in a
separate frame or a new window.  It can't be used when a window is
reused for displaying the buffer.  In my branch `display-buffer' always
records the previous state and burying the buffer or quitting the window
conveniently restores the previous state.  So when you dedicate a window
to its buffer you exclusively do that because you do not want to display
another buffer in that window.

martin





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

* Re: Completion: minibuffer.el vs comint.el
  2011-03-29  9:14     ` martin rudalics
@ 2011-03-29 13:39       ` Stefan Monnier
  2011-03-29 15:18         ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2011-03-29 13:39 UTC (permalink / raw)
  To: martin rudalics; +Cc: Andrew Helsley, emacs-devel

> The dedicated window method works well for displaying a buffer in a
> separate frame or a new window.

But that's exactly what we do currently: mark the window dedicated if
and only if the window was created for this buffer.

> It can't be used when a window is reused for displaying the buffer.

Indeed we don't mark it dedicated when we reuse a window.

> In my branch `display-buffer' always records the previous state and
> burying the buffer or quitting the window conveniently restores the
> previous state.

Not sure what "state" this includes, so maybe it's a good idea, but
I haven't seen many complaints about the current behavior in this respect.


        Stefan



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

* Re: Completion: minibuffer.el vs comint.el
  2011-03-29 13:39       ` Stefan Monnier
@ 2011-03-29 15:18         ` martin rudalics
  2011-03-29 20:55           ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2011-03-29 15:18 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andrew Helsley, emacs-devel

 >> The dedicated window method works well for displaying a buffer in a
 >> separate frame or a new window.
 >
 > But that's exactly what we do currently: mark the window dedicated if
 > and only if the window was created for this buffer.
 >
 >> It can't be used when a window is reused for displaying the buffer.
 >
 > Indeed we don't mark it dedicated when we reuse a window.
 >
 >> In my branch `display-buffer' always records the previous state and
 >> burying the buffer or quitting the window conveniently restores the
 >> previous state.
 >
 > Not sure what "state" this includes, so maybe it's a good idea, but
 > I haven't seen many complaints about the current behavior in this respect.

The previous "state" for a reused window is that window's buffer, window
start, and window point at the time it was replaced by `display-buffer'.
This amounts to all the things we currently restore when quitting a help
window.

martin



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

* Re: Completion: minibuffer.el vs comint.el
  2011-03-29 15:18         ` martin rudalics
@ 2011-03-29 20:55           ` Stefan Monnier
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2011-03-29 20:55 UTC (permalink / raw)
  To: martin rudalics; +Cc: Andrew Helsley, emacs-devel

>> Not sure what "state" this includes, so maybe it's a good idea, but
>> I haven't seen many complaints about the current behavior in this respect.
> The previous "state" for a reused window is that window's buffer, window
> start, and window point at the time it was replaced by `display-buffer'.
> This amounts to all the things we currently restore when quitting a help
> window.

Window-start and window-point sound like good improvements over the
usual behavior of bury-buffer.


        Stefan



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

end of thread, other threads:[~2011-03-29 20:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20101114173358.683A6628353@mail.cs.ucr.edu>
2010-11-15 21:56 ` Completion: minibuffer.el vs comint.el Andrew Helsley
2011-03-28 14:11   ` Stefan Monnier
2011-03-29  9:14     ` martin rudalics
2011-03-29 13:39       ` Stefan Monnier
2011-03-29 15:18         ` martin rudalics
2011-03-29 20:55           ` Stefan Monnier
2010-11-14 16:44 Андрей Парамонов

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