bug#25055: 25.1.50; completion buffer changes window size

bug#25055: 25.1.50; completion buffer changes window size

[Tyler Smith]

To reproduce:

1. start emacs -Q
2. M-x shell
3. ls ./<tab><tab>
4. A temporary buffer pops up with all possible completions.
   - if your home directory is big enough, this buffer will take up a
   large portion of the frame
5. press <space>
6. The completions are dismissed, but the frame remains in its new
configuration, with 90% of the space taken up by the window where the
completions had been listed (this window has now returned to the
shell-mode buffer).

What I would expect to happen instead is that when the completions are
dismissed, the window configuration returns to the state it was in
before pressing tab: that is, the top half is the scratch buffer, the
bottom half is the shell-mode buffer.


Thanks,

Tyler


In GNU Emacs 25.1.50.3 (x86_64-pc-linux-gnu, GTK+ Version 3.22.2)
 of 2016-11-20 built on tardis
Repository revision: 3138598dd87d3578cee220436d1c7857a9aca896
Windowing system distributor 'The X.Org Foundation', version
11.0.11804000
System Description:     Debian GNU/Linux testing (stretch)

Configured using:
 'configure --with-x-toolkit=gtk'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_CA.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Complete, but not unique
Making completion list...
Complete, but not unique [2 times]
Making completion list...
Complete, but not unique [2 times]
Making completion list...
Complete, but not unique [2 times]
GNU Emacs 25.1.50.3 (x86_64-pc-linux-gnu, GTK+ Version 3.22.2) of
2016-11-20
You can run the command ‘emacs-version’ with M-x em-v RET
GNU Emacs 25.1.50.3 (x86_64-pc-linux-gnu, GTK+ Version 3.22.2) of
2016-11-20

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils shell pcomplete comint
ansi-color ring time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 92318 6553)
 (symbols 48 20433 0)
 (miscs 40 68 146)
 (strings 32 16444 4822)
 (string-bytes 1 471026)
 (vectors 16 12572)
 (vector-slots 8 441992 5013)
 (floats 8 168 188)
 (intervals 56 664 334)
 (buffers 976 22))

bug#25055: 25.1.50; completion buffer changes window size

[martin rudalics]

 > 1. start emacs -Q
 > 2. M-x shell
 > 3. ls ./<tab><tab>
 > 4. A temporary buffer pops up with all possible completions.
 >     - if your home directory is big enough, this buffer will take up a
 >     large portion of the frame
 > 5. press <space>
 > 6. The completions are dismissed, but the frame remains in its new
 > configuration, with 90% of the space taken up by the window where the
 > completions had been listed (this window has now returned to the
 > shell-mode buffer).
 >
 > What I would expect to happen instead is that when the completions are
 > dismissed, the window configuration returns to the state it was in
 > before pressing tab: that is, the top half is the scratch buffer, the
 > bottom half is the shell-mode buffer.

Annoying, indeed.  It happens because displaying completions is allowed
to steal space from all other windows in the same combination and there
is no easy way to automatically return the space to them unless you have
customized ‘window-combination-resize’ to t (if the latter doesn't annoy
you elsewhere, try it).  Maybe Juri has an idea.

martin

bug#25055: 25.1.50; completion buffer changes window size

[Juri Linkov]

> Annoying, indeed.  It happens because displaying completions is allowed
> to steal space from all other windows in the same combination and there
> is no easy way to automatically return the space to them unless you have
> customized ‘window-combination-resize’ to t (if the latter doesn't annoy
> you elsewhere, try it).  Maybe Juri has an idea.

Sorry, I still have no idea for this and for recent bug reported by Liu Hui
other than enabling ‘window-combination-resize’ by default.

bug#25055: 25.1.50; completion buffer changes window size

[martin rudalics]

 > 1. start emacs -Q
 > 2. M-x shell
 > 3. ls ./<tab><tab>
 > 4. A temporary buffer pops up with all possible completions.
 >     - if your home directory is big enough, this buffer will take up a
 >     large portion of the frame
 > 5. press <space>
 > 6. The completions are dismissed, but the frame remains in its new
 > configuration, with 90% of the space taken up by the window where the
 > completions had been listed (this window has now returned to the
 > shell-mode buffer).
 >
 > What I would expect to happen instead is that when the completions are
 > dismissed, the window configuration returns to the state it was in
 > before pressing tab: that is, the top half is the scratch buffer, the
 > bottom half is the shell-mode buffer.

The bugs leading to this behavior should have been fixed now on master
with commit

23d3eeb798c7edc27898b0dbd4c2364a6ca6247d

Note that to get the desired behavior you have to (1) recompile
window.el and after that (2) recompile all users of the macro
`with-displayed-buffer-window' - that is, the files minibuffer.el and
dired.el and finally (3) rebuild Emacs.

If for some reason you cannot build Emacs or work with master, please
tell me.  I'll then try to explain how to get the desired behavior with
Emacs 25 and your .emacs alone.  Meanwhile closing this bug.

Many thanks for the report, martin

bug#25055: 25.1.50; completion buffer changes window size

[Tyler Smith]

This fixes the problem at my end.

Many thanks!

Tyler

-- 
plantarum.ca

On Sat, Apr 15, 2017, at 10:49 AM, martin rudalics wrote:
>  > 1. start emacs -Q
>  > 2. M-x shell
>  > 3. ls ./<tab><tab>
>  > 4. A temporary buffer pops up with all possible completions.
>  >     - if your home directory is big enough, this buffer will take up a
>  >     large portion of the frame
>  > 5. press <space>
>  > 6. The completions are dismissed, but the frame remains in its new
>  > configuration, with 90% of the space taken up by the window where the
>  > completions had been listed (this window has now returned to the
>  > shell-mode buffer).
>  >
>  > What I would expect to happen instead is that when the completions are
>  > dismissed, the window configuration returns to the state it was in
>  > before pressing tab: that is, the top half is the scratch buffer, the
>  > bottom half is the shell-mode buffer.
> 
> The bugs leading to this behavior should have been fixed now on master
> with commit
> 
> 23d3eeb798c7edc27898b0dbd4c2364a6ca6247d
> 
> Note that to get the desired behavior you have to (1) recompile
> window.el and after that (2) recompile all users of the macro
> `with-displayed-buffer-window' - that is, the files minibuffer.el and
> dired.el and finally (3) rebuild Emacs.
> 
> If for some reason you cannot build Emacs or work with master, please
> tell me.  I'll then try to explain how to get the desired behavior with
> Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
> 
> Many thanks for the report, martin

bug#25055: 25.1.50; completion buffer changes window size

[Tyler Smith]

> On Sat, Apr 15, 2017, at 10:49 AM, martin rudalics wrote:
> > 
> > If for some reason you cannot build Emacs or work with master, please
> > tell me.  I'll then try to explain how to get the desired behavior with
> > Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
> > 

Sorry, I spoke too soon. I didn't use emacs -Q, and so forgot that I had
a work-around in my .emacs that hides the problem.

I can't currently compile the master branch. I checked out the latest
commit from github.  I had been using the emacs-25 branch previously,
and assumed the specific commands you suggested (recompile window.el et
al) would be taken care of by rebuilding the program completely.
However, `make` on its own complained:

make: *** No rule to make target 'lib/Makefile.am', needed by
'lib/Makefile.in'.  Stop.

So I ran 
./autogen.sh all
./configure
make

which failed with:

Loading macroexp.elc...
Wrong type argument: cl-slot-descriptor, [cl-struct-cl-slot-descriptor
parent-instance unbound eieio-instance-inheritor ((:documentation . "The
parent of this instance.
If a slot of this class is referenced, and is unbound, then the parent
is checked for a value."))]
Makefile:84: recipe for target
'../../lisp/cedet/semantic/bovine/c-by.el' failed
make[3]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Error 255
make[3]: Leaving directory
'/home/tws/research/programs/emacs-github/admin/grammars'
Makefile:358: recipe for target 'semantic' failed
make[2]: *** [semantic] Error 2
make[2]: Leaving directory
'/home/tws/research/programs/emacs-github/lisp'
Makefile:734: recipe for target '../lisp/loaddefs.el' failed
make[1]: *** [../lisp/loaddefs.el] Error 2
make[1]: Leaving directory
'/home/tws/research/programs/emacs-github/src'
Makefile:416: recipe for target 'src' failed
make: *** [src] Error 2

So I can't actually confirm that the bug is fixed or not. Assuming this
is just a transient issue in the master branch, I'm happy to wait and
try again later on. As I mentioned above I have a work-around that
smooths over this issue locally.

Best,

Tyler

bug#25055: 25.1.50; completion buffer changes window size

[npostavs]

Tyler Smith <tyler@plantarum.ca> writes:

>> On Sat, Apr 15, 2017, at 10:49 AM, martin rudalics wrote:
>> > 
>> > If for some reason you cannot build Emacs or work with master, please
>> > tell me.  I'll then try to explain how to get the desired behavior with
>> > Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
>> > 
>
> Sorry, I spoke too soon. I didn't use emacs -Q, and so forgot that I had
> a work-around in my .emacs that hides the problem.
>
> I can't currently compile the master branch. I checked out the latest
> commit from github.  I had been using the emacs-25 branch previously,
> and assumed the specific commands you suggested (recompile window.el et
> al) would be taken care of by rebuilding the program completely.
> However, `make` on its own complained:
>
> make: *** No rule to make target 'lib/Makefile.am', needed by
> 'lib/Makefile.in'.  Stop.
>
> So I ran 
> ./autogen.sh all
> ./configure
> make
>
> which failed with:
>
> Loading macroexp.elc...
> Wrong type argument: cl-slot-descriptor, [cl-struct-cl-slot-descriptor

Try with 'make bootstrap' instead of just plain 'make', possibly 'rm
Makefile lib/Makefile' would also be needed.

bug#25055: 25.1.50; completion buffer changes window size

[Tyler Smith]

On Wed, Apr 19, 2017, at 09:41 PM, npostavs@users.sourceforge.net wrote:
> Tyler Smith <tyler@plantarum.ca> writes:
> 
> >> On Sat, Apr 15, 2017, at 10:49 AM, martin rudalics wrote:
> >> > 
> >> > If for some reason you cannot build Emacs or work with master, please
> >> > tell me.  I'll then try to explain how to get the desired behavior with
> >> > Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
> >> > 
> >
> > Sorry, I spoke too soon. I didn't use emacs -Q, and so forgot that I had
> > a work-around in my .emacs that hides the problem.
> > 
> Try with 'make bootstrap' instead of just plain 'make'

That did it, thanks. And I can confirm the bug is squashed!

Best,

Tyler

bug#25055: 25.1.50; completion buffer changes window size

[martin rudalics]

 > That did it, thanks. And I can confirm the bug is squashed!

Thanks for testing (and for the report, obviously), martin

bug#25055: 25.1.50; completion buffer changes window size

[martin rudalics]

Noam,

since OT1H apparently nobody but you cares about these continuing "cl-"
hassles when building and OTOH we expect people to test bug fixes: What
would you recommend to tell them in the first place when asking them to
test a patch?  I'd like to use some standard text as

   Please note that Emacs master currently undergoes a restructuring
   process where a simple 'make' is often not sufficient for a build to
   succeed.  Hence, when your build fails with a message prefixed with
   "cl-", please try with 'make bootstrap' instead of just plain 'make',
   possibly 'rm Makefile lib/Makefile' would also be needed.

Or what would you recommend?

Thanks, martin

bug#25055: 25.1.50; completion buffer changes window size

[npostavs]

martin rudalics <rudalics@gmx.at> writes:

> Noam,
>
> since OT1H apparently nobody but you cares about these continuing "cl-"
> hassles when building and OTOH we expect people to test bug fixes: What
> would you recommend to tell them in the first place when asking them to
> test a patch?  I'd like to use some standard text as
>
>   Please note that Emacs master currently undergoes a restructuring
>   process where a simple 'make' is often not sufficient for a build to
>   succeed.  Hence, when your build fails with a message prefixed with
>   "cl-", please try with 'make bootstrap' instead of just plain 'make',
>   possibly 'rm Makefile lib/Makefile' would also be needed.
>
> Or what would you recommend?

I guess the text from INSTALL.REPO should be fine as standard:

    If 'make' fails, try 'make bootstrap'.  If CPU time is not an issue,
    'make bootstrap' is the most thorough way to rebuild, and avoid any
    spurious problems.

The "cl-"/struct/class thing is just the current spurious problem.

Although that doesn't necessarily cover the 'rm Makefile lib/Makefile'.
Perhaps we should add that to INSTALL.REPO as well?

bug#25055: 25.1.50; completion buffer changes window size

[Live System User]

martin rudalics <rudalics@gmx.at> writes:

[...]

> The bugs leading to this behavior should have been fixed now on master
> with commit
>
> 23d3eeb798c7edc27898b0dbd4c2364a6ca6247d
>
> Note that to get the desired behavior you have to (1) recompile
> window.el and after that (2) recompile all users of the macro
> `with-displayed-buffer-window' - that is, the files minibuffer.el and
> dired.el and finally (3) rebuild Emacs.
>
> If for some reason you cannot build Emacs or work with master, please
> tell me.  I'll then try to explain how to get the desired behavior with
> Emacs 25 and your .emacs alone.  Meanwhile closing this bug.

  I'd like to know how to do this on Emacs 25.

  Thanks.


>
> Many thanks for the report, martin

bug#25055: 25.1.50; completion buffer changes window size

[martin rudalics]

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

 >> If for some reason you cannot build Emacs or work with master, please
 >> tell me.  I'll then try to explain how to get the desired behavior with
 >> Emacs 25 and your .emacs alone.  Meanwhile closing this bug.
 >
 >    I'd like to know how to do this on Emacs 25.

Store the attached file my-fit-window.el somewhere on your machine,
byte-compile it with Emacs 25 and load my-fit-window.elc from .emacs.

And please tell me if it works.

Thanks, martin

[-- Attachment #2: my-fit-window.el --]
[-- Type: application/emacs-lisp, Size: 17369 bytes --]