[haskeline] #78: control characters in prompt mess up width calculations

[haskeline]

#78: control characters in prompt mess up width calculations
-------------------+--------------------------------------------------------
Reporter:  judah   |        Owner:     
    Type:  defect  |       Status:  new
Priority:  minor   |    Milestone:     
 Version:  0.6     |   Resolution:     
Keywords:          |  
-------------------+--------------------------------------------------------
Comment (by phercek):

 Actually, I use only ghci with haskeline now. But it is not the stock
 ghci. I have about 5 private patches to it and one of them enables escape
 sequences in the prompt. It is a really ugly hack which uses some internal
 features of showSDoc functionality but does not modify showSDoc itlself. I
 was told rather not to modify showSDoc itslef, but I wanted this, so I
 just went around for my ghci instance. There is one more thing which
 annoys me with ghci SDoc: it assumes my terminal has 80 columns even when
 it has much more. But I did not do anything with this yet.

 Personally I do not really care whether it is \[ and \] or \001 and \002
 (e.g. zsh uses %{ and %}). The first allows us not to meddle with what
 user wants to pass to the actual terminal (i.e. user can pass \001 at the
 places he wants and not at the places we force him). But it also means we
 need additional escaping for \. So if somebody would want to use \ in the
 prompt it would need to be passed as \\. If a haskeline client program
 would use \ as its escaping character too, then it would mean user would
 need to specify haskeline \[ (\]) as \\[ (\\]) so that the client program
 does not process them. This is not a problem with ghci itslef which uses %
 as ecape character (so it is like zsh).

 On the other side \001 is start of heading (SOH) and \002 is start of text
 (STX) in ASCII. So this choice makes sense. If haskeline is going to
 interpret escape sequences (by correctly recognizing their length on ansi
 terminals at least) it can intepret also SOH and STX. They do not have any
 width themselves on my terminal. So SOH/STX looks like a better way. Maybe
 this is even the intended way how to recognize the width of escape
 sequences and control codes. It would be good to verify it with the ANSI
 standard (to check whether this is really the intended use) but I do not
 have access to it so I would rather do what others (readline) do. Maybe
 they verified it, and if not at least we are compatible with them. Things
 would be easier to port.

 So my summary:[[BR]]
 * \[(\]) is more flexible and in a way more compatible with systems not
 using SOH/SOX "standard" (we do not assign meaning to SOH/STX - we do not
 meddle with what user wants to send to the terminal).[[BR]]
 * SOH/STX is more compatible with current systems (known to use ansi
 sequences).[[BR]]
 Without additional info I vote lets do what readline does (SOH/STX). I'm a
 linux user and I doubt windows users mind we force SOH/STX ussage at them.
 They will not use any escape sequences anyway since they do not work from
 the time MS stopped to provide ansi.sys. This way it will easily work on
 linux quickly and on Windows we can add our own interpretation of ansi
 ecape-sequences later (to translate them to the correct console api
 calls).[[BR]]
 Hey, and if windows users really care now, they can get support for ansi
 escape sequences with even for 32 bit programs (where ansi.sys does not
 work) with ansicon. I used it myself working on windows. Well I had it
 patched because it had bugs which presented itself with ghci. When patched
 it works. I can provide the patch if anybody cares.

 If you want to try it with ghci, here is the ugly hack I use:
 {{{
 diff -rN -u old-ghc/ghc/InteractiveUI.hs new-ghc/ghc/InteractiveUI.hs
 --- old-ghc/ghc/InteractiveUI.hs        2009-02-25 21:54:08.879780180
 +0100
 +++ new-ghc/ghc/InteractiveUI.hs        2009-02-25 21:54:08.999779327
 +0100
 @@ -531,7 +531,7 @@
          f [] = empty
     --
    st <- getGHCiState
 -  return (showSDoc (f (prompt st)))
 +  return $ read $ '"' : ( showSDoc (f $ prompt st) ++ "\"" )


  queryQueue :: GHCi (Maybe String)
 }}}
 So far the hack did not make me any troubles.

-- 
Ticket URL: <http://trac.haskell.org/haskeline/ticket/78#comment:5>
haskeline <http://example.org/>
My example project