bug#2800: 23.0.91; Emacs has no response when mini-buffer is too narrow to display information

bug#2800: 23.0.91; Emacs has no response when mini-buffer is too narrow to display information

[ZelluX]

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

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing
list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I opened two windows using C-x 3, and set the width of the right windows to
a really small value (to be more precisely, it can display 50 characters per
line). Then on the left line I run some command like M-x align<TAB>, as a
result, the right window will be used as minibuffer and display
auto-completion list. The bug is that, the list comes with all '\' on the
right most and just cannot stop printing, and does not response to my
control. In program 'top' I can see the CPU% of this emacs process is 100%.

I now can reproduce bug with the above operations. Under ArchLinux, in a
bash terminal with screen 4.00.03.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.0.91/etc/DEBUG for instructions.


In GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.14.7)
 of 2009-03-19 on pupykin
configured using `configure  '--prefix=/usr'
'--localstatedir=/var/lib/emacs' '--libexecdir=/usr/lib/emacs' '--with-xpm'
'--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk'
'--without-sound' '--enable-font-backend' '--with-freetype' '--with-xft'
'--with-libotf' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 8 3 ; 4 0 0 0 3 ; 0 c C-x C-f C-g C-x 3 C-u
1 0 C-x } C-x C-g C-x < C-g C-x { C-x { C-x { C-x {
C-x { C-x { C-x { C-x { C-x { C-x { C-x { C-x { C-x
{ C-x { C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-g ESC x r e p o TAB TAB r t TAB TAB RET C-g ESC C-z
C-x C-f C-g ESC x r e p o TAB r t TAB RET

Recent messages:
Loading /usr/share/emacs/site-lisp/themes/color-theme-library.el
(source)...done
Loading /home/wyx/emacs/my-utils.el (source)...done
Loading /home/wyx/emacs/muse-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Type y, n, ! or SPC (the space bar):
Quit [2 times]
Making completion list...
Quit [2 times]
Making completion list...

[-- Attachment #2: Type: text/html, Size: 3490 bytes --]

bug#2800: 23.0.91; Emacs has no response when mini-buffer is too narrow to display information

[Chong Yidong]

> I opened two windows using C-x 3, and set the width of the right
> windows to a really small value (to be more precisely, it can display
> 50 characters per line). Then on the left line I run some command like
> M-x align<TAB>, as a result, the right window will be used as
> minibuffer and display auto-completion list. The bug is that, the list
> comes with all '\' on the right most and just cannot stop printing,
> and does not response to my control. In program 'top' I can see the
> CPU% of this emacs process is 100%.

I can't reproduce this.  Does it happen with `emacs -Q'?

bug#2800: 23.0.91; Emacs has no response when mini-buffer is too narrow to display information

[ZelluX]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

It still happens, i've uploaded another three pictures which show the
problem more clearly

In step1.png it has no problem. Then i typed C-x } *once* to make the right
window narrower, as in step2.png
Then when i tried M-x align<TAB> the problem occured, after i typed another
<TAB> Emacs has no responses.
Additionally, when i have two of emacs running in this situation, the system
becomes really slow, since emacs consumes nearly 100% CPU

On Mon, Mar 30, 2009 at 1:21 AM, Chong Yidong <cyd@stupidchicken.com> wrote:

> > I opened two windows using C-x 3, and set the width of the right
> > windows to a really small value (to be more precisely, it can display
> > 50 characters per line). Then on the left line I run some command like
> > M-x align<TAB>, as a result, the right window will be used as
> > minibuffer and display auto-completion list. The bug is that, the list
> > comes with all '\' on the right most and just cannot stop printing,
> > and does not response to my control. In program 'top' I can see the
> > CPU% of this emacs process is 100%.
>
> I can't reproduce this.  Does it happen with `emacs -Q'?
>

[-- Attachment #1.2: Type: text/html, Size: 1504 bytes --]

[-- Attachment #2: step1.png --]
[-- Type: image/png, Size: 28742 bytes --]

[-- Attachment #3: step2.png --]
[-- Type: image/png, Size: 27984 bytes --]

[-- Attachment #4: step3.png --]
[-- Type: image/png, Size: 24647 bytes --]

bug#2800: 23.0.91; Emacs has no response when mini-buffer is too narrow to display information

[Chong Yidong]

Okay, I found a recipe for the bug.

(global-set-key [f1] (lambda () (interactive)
  (split-window-horizontally 50)
  (setq truncate-partial-width-windows nil)
  (erase-buffer)
  (insert "In this buffer, type RET to select the completion near
  point.\n\nPossible completions are:\nalign    align-current
  align-entire\n")
  (put-text-property 95 96 'display '(space :align-to 26))
  (put-text-property 110 111 'display '(space :align-to 52))))

Running this command on a terminal will hang it.  Looks like a redisplay
problem with space display properties, and it's present on Emacs 22 as
well.