XMonad.Prompt freezes if alwaysHighlight= True and maxComplRows is not Nothing

[fabiodl]

Problem Description

Especially for XMonad.Prompt.Prompt (but the bug holds for XMonad.Prompt.Window) I set alwaysHighlight to True (to avoid the necessity of pressing tab for selection) but to keep the prompt window reasonably small I set maxComplRows to Just 3
If I have enough choices, so that some of them are not shown, and I keep pressing tab, when I select the first "off screen" one, the prompt freezes. To be specific, the prompt stays there, other xmonad keybindings become available (for instance, switching workspace) while applications do not receive keystrokes anymore (the mouse can be used, however).
stdout reports

user error (Pattern match failure in do expression at XMonad/Prompt.hs:911:3-14)

Expected behavior: as when alwayHighlight is false, complete the prompt with the first invisible entry.

Configuration File

, ((myModKey .|. shiftMask, xK_b ), windowPrompt def{maxComplRows=Just 3,alwaysHighlight = True} Bring allWindows)

Checklist

• I've read CONTRIBUTING.md

[byorgey]

What version of xmonad are you using?

[fabiodl]

0.13, both installed from cabal or compiled from github.
The one installed from cabal runs on a machine with ghc 7.6.3,
The one manually compiled runs on a machine with ghc 7.10.3

I tried recompiling everything with 8.0.2 and the problem remains. Minimal file:

import XMonad                                                                  
import XMonad.Prompt                                                           
import XMonad.Prompt.Shell                                                     
import XMonad.Util.EZConfig                                                    
                                                                               
main = xmonad $ def `additionalKeys` [                                         
  ((mod4Mask, xK_x),shellPrompt def{maxComplRows=Just 3, alwaysHighlight=Tru
e})                                                                            
  ] 

[byorgey]

And when you run the version compiled from github, does it still give the same error Pattern match failure in do expression at XMonad/Prompt.hs:911:3-14?

In fact, line 911 of XMonad.Prompt no longer contains anything which could cause a pattern match failure. So this would indicate that somehow you are actually running an older version of xmonad.

[fabiodl]

Sorry, for the git version it becomes row 914
user error (Pattern match failure in do expression at XMonad/Prompt.hs:914:3-14)

[byorgey]

So line 914 is this:

 Just bgcolor <- io $ initColor d (bgColor c)

in what situations could initColor return Nothing? It is a mystery why stuff about completion could affect whether the background color can be initialized successfully.

Just a guess at this point but perhaps the offending change is contained in this commit: 57c00b1#diff-748083b353b28f1e3caf808fbfb0f470

[fabiodl]

I found out that when the error occurs, d seems not valid. Specifically, if I print d I get
Display Prelude.!!: index too large.
However, i have no idea where dpy is set

[geekosaur]

https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Prompt.hs#L420 and later stuffed into the XPState. But I don't see why this would be relevant to (!!) unless there are two different uses of d with one shadowing the other. dpy is not meaningful to anything but Xlib and the X server.

[fabiodl]

When the error does not occur, d contains something that appears to be a pointer. Is such a pointer actually from a list of pointers?

[geekosaur]

It's a pointer obtained from C to the Xlib Display structure, which is supposed to be opaque to anything other than Xlib internals (but is actually partially exposed if you know which knobs to turn). We obtain it from openDisplay aka XOpenDisplay() and then pass it to other Xlib routines, which is all that an Xlib consumer is allowed to do. (Similar constraints exist on the xcb version.)

[geekosaur]

And I don't think it should ever come from a list, since we can only manage one Xlib Display / Screen at a time. But (!!) arising here means something is being done lazily to get it. I'm not sure what, since the only things I see in Prompt using it are XPState field lookups.

[mgsloan]

In #291 I've fixed the wrap around behavior of tab so that it returns to the first item on reaching the end of the visible completions list.

#287 resolves the exception handling behavior such that the keyboard gets ungrabbed and the prompt windows get destroyed

[fabiodl]

Really thank you very much, that perfectly solved the issue!