Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14

[GoogleCodeExporter]

**What steps will reproduce the problem?**
I'm not sure that I can exactly describe how I get it. Generally speaking, it's
`shellPrompt' call and fast `t' pressing.

Than I get xmonad totally freezed and message in terminal where I call `xinit',
which run xmonad:

    Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14

At 601 line of Prompt.hs there is unsafe pattern matching:

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

**What is the expected output? What do you see instead?**
What I want is some `fromJust' there or hadling this situation with `case'.

It's xmonad-contrib-0.10-r1 build from gentoo-haskell overlay. 
(https://github.com/gentoo-haskell/gentoo-haskell/tree/master/x11-wm/xmonad-cont
rib)

Original issue reported on code.google.com by smp...@gmail.com on 3 Jun 2012 at 3:02

[GoogleCodeExporter]

I can reproduce the same bug with xmonad-0.10-3 from ubuntu 12.0 by running 
shellPrompt and typing any character with code greater than 0x100 (utf-8 
locale), for example "ы".

Original comment by manpac...@gmail.com on 17 Jun 2012 at 1:04

[GoogleCodeExporter]

That's right, utf-8 symbols in Prompt reproduces that error.

Original comment by smp...@gmail.com on 18 Jun 2012 at 8:37

[GoogleCodeExporter]

Right, the problem is that lookupString already returns keypresses which are 
already in proper  unicode and whoever implemented utf8-string library decided 
not to use any checks if string is in unicode format already and some other guy 
 who implemented  Xmonad.Prompt decided that he can assume that color passed 
into initColor will be always correct and yet one more guy decided that 
catching any exceptions inside that initColor function and returning Nothing 
should be  safe - because of all this (and some haskell lazyness) we have a 
nice,  clean and 100% unrelated error message about this pattern match.

So if you are affected by that bug and looking for a quick fix - just go into 
XMonad.Prompt module, look for keyPressHandle function, look for decodeString 
near insertString call and just remove that decodeString part.

Original comment by manpac...@gmail.com on 23 Jul 2012 at 1:29

[GoogleCodeExporter]

I wanna that fix to be done in some future xmonad releases.

Original comment by smp...@gmail.com on 23 Jul 2012 at 5:09

[GoogleCodeExporter]

I remove 'decodeString', but it does not fix problem:

keyPressHandle :: KeyMask -> KeyStroke -> XP ()
keyPressHandle m (ks,str) = do
  km <- gets (promptKeymap . config)
  kmask <- cleanMask m -- mask is defined in ghc7
  case M.lookup (kmask,ks) km of
    Just action -> action >> updateWindows
    Nothing -> case str of
                 "" -> eventLoop handle
                 _ -> when (kmask .&. controlMask == 0) $ do
                                 insertString (decodeString str)
                                 updateWindows
                                 completed <- tryAutoComplete
                                 when completed $ setSuccess True >> setDone True

to

keyPressHandle :: KeyMask -> KeyStroke -> XP ()
keyPressHandle m (ks,str) = do
  km <- gets (promptKeymap . config)
  kmask <- cleanMask m -- mask is defined in ghc7
  case M.lookup (kmask,ks) km of
    Just action -> action >> updateWindows
    Nothing -> case str of
                 "" -> eventLoop handle
                 _ -> when (kmask .&. controlMask == 0) $ do
                                 insertString str
                                 updateWindows
                                 completed <- tryAutoComplete
                                 when completed $ setSuccess True >> setDone True

Please, fix this bug!!

Original comment by d...@krylov.ws on 26 Aug 2012 at 5:17

[GoogleCodeExporter]

> I remove 'decodeString', but it does not fix problem:
sorry, it's need to call "xmonad --recompile" too.
Now this patch work!

Original comment by d...@mycareermap.ru on 27 Aug 2012 at 9:11

[GoogleCodeExporter]

Has anyone but dima tested this?

Original comment by gwe...@gmail.com on 7 Sep 2012 at 3:37

[GoogleCodeExporter]

Can we merge this fix into main repo? Or at least check whole situation with 
handling input with encodings other than lower part of ASCII - mostly utf8.

Original comment by manpac...@gmail.com on 29 Oct 2012 at 5:50

[GoogleCodeExporter]

I came to the same solution independently. Works fine here (ghc-7.6, 
en_US.UTF-8 locale). I think it's peekCString doing all the hard work:

> peekCStringLen s = getForeignEncoding >>= flip GHC.peekCStringLen s

Original comment by polac...@gmail.com on 14 Dec 2012 at 3:42

Attachments:

• prompt.diff

[GoogleCodeExporter]

Original comment by vogt.a...@gmail.com on 14 Dec 2012 at 4:30

• Changed state: Patch
• Added labels: Component-Contrib, Milestone-Release1.0, Type-Defect

[GoogleCodeExporter]

Original comment by vogt.a...@gmail.com on 26 Dec 2012 at 1:32

• Changed state: Fixed