Re: [GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support -+-- Reporter: guest |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: GHCi | Version: 6.10.3 Severity: minor | Resolution: wontfix Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * difficulty: = Unknown * resolution: = wontfix Comment: I agree that time would be better spent improving haskeline than trying to maintain, and test, a readline alternative. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.3 Severity: minor | Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by duncan): I'd tend to agree, however there are at least these issues: * Maintenance and testing burden of keeping several line editing systems working * Distributing binaries and problems with depending on system shared libs. * Licensing complications If the patch is not invasive and GHC HQ are not asked to maintain the readline branch then perhaps the first point is ok. It's annoying when building binaries that sometimes the .so number of readline changes and then we need to build different binaries for different systems. Using haskeline has fewer problems in this area. When one builds ghc (BSD licensed) against readline (GPL) then if you distribute the combined work it must be under the terms of the GPL. That's not something that GHC HQ want to do and some users would prefer to receive binaries under the BSD or distribute their own binaries under the terms of the BSD license. On the other hand it's perfectly OK for distros to build it that way, as long as they clearly label the licensing terms of the result (which has not always been done clearly). So if readline is to be used it has to be optional and not the default. That's fine. So the only remaining issue is the maintenance burden. I cannot speak for the GHC maintainers but if someone volunteers to properly maintain the readline support then perhaps that might be enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.3 Severity: minor | Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by judah): Note that Haskeline does have bindable commands, as documented at: http://trac.haskell.org/haskeline/wiki/WikiDocumentation Also keep in mind that the readline backend also came with problems. For example, the following didn't work: - tab-completion of Unicode identifiers (#2058) - tab completion of quoted filenames in expressions - cancel the current input line with ctrl-c I don't really object to a forked GHC/readline. But I wonder whether the effort required to maintain a separate branch of GHC would be better used to fix Haskeline's remaining issues. (I plan to tackle many of them myself in time for the ghc-6.12 release.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
