* bug#19355: 25.0.50; limit the popup window height
@ 2014-12-12 1:49 Leo Liu
2014-12-12 12:45 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-12 1:49 UTC (permalink / raw)
To: 19355; +Cc: Juri Linkov
The popup window from, for example, minibuffer-completion-help, can be
so tall that the main editing window is squeezed to a few lines which
has the unfortunate side-effect of moving point, pushing some buffer
text out of the window. This is quite an annoyance. To see this:
1. Find an elisp file, with the form under edit centred around the
window.
2. Try complete for `(s' and assume the window split will be done
vertically.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-12 1:49 bug#19355: 25.0.50; limit the popup window height Leo Liu
@ 2014-12-12 12:45 ` martin rudalics
2014-12-12 13:05 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-12 12:45 UTC (permalink / raw)
To: Leo Liu, 19355; +Cc: Juri Linkov
> The popup window from, for example, minibuffer-completion-help, can be
> so tall that the main editing window is squeezed to a few lines
This number of lines is specified by `window-min-height'.
> which
> has the unfortunate side-effect of moving point, pushing some buffer
> text out of the window. This is quite an annoyance. To see this:
>
> 1. Find an elisp file, with the form under edit centred around the
> window.
>
> 2. Try complete for `(s' and assume the window split will be done
> vertically.
We can add the MAX/MIN-HEIGHT/WIDTH arguments of `fit-window-to-buffer'
to the alist entries recognized by `display-buffer'. Then
`minibuffer-completion-help' and friends could set them in a way we'd
have to choose yet. Or we make these globally customizable.
I'm currently rewriting the code for *Completions* windows to make sure
they don't get obscured by an expanding minibuffer window. If you have
a good proposal I can make the necessary changes right away.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-12 12:45 ` martin rudalics
@ 2014-12-12 13:05 ` Leo Liu
2014-12-12 17:19 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-12 13:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, Juri Linkov
On 2014-12-12 13:45 +0100, martin rudalics wrote:
> I'm currently rewriting the code for *Completions* windows to make sure
> they don't get obscured by an expanding minibuffer window. If you have
> a good proposal I can make the necessary changes right away.
Are we talking about the same thing? I am worrying about *Completions*
buffer and the like obscuring my working buffer.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-12 13:05 ` Leo Liu
@ 2014-12-12 17:19 ` martin rudalics
2014-12-13 0:17 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-12 17:19 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355, Juri Linkov
>> I'm currently rewriting the code for *Completions* windows to make sure
>> they don't get obscured by an expanding minibuffer window. If you have
>> a good proposal I can make the necessary changes right away.
>
> Are we talking about the same thing? I am worrying about *Completions*
> buffer and the like obscuring my working buffer.
I'm fixing `with-displayed-buffer-window' and `fit-window-to-buffer' for
displaying *Completions* from `minibuffer-completion-help'. So if you
have a proposal pertinent to the latter tell me so ASAP. In that case I
can make a concerted change without having to reexamine code first.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-12 17:19 ` martin rudalics
@ 2014-12-13 0:17 ` Leo Liu
2014-12-13 10:21 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-13 0:17 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, Juri Linkov
On 2014-12-12 18:19 +0100, martin rudalics wrote:
> I'm fixing `with-displayed-buffer-window' and `fit-window-to-buffer' for
> displaying *Completions* from `minibuffer-completion-help'. So if you
> have a proposal pertinent to the latter tell me so ASAP. In that case I
> can make a concerted change without having to reexamine code first.
Thanks for the clarification. We are on the same page. I don't have
anything specific to add. Just want to point out that
fit-window-to-buffer is probably not the cause for this specific bug.
The contents of the elisp buffer can be a few windowful and I am still
seeing it being squeezed to 4 lines.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-13 0:17 ` Leo Liu
@ 2014-12-13 10:21 ` martin rudalics
2014-12-13 14:41 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-13 10:21 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355, Juri Linkov
> Thanks for the clarification. We are on the same page. I don't have
> anything specific to add. Just want to point out that
> fit-window-to-buffer is probably not the cause for this specific bug.
> The contents of the elisp buffer can be a few windowful and I am still
> seeing it being squeezed to 4 lines.
There's no specific bug here. What you report can be easily considered
a user error like choosing a too broad base for completions or failing
to appropriately customize the option `window-min-height'.
But even if we decide that Emacs made a bad choice when making the
*Completions* that large we'd have to decide which heuristics we want to
apply instead, like
- use `shrink-window-if-larger-than-buffer' instead of
`fit-window-to-buffer',
- explicitly pass a hardocded maximum height/width argument to
`fit-window-to-buffer' (requires some minor changes to
`with-displayed-buffer-window')
- add some options that allow users to specify the minimum and maximum
sizes of _any_ window resized by `fit-window-to-buffer',
- tell users that they should customize `display-buffer' appropriately
(in this case `with-displayed-buffer-window' would have to do much
more work than it does now).
In any case, if you want the present behavior to change, you have to
express what you want Emacs to do instead ;-)
As an aside, I observe that displaying the *Completions* window
currently induces three calls to `fit-window-to-buffer' which aren't
that cheap, especially when the buffer is large.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-13 10:21 ` martin rudalics
@ 2014-12-13 14:41 ` Leo Liu
2014-12-13 20:03 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-13 14:41 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, Juri Linkov
On 2014-12-13 11:21 +0100, martin rudalics wrote:
> There's no specific bug here. What you report can be easily considered
> a user error like choosing a too broad base for completions or failing
> to appropriately customize the option `window-min-height'.
Try emacs 24.4 and compare. I think it is a bug.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-13 14:41 ` Leo Liu
@ 2014-12-13 20:03 ` martin rudalics
2014-12-14 0:37 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-13 20:03 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355, Juri Linkov
> Try emacs 24.4 and compare. I think it is a bug.
You're right. The behavior changed completely. Could you try to
replace in `minibuffer-completion-help' the form
(window-height . fit-window-to-buffer)
with
,(when temp-buffer-resize-mode
'(window-height . resize-temp-buffer-window))
and test whether it restores the old behavior (with
`temp-buffer-resize-mode' en- and disabled)?
Thanks, martin
^ permalink raw reply [flat|nested] 20+ messages in thread* bug#19355: 25.0.50; limit the popup window height
2014-12-13 20:03 ` martin rudalics
@ 2014-12-14 0:37 ` Leo Liu
2014-12-14 9:03 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-14 0:37 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, Juri Linkov
On 2014-12-13 21:03 +0100, martin rudalics wrote:
> ,(when temp-buffer-resize-mode
> '(window-height . resize-temp-buffer-window))
>
> and test whether it restores the old behavior (with
> `temp-buffer-resize-mode' en- and disabled)?
No.
I think they all use fit-window-to-buffer underneath so it will take up
as much height as possible.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-14 0:37 ` Leo Liu
@ 2014-12-14 9:03 ` martin rudalics
2014-12-17 0:43 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-14 9:03 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355, Juri Linkov
>> ,(when temp-buffer-resize-mode
>> '(window-height . resize-temp-buffer-window))
>>
>> and test whether it restores the old behavior (with
>> `temp-buffer-resize-mode' en- and disabled)?
>
> No.
Interesting. Suppose with (my not so up-to-date version of trunk's)
emacs -Q I do
C-h f set- RET
my *scratch* window is split into two equally sized windows and the
lowest line of the lower window ends with set-charset-priority. If I do
C-h f set-window- RET
I get an empty last line in the lower window with set-window-vscroll on
the line before and with
C-h f set-window-d RET
I get lots of empty lines with set-window-dot as last displayed entry.
Now if with emacs -Q I evaluate
(setq temp-buffer-resize-mode t)
first and do the same steps as above, the first one is identical and in
the other two cases the empty lines get removed and the window shrinks.
Please have another look.
> I think they all use fit-window-to-buffer underneath so it will take up
> as much height as possible.
`resize-temp-buffer-window' limits this to `temp-buffer-max-height'
lines.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-14 9:03 ` martin rudalics
@ 2014-12-17 0:43 ` Leo Liu
2014-12-17 7:08 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-17 0:43 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, Juri Linkov
On 2014-12-14 10:03 +0100, martin rudalics wrote:
> first and do the same steps as above, the first one is identical and in
> the other two cases the empty lines get removed and the window shrinks.
>
> Please have another look.
I got the same thing with or without temp-buffer-resize-mode.
My concern is with something similar to the first experiment i.e. C-h f
set- TAB. What we see in C-h f set- TAB is not problematic because point
is in the minibuffer and the popup doesn't move it around.
The problematic case is when I am developing an elisp program in a
window and do a completion-at-point for `(set-'. The popup takes up so
much height that it often changes view in my editing buffer, i.e. move
point to close to the top of the frame, push some buffer contents out of
view etc.
I.e. Change
+--------
|
|
|_
|
|
|
+--------
to
+--------
|_
+--------
|
|
|
|
+--------
where _ is point. When the popup goes away (*Completions* goes away
after some command.), my window view now looks like:
+--------
|_
|
|
|
|
|
+--------
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-17 0:43 ` Leo Liu
@ 2014-12-17 7:08 ` martin rudalics
2014-12-19 23:10 ` Leo Liu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-17 7:08 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355, Juri Linkov
> I got the same thing with or without temp-buffer-resize-mode.
[...]
> The problematic case is when I am developing an elisp program in a
> window and do a completion-at-point for `(set-'. The popup takes up so
> much height that it often changes view in my editing buffer, i.e. move
> point to close to the top of the frame, push some buffer contents out of
> view etc.
[...]
I think I understand your problem but I don't understand how you can
still see it after the change I proposed. Are you sure you applied it
and recompiled the associated functions? If so, and the problem
persists, then please try to find out (1) why `fit-window-to-buffer'
apparently still gets called even if `temp-buffer-resize-mode' is off
and (2) why apparently `temp-buffer-max-width' is not observed when
`temp-buffer-resize-mode' is on. (In both cases I usually find it best
to re-evaluate the involved files, edebug `fit-window-to-buffer' /
`resize-temp-buffer-window' and get a backtrace to find out how they got
called.)
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-17 7:08 ` martin rudalics
@ 2014-12-19 23:10 ` Leo Liu
2014-12-25 10:35 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Leo Liu @ 2014-12-19 23:10 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355
On 2014-12-17 15:08 +0800, martin rudalics wrote:
> I think I understand your problem but I don't understand how you can
> still see it after the change I proposed. Are you sure you applied it
> and recompiled the associated functions? If so, and the problem
> persists, then please try to find out (1) why `fit-window-to-buffer'
> apparently still gets called even if `temp-buffer-resize-mode' is off
> and (2) why apparently `temp-buffer-max-width' is not observed when
> `temp-buffer-resize-mode' is on. (In both cases I usually find it best
> to re-evaluate the involved files, edebug `fit-window-to-buffer' /
> `resize-temp-buffer-window' and get a backtrace to find out how they got
> called.)
Thanks. the harddisk of my workstation faulted, so I was moving to a new
iMac. Re-built trunk without GUI and the problem seemed to be gone.
Leo
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-19 23:10 ` Leo Liu
@ 2014-12-25 10:35 ` martin rudalics
2014-12-25 20:01 ` Juri Linkov
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-25 10:35 UTC (permalink / raw)
To: Leo Liu; +Cc: 19355-done
> Thanks. the harddisk of my workstation faulted, so I was moving to a new
> iMac. Re-built trunk without GUI and the problem seemed to be gone.
OK. Closing.
Thanks, martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-25 10:35 ` martin rudalics
@ 2014-12-25 20:01 ` Juri Linkov
2014-12-26 9:13 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Juri Linkov @ 2014-12-25 20:01 UTC (permalink / raw)
To: 19355; +Cc: sdl.web
>> Thanks. the harddisk of my workstation faulted, so I was moving to a new
>> iMac. Re-built trunk without GUI and the problem seemed to be gone.
>
> OK. Closing.
I tried your fixes now, and I see all improvements, but there is one thing
that doesn't look good. The *Completions* buffer doesn't shrink anymore
if the window is larger than the buffer, e.g. after `M-x z TAB' now
it leaves too much empty unused screen space instead of shrinking.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-25 20:01 ` Juri Linkov
@ 2014-12-26 9:13 ` martin rudalics
2014-12-27 0:57 ` Juri Linkov
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-26 9:13 UTC (permalink / raw)
To: Juri Linkov, 19355; +Cc: sdl.web
> I tried your fixes now, and I see all improvements, but there is one thing
> that doesn't look good. The *Completions* buffer doesn't shrink anymore
> if the window is larger than the buffer, e.g. after `M-x z TAB' now
> it leaves too much empty unused screen space instead of shrinking.
Add (require 'zotelo) and (require 'zeal-at-point) to your .emacs to
make this look more behaved ;-)
In fact, the present behavior is that of Emacs 24.4 and that's what Leo
Liu asked for in this thread. Unfortunately, nobody stepped forward to
say that the pure `fit-window-to-buffer' behavior you implemented was
better. I think it was - but I hardly count since I practically always
use in-line completion.
So now people have to activate `temp-buffer-resize-mode' again in order
to make this work in your sense. Unless you find a better solution.
martin
BTW: IIUC `with-displayed-buffer-window' may call `fit-window-to-buffer'
up to three times now. Couldn't we cut that down a bit?
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-26 9:13 ` martin rudalics
@ 2014-12-27 0:57 ` Juri Linkov
2014-12-30 10:15 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Juri Linkov @ 2014-12-27 0:57 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, sdl.web
> BTW: IIUC `with-displayed-buffer-window' may call `fit-window-to-buffer'
> up to three times now. Couldn't we cut that down a bit?
I removed the duplicate calls now in the commit 162660c.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-27 0:57 ` Juri Linkov
@ 2014-12-30 10:15 ` martin rudalics
2014-12-31 0:03 ` Juri Linkov
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2014-12-30 10:15 UTC (permalink / raw)
To: Juri Linkov; +Cc: 19355, sdl.web
> I removed the duplicate calls now in the commit 162660c.
Thanks. Would it make sense to select the window around BODY in
`with-displayed-buffer-window'? Though I suppose this hardly makes
sense because (1) its buffer should never appear in two windows at the
same time (and so `get-buffer-window' should work anyway) and (2) BODY
might want to refer to the "real" selected window.
Note that I now documented `with-current-buffer-window' and
`with-displayed-buffer-window' in the Elisp manual together with
`temp-buffer-resize-mode'. Please have a look.
Maybe we should enable `temp-buffer-resize-mode' by default. But IIRC
some people didn't like it.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19355: 25.0.50; limit the popup window height
2014-12-30 10:15 ` martin rudalics
@ 2014-12-31 0:03 ` Juri Linkov
2014-12-31 18:38 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Juri Linkov @ 2014-12-31 0:03 UTC (permalink / raw)
To: martin rudalics; +Cc: 19355, sdl.web
> Note that I now documented `with-current-buffer-window' and
> `with-displayed-buffer-window' in the Elisp manual together with
> `temp-buffer-resize-mode'. Please have a look.
Thank you! I looked at your changes to confirm everything is all right.
> Maybe we should enable `temp-buffer-resize-mode' by default. But IIRC
> some people didn't like it.
It seems this is a good idea to enable `temp-buffer-resize-mode'.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-12-31 18:38 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-12 1:49 bug#19355: 25.0.50; limit the popup window height Leo Liu
2014-12-12 12:45 ` martin rudalics
2014-12-12 13:05 ` Leo Liu
2014-12-12 17:19 ` martin rudalics
2014-12-13 0:17 ` Leo Liu
2014-12-13 10:21 ` martin rudalics
2014-12-13 14:41 ` Leo Liu
2014-12-13 20:03 ` martin rudalics
2014-12-14 0:37 ` Leo Liu
2014-12-14 9:03 ` martin rudalics
2014-12-17 0:43 ` Leo Liu
2014-12-17 7:08 ` martin rudalics
2014-12-19 23:10 ` Leo Liu
2014-12-25 10:35 ` martin rudalics
2014-12-25 20:01 ` Juri Linkov
2014-12-26 9:13 ` martin rudalics
2014-12-27 0:57 ` Juri Linkov
2014-12-30 10:15 ` martin rudalics
2014-12-31 0:03 ` Juri Linkov
2014-12-31 18:38 ` martin rudalics
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).