Issue 507 in xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14
Status: New Owner: ---- New issue 507 by smp...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 **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-c...)
Comment #1 on issue 507 by manpac...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 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 "ы".
Comment #2 on issue 507 by smp...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 That's right, utf-8 symbols in Prompt reproduces that error.
Comment #3 on issue 507 by manpac...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 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.
Comment #4 on issue 507 by smp...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 I wanna that fix to be done in some future xmonad releases.
Comment #5 on issue 507 by d...@krylov.ws: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 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!!
Comment #6 on issue 507 by d...@mycareermap.ru: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507
I remove 'decodeString', but it does not fix problem: sorry, it's need to call "xmonad --recompile" too. Now this patch work!
Comment #7 on issue 507 by gwe...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 Has anyone but dima tested this?
Comment #8 on issue 507 by manpac...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 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.
Comment #9 on issue 507 by polac...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 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
Attachments: prompt.diff 1.3 KB
Updates: Status: Patch Owner: vogt.a...@gmail.com Labels: Component-Contrib Milestone-Release1.0 Type-Defect Comment #10 on issue 507 by vogt.a...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 (No comment was entered for this change.)
Updates: Status: Fixed Comment #11 on issue 507 by vogt.a...@gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 (No comment was entered for this change.)
participants (1)
-
codesite-noreply＠google.com