On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts
On Sun, 2008-11-09 at 01:49 +0000, Ian Lynagh wrote:
On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote:
bind "\e[3~" ed-delete-next-char
It's a shame this doesn't just work out of the box in an xterm, on Debian at least. Perhaps we should consider switching to haskeline? Do we know anything about how portable and complete that is?
If we're considering that I think we should consider bringing back readline as an option and let the people who have problems with gpl code configure in editline support instead.
Note that haskeline has a lot of dependencies and requires TemplateHaskell and many other language extensions.
I'm also somewhat wary of switching to haskeline in ghc-6.10. I think these issues could be resolved in time for 6.12, though: 1) Completeness: IMHO as the package author, haskeline already has enough features and cross-platform compatibility to warrant its use by ghci. (The full feature-list is at http://trac.haskell.org/haskeline/ .) 2) Language extensions: Since ghci is only ever built in stage 2 (and never by the bootstrapping compiler), the language extensions should not be an issue. The only exception is TemplateHaskell, as Duncan mentioned, since it cannot be used by a stage 1 compiler. But TH is limited to one function in one module and could be easily replaced either by hard-coding the generated code or by using syb. (Some other extensions may also no longer be necessary: I haven't checked recently). 3) Dependencies: Outside of ghc's bootlibs, haskeline depends on mtl and stm (which are extralibs), terminfo (which is only used on POSIX), and utf8-string. - utf8-string should not be needed when unicode text I/O is implemented for ghc-6.12, as mentioned in http://hackage.haskell.org/trac/ghc/wiki/Status/October08 - terminfo is a lightweight binding to a foreign library (ncurses, really) and could either be added to the bootlibs (my preference) or folded into the haskeline package. - stm: I don't see why this couldn't also be a bootlib, although if necessary I can investigate using MVar-based concurrency instead. - mtl: haskeline uses MonadTrans and MonadIO from that package, which ghc reimplements internally. I'm not sure of the right thing to do here. -Judah