On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts wrote:

I get some working and some non-working. Eg backspace, del, home, end work, but the ctl-left/ctl-right to jump words does not.

Does anyone know how libedit is supposed to be configured? readline uses /etc/inputrc but libedit either does not or doesn't understand all of it.

/me wonders if it was really necessary to switch from readline

Duncan

You can configure libedit with a ~/.editrc file. http://www.manpagez.com/man/5/editrc/ -Judah

Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Duncan Coutts | Sent: 07 November 2008 18:09 | To: GHC-users list | Cc: Philip K.F. Hölzenspies | Subject: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? | | On Fri, 2008-11-07 at 09:14 -0800, Judah Jacobson wrote: | > On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts | > wrote: | > > | > > I get some working and some non-working. Eg backspace, del, home, end | > > work, but the ctl-left/ctl-right to jump words does not. | > > | > > Does anyone know how libedit is supposed to be configured? readline | > > uses /etc/inputrc but libedit either does not or doesn't understand all | > > of it. | > > | > > /me wonders if it was really necessary to switch from readline | > > | > > Duncan | > | > You can configure libedit with a ~/.editrc file. | > | > http://www.manpagez.com/man/5/editrc/ | | Thanks Judah. | | To save everyone else having to read the man page and working out | through trial and error what the key escape codes are, add the following | to your ~/.editrc file. | | # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving | bind "\e[1;5D" vi-prev-word | bind "\e[1;5C" vi-next-word | | (though from reading the readline /etc/inputrc it suggests that "\e[5C" | and "\e[5D" might be right on some systems) | | It's unfortunate that editline does not seem to support any | global /etc/editrc file which would enable distros to make it do the | right thing by default like they do for readline. | | Duncan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Philip Hölzenspies wrote:

Something that I would personally very much enjoy is a clear and unmistakable warning from configure when editline is not found. After installing libedit-devel (my ghci-6.10.1 finally has comfortable editing now), I checked config.log; there's not even a mention of libedit capabilities. Maybe a general summary at the end of configure of all the optional capabilities that were or were not configured. As an inspiration, look at gtk2hs' configure output.

Good idea - I've added it to the list of things to do in the new build system. Cheers, Simon

Duncan Coutts wrote:

On Wed, 2008-11-19 at 20:45 +0100, Philip Hölzenspies wrote:

...

On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote:

...

Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Dear Simon, all,

I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes.

I don't have any particular wishes. I just want it to "work" where "work" means does what the rest of my system does. I never configured readline, it came with sensible defaults (possibly set by my linux system distributor).

What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach.

One downside I can see is that it gives us an extra configuration to test and maintain. It's hard enough keeping one line-editing binding working, let alone two! It's true that editline seems to have brought a bunch of headaches with it, though. Perhaps Haskelline is the way to go in the future. Cheers, Simon

On Thu, Nov 20, 2008 at 01:52:12PM +0000, Duncan Coutts wrote:

My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration.

Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to be BSD then it can't use it. Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency. Thanks Ian

On Thu, Nov 20, 2008 at 06:43:49PM +0000, Duncan Coutts wrote:

On Thu, 2008-11-20 at 15:16 +0000, Ian Lynagh wrote:

...

On Thu, Nov 20, 2008 at 01:52:12PM +0000, Duncan Coutts wrote:

...

My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration.

Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to be BSD then it can't use it.

It's not quite that simple. GHC HQ does not ship readline, it's just shipping BSD code. If I link ghc against readline then the result must be distributed in compliance with the GPL, but that's ok, all linux distros do that. When GHC HQ ship binaries they can configure it to use editline.

OK, so I should have said "... it can't use it exclusively". But it's still GHC HQ that needs editline support (or a switch to haskeline, or splitting ghci off, or some other solution. But just reverting to readline-only won't work). Thanks Ian

On 11/21/08, Simon Marlow wrote:

I propose we do this:

* extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package.

* Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs.

This gives us line-editing on Windows, and removes problematic external C library dependencies.

Just so it's clear, Haskeline on POSIX does require (n)curses, an external C library, in order to access terminfo capabilities portably. But in my experience curses is much more widely available by default than readline or editline, so I still think this is a significant improvement.

* Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want. Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package?

That sounds reasonable. As a side note, I'm very interested to learn of any more issues with Haskeline that would make it less preferable than the readline backend. -Judah

On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote:

I propose we do this:

* extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package.

This is good independently of the other suggestions.

* Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies.

I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies. Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it. In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale).

* Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want.

If haskeline "works" then I doubt there will be much pressure for readline support. The pining for the "good old days of readline" at the moment are only because editline clearly doesn't "work". [For some definition of "work"]

Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package?

A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a "bad thing". I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file. Duncan

Duncan Coutts wrote:

On Fri, 2008-11-21 at 14:01 +0000, Simon Marlow wrote:

...

I propose we do this:

* extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package.

This is good independently of the other suggestions.

...

* Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies.

I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies.

Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it.

Yes - I did some work on this, but didn't finish it. Unfortunately trying to shoehorn encodings into the IO library isn't pretty, and I became a bit disillusioned. I could probably still get it working, but I think I was really hoping that a better architecture for the IO library might emerge, and so far it didn't :-)

In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale).

Right, this will certainly be possible when we have System.IO doing encoding/decoding, we just need to agree on an API.

...

Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package?

A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a "bad thing". I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file.

I think it's a good idea to avoid variant licenses, especially in libraries. We want it to be easy for someone to know whether they're complying with the licenses for the libraries they depend on, and if those licenses depend on choices made at the time the library was built, then it's much harder. Cheers, Simon

Philip Hölzenspies wrote:

On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote:

...

Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later?

Dear Simon, all,

I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes. For example, aside from the word-jumping Duncan suggested, I alway use zsh-like history searching, so I like:

bind "^[[A" ed-search-prev-history bind "^[[B" ed-search-next-history

Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose.

But this is abhorrent. The whole point of the existence of termcap and libraries which build upon it (ncurses, readline, editline, etc) is so that individual users do not have to work out what the escape sequences produced by their terminal are. Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way? Jules

Philip K.F. Hölzenspies wrote:

On Friday 21 November 2008 10:49:47 Jules Bean wrote:

...

Philip Hölzenspies wrote:

...

Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose. But this is abhorrent.

The whole point of the existence of termcap and libraries which build upon it (ncurses, readline, editline, etc) is so that individual users do not have to work out what the escape sequences produced by their terminal are.

Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way?

One can call it broken, another will say users should settle for the default behaviour. Neither readline, nor editline *need* configuration this way, because they do come with sensible defaults. However, some people want custom behaviour and they'll have to figure out how stuff works for their machine.

And suppose I log on from another machine with a different TERM setting? or just use a different terminal program? This is broken.

On 11/21/08, Duncan Coutts wrote:

On Fri, 2008-11-21 at 11:59 +0100, Philip K.F. Hölzenspies wrote:

...

On Friday 21 November 2008 10:49:47 Jules Bean wrote:

...

...

Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way?

One can call it broken, another will say users should settle for the default behaviour. Neither readline, nor editline *need* configuration this way, because they do come with sensible defaults.

But that's just it. It seems that readline does come with sensible defaults and editline does not. For example xterm is not a rare kind of terminal (basically every terminal in use claims to be xterm) and yet delete does not work with it out-of-the-box with editline. That is broken.

[To add insult to injury, even when I look up the escape sequence for delete using the cat/telnet trick, I still cannot configure editline to recognise it.]

After further investigation, I think this technically isn't a terminal compatibility issue, but rather a missing feature; i.e., editline just doesn't intentionally support using the delete key. The command ed-delete-next-char which we found in the editrc manpage is really meant to represent pressing 'x' in the vi bindings, which is why it hasn't been working as expected. AFAICT, editline has no command equivalent to pressing 'delete'. Of course, regardless of the cause, the net result (delete key not working) is the same. I just wanted to point out that editline does use the same terminal capability libraries (termcap/terminfo) as readline, so there's no fundamental reason this couldn't be implemented portably other than (I'm guessing) the lack of motivation or time from its authors/contributors. -Judah

On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote:

...

Does anyone know how libedit is supposed to be configured? readline uses /etc/inputrc but libedit either does not or doesn't understand all of it.

/me wonders if it was really necessary to switch from readline

I'll note that it is all working find on Arch. The behaviour is indistinguishable to readline.

Perhaps the editline package is correctly configured here?

Does the arch editline package include a config file? /etc/something? Duncan

On Fri, Nov 7, 2008 at 8:38 PM, Alexander Dunlap wrote:

On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. Hölzenspies wrote:

Hi all,

I apologize if this is off-topic, but I'm having a similar (but distinct) problem: editline thinks that my delete key is a tilde key. When I type <DELETE>, it inserts a tilde. The tilde then acts completely like a tilde (i.e. GHCi interprets it as a tilde). I have been unable to find an answer by googling. Does anyone else have/know how to fix this problem?

First, just to make sure: do the arrow keys work or is all editing functionality broken? If it's the latter, then ghc probably wasn't built with libedit and you need the libedit-devel package. Assuming that's not the issue, and you don't get the same problem with readline-based programs, then it sounds like editline doesn't know about the key binding for DELETE on your system. The simplest fix is to edit the ~/.editrc file. For example: Running "ghc -e getLine", then pressing DELETE followed by RETURN, I see: $ ghc -e getLine ^[[3~ "\ESC[3~" This tells me the key sequence for the DELETE key in my terminal, so I add the following line to my ~/.editrc file (http://www.manpagez.com/man/5/editrc/): bind "\e[3~" ed-delete-next-char Hope that helps, -Judah

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? Thanks Ian

On Sun, Nov 9, 2008 at 12:53 PM, Ian Lynagh wrote:

On Sun, Nov 09, 2008 at 01:49:43AM +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

Oh, the other thing I meant to say is that it seems to behaves unexpectedly too. If I type "abc" and press delete, then the "c" is deleted and the cursor is left on (on, not after) the "b". I'd expect the "c" to remain, and the cursor to stay after the "c".

Thanks Ian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi, I'm not sure if this is Emacs' fault, but when I run GHCi through Emacs, entered text is printed to stdout or stderr immediately after Enter is pressed; when this is done after a file is loaded, "^J" is appended. For example

GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :t id :t id id :: a -> a Prelude> :l Pair.hs :l Pair.hs [1 of 1] Compiling Pair ( Pair.hs, interpreted ) Ok, modules loaded: Pair. *Pair> :t id :t id^Jid :: a -> a *Pair>

Note that this happens even without haskell-mode, using just M-x shell. I'm using Ubuntu 8.10, GHC 6.10.1. I symlinked libedit.so.0 to libedit.so.2 as Simon Marlow suggested. It works fine in gnome-terminal, but not in Emacs. Cheers, Reiner

On 2008 Nov 8, at 22:13, Rohan Drape wrote:

Emacs sends text to processes in packets of at most 255 characters. In between these ghci now gets a ^D character sequence inserted into the text. This did not happen previously (ie. with 6.8.2).

This sounds like a bug: either editline or ghci assumes that when it successfully reads data which lacks a line terminator than it has seen an EOF, so inserts a ^D. But if it received the data at the maximum tty buffer size (255) then there is no trigger character. (This is easy enough to work around: special-case reads of length 255. But in reality, this means something is Doing It Wrong.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

...

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 a haskell-based solution could be made to work, that would be great - if you think that editline somehow less nice than readline, consider us poor windows users: we have neither!

Note that haskeline has a lot of dependencies and requires TemplateHaskell and many other language extensions.

Talking about dependencies of cabal packages: - some packages depend on everything and the kitchen-sink, following the "ah, great, here's another package I should use" idea of what it means to provide a modern haskell package. It would be nice if package authors would consider separate minimal and extended dependencies, the former sufficient to enable the package functionality, the latter enabled by a flag, and only needed for testing frameworks, parser re-generation, convenience, performance, .. - since Duncan has put in the work for making meta-packages possible for the Haskell Platform anyway, couldn't that be used to group typical dependencies together (eg, ghc corelibs, old extralibs, haskell platform, testing, ..), to make those dependency lists on hackage somewhat easier to comprehend? Probably, hackage/cabal could offer some support for reducing detailed dependencies to standard dependency groups. Claus

On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts wrote:

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

On Sun, Nov 9, 2008 at 11:03 AM, Don Stewart wrote:

judah.jacobson:

...

...

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:

haskeline needs /way/ too many extensions for a simple console reader...

Well, even though the external API of a line reader may look simple, under the hood there can be a lot going on, both in the user interface (e.g. user preferences, multiple key bindings, history recall/search, undo/redo, tab completion) and backend (e.g. redraw efficiently, cross-platform compatibility). Using a stack of monad transformers to encapsulate the state and settings helped make the code much more modular, understandable and concise, but also required several type extensions to work the way I wanted (MultiParamTypeClasses, OverlappingInstances, FlexibleContexts, etc.). I felt the tradeoff was worth it when originally writing the code, but patches or suggestions are, of course, welcome :-) (Incidentally, the .cabal file in haskeline-3.2 erroneously lists GADTs and FunDeps which are not actually required; those extensions will be removed for the next release.) Best, -Judah