Fwd: pcomplete bug with special display buffers

Fwd: pcomplete bug with special display buffers

[David Hansen]

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

Hello,

is there anything wrong with this one character patch or did it just
got lost?

I'm using it now for about two weeks and it seems to work pretty
well.

David


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

From: David Hansen <david.hansen@physik.fu-berlin.de>
To: emacs-pretest-bug@gnu.org
Subject: pcomplete bug with special display buffers
Date: Sat, 17 Feb 2007 13:14:44 +0100
Message-ID: <87hctlq8uj.fsf@localhorst.mine.nu>


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:

Hello,

to reproduce the bug:

$ emacs -Q

and eval (setq special-display-regexps '("^\\*Completions\\*$"))

then use some Emacs program that uses pcomplete.el e.g. M-x eshell
and use the completion feature (press TAB at least two times) on
some not unique string, e.g. in eshell just hit TAB

Debugger entered--Lisp error: (wrong-type-argument window-live-p nil)
  select-window(nil)
  byte-code(<stripped as this confuses gnus to much>)
  pcomplete-show-completions(("fold" "font2c" "font2psf" "fontinst" "fontname" "fontprop" "formail"))
  pcomplete-stub("fo" ("fold" "font2c" "font2psf" "fontinst" "fontname" "fontprop" "formail"))
  pcomplete-do-complete("fo" ("fold" "font2c" "font2psf" "fontinst" "fontname" "fontprop" "formail"))
  byte-code(<stripped as this confuses gnus to much>)
  pcomplete(1)
  call-interactively(pcomplete)

Fix:

*** pcomplete.el	24 Jan 2007 06:19:37 +0100	1.25
--- pcomplete.el	17 Feb 2007 13:11:18 +0100	
***************
*** 982,988 ****
                      ;; Needed on a terminal
                      (event-matches-key-specifier-p event 9))
  		(save-selected-window
! 		  (select-window (get-buffer-window "*Completions*"))
  		  (if (pos-visible-in-window-p (point-max))
  		      (goto-char (point-min))
  		    (scroll-up)))
--- 982,988 ----
                      ;; Needed on a terminal
                      (event-matches-key-specifier-p event 9))
  		(save-selected-window
! 		  (select-window (get-buffer-window "*Completions*" t))
  		  (if (pos-visible-in-window-p (point-max))
  		      (goto-char (point-min))
  		    (scroll-up)))


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
/home/dhansen/share/emacs/22.0.93/etc/DEBUG for instructions.


In GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, X toolkit)
 of 2007-01-30 on robotron
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--disable-sound' '--prefix=/home/dhansen' '--without-toolkit-scroll-bars' '--disable-pop''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  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.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  erc-menu-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-netsplit-mode: t
  erc-spelling-mode: t
  erc-truncate-mode: t
  paredit-mode: t
  jabber-activity-mode: t
  erc-services-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-smiley-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  erc-scrolltobottom-mode: t
  eldoc-mode: t
  which-function-mode: t
  show-paren-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  abbrev-mode: 1
  hs-minor-mode: t

Recent input:
<tab> <tab> C-n C-n <tab> <return> C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-l C-n C-n C-n C-n C-p C-p 
C-p C-p C-s s e l e C-n C-l M-f M-f C-h f C-g C-x 1 
C-z e m <backspace> <backspace> ~ . <backspace> / b 
i n <tab> e m <tab> SPC - Q SPC <return> <C-tab> C-x 
b d o t <return> M-< C-s s p e c i C-a C-M-SPC M-w 
C-x b <return> C-x b <return> C-n <switch-frame> <switch-frame> 
C-x 1 M-x r e p <tab> o <tab> r <tab> b <tab> <ret
urn>

Recent messages:
uncompressing pcomplete.el.gz...done
Fontifying pcomplete.el.gz... (regexps...................)
uncompressing pcomplete.el.gz...done
Mark saved where search started
Quit
Partially completed
Mark set
Mark saved where search started
Mark set
Making completion list... [2 times]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Fwd: pcomplete bug with special display buffers

[Chong Yidong]

David Hansen <david.hansen@gmx.net> writes:

> Hello,
>
> is there anything wrong with this one character patch or did it just
> got lost?
>
> I'm using it now for about two weeks and it seems to work pretty
> well.

Looks good; I checked it in.  Thanks.

Re: Fwd: pcomplete bug with special display buffers

[Richard Stallman]

    is there anything wrong with this one character patch or did it just
    got lost?

What do you mean, "one character patch"?  It looks like two characters
to me!

Re: Fwd: pcomplete bug with special display buffers

[David Hansen]

On Mon, 05 Mar 2007 12:33:13 -0500 Chong Yidong wrote:

> David Hansen <david.hansen@gmx.net> writes:
>
>> Hello,
>>
>> is there anything wrong with this one character patch or did it just
>> got lost?
>>
>> I'm using it now for about two weeks and it seems to work pretty
>> well.
>
> Looks good; I checked it in.  Thanks.

Thanks.  In the meantime I noticed that the (more or less same) bug
is spread all over the GNU Emacs sources (well, I might exaggerate a
bit).  The attached patch is for lisp.el, the same happens at least
in comint.el, I haven't investigated the other results that a grep
showed me.

The bug in lisp and comint completion won't throw an error as in
pcomplete.el.  To reproduce it you have resize the special frame so
that not all possible completions fit within the window. Repeated TAB
key strokes won't scroll the buffer.

Not sure if your improvements to the pcomplete patch make sense here
too (note the `last-command-check').  Maybe 'visible instead of t?

When we are at it:  what's a good solution to the following problem:
as you may have noticed ;-) I made some other changes to comint.el
but only want to send the diff that solves the *Completion* buffer
problem.  How do you deal with this?

David

*** lisp.el	24 Jan 2007 06:19:42 +0100	1.78
--- lisp.el	06 Mar 2007 03:52:16 +0100	
***************
*** 583,589 ****
  considered."
    (interactive)
  
!   (let ((window (get-buffer-window "*Completions*")))
      (if (and (eq last-command this-command)
  	     window (window-live-p window) (window-buffer window)
  	     (buffer-name (window-buffer window)))
--- 583,589 ----
  considered."
    (interactive)
  
!   (let ((window (get-buffer-window "*Completions*" t)))
      (if (and (eq last-command this-command)
  	     window (window-live-p window) (window-buffer window)
  	     (buffer-name (window-buffer window)))

Re: Fwd: pcomplete bug with special display buffers

[Stefan Monnier]

> When we are at it:  what's a good solution to the following problem:
> as you may have noticed ;-) I made some other changes to comint.el
> but only want to send the diff that solves the *Completion* buffer
> problem.  How do you deal with this?

I start by doing

M-x vc-prepare-to-partial-checkin RET

then I undo the parts that I don't want to install (usually with the help
of C-x v = and diff-apply-hunk).  and then I C-x v v (or `c' from the *cvs*
buffer).

But IIRC vc-prepare-to-partial-checkin is one of those local hacks I haven't
installed in Emacs-CVS yet.


        Stefan

Re: Fwd: pcomplete bug with special display buffers

[David Hansen]

On Tue, 06 Mar 2007 04:05:24 +0100 David Hansen wrote:

> On Mon, 05 Mar 2007 12:33:13 -0500 Chong Yidong wrote:
>
>> David Hansen <david.hansen@gmx.net> writes:
>>
>>> Hello,
>>>
>>> is there anything wrong with this one character patch or did it just
>>> got lost?
>>>
>>> I'm using it now for about two weeks and it seems to work pretty
>>> well.
>>
>> Looks good; I checked it in.  Thanks.
>
> Thanks.  In the meantime I noticed that the (more or less same) bug
> is spread all over the GNU Emacs sources (well, I might exaggerate a
> bit).  The attached patch is for lisp.el, the same happens at least
> in comint.el, I haven't investigated the other results that a grep
> showed me.
>
> The bug in lisp and comint completion won't throw an error as in
> pcomplete.el.  To reproduce it you have resize the special frame so
> that not all possible completions fit within the window. Repeated TAB
> key strokes won't scroll the buffer.
>

Attached the patch for comint.el.  Could someone please have a look
at `switch-to-completions' in simple.el?  My window manager doesn't
allow emacs to focus other frames so it won't work for me anyways.

Grep indicates that the same bug might be present in org.el,
python.el and idlwave.el.  I don't use these modes, would be glad if
someone else can check these.

David

Index: lisp/comint.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/comint.el,v
retrieving revision 1.358
diff -u -r1.358 comint.el
--- lisp/comint.el	23 Feb 2007 19:21:25 -0000	1.358
+++ lisp/comint.el	7 Mar 2007 14:58:11 -0000
@@ -2943,7 +2943,7 @@
 (defun comint-dynamic-list-completions (completions)
   "List in help buffer sorted COMPLETIONS.
 Typing SPC flushes the help buffer."
-  (let ((window (get-buffer-window "*Completions*")))
+  (let ((window (get-buffer-window "*Completions*" t)))
     (setq completions (sort completions 'string-lessp))
     (if (and (eq last-command this-command)
 	     window (window-live-p window) (window-buffer window)

Re: Fwd: pcomplete bug with special display buffers

[Stefan Monnier]

> +  (let ((window (get-buffer-window "*Completions*" t)))

I recommend to use 0 rather than t as last arg to get-buffer-window
otherwise you may find the buffer but in a frame that can't be seen (at
least not without first explicitly making it visible).


        Stefan

Re: Fwd: pcomplete bug with special display buffers

[David Hansen]

On Wed, 07 Mar 2007 11:30:31 -0500 Stefan Monnier wrote:

>> +  (let ((window (get-buffer-window "*Completions*" t)))
>
> I recommend to use 0 rather than t as last arg to get-buffer-window
> otherwise you may find the buffer but in a frame that can't be seen (at
> least not without first explicitly making it visible).

Shouldn't it be 'visible then?  But i don't think I'm the right
person to check this, my window manager (ion3) is a bit different
from what most other users have.

David

Re: Fwd: pcomplete bug with special display buffers

[Stefan Monnier]

>>> +  (let ((window (get-buffer-window "*Completions*" t)))
>> 
>> I recommend to use 0 rather than t as last arg to get-buffer-window
>> otherwise you may find the buffer but in a frame that can't be seen (at
>> least not without first explicitly making it visible).

> Shouldn't it be 'visible then?  But i don't think I'm the right
> person to check this, my window manager (ion3) is a bit different
> from what most other users have.

Could be.  The difference is that `visible' would not notice if the
buffer is displayed in an iconified frame, even though the frame will be
de-iconified automatically by display-buffer, pop-to-buffer,
raise-frame, and maybe a few other common operations.

To be honest: there's a bit of confusion around all this.  Part of the
confusion comes from the fact that the `invisible' property of a window has
been poorly specified and that most things have been defined in the context
of a single display.  With multiple-displays it makes sense to distinguish
frames that are merely not currently shown (typically: iconified) from
frames that simply can't be displayed on the current display.

Given the current situation, the most sensible way to go is to declare that
`invisible' indicates a frame that Emacs should consider as "currently
unshowable" (either because it's on another display, or because the user
has told Emacs not to show it by setting the `invisible' property).
I have some patches waiting to be applied to try and straighten things out.


        Stefan