Add readline support to HPC-GAP

[ssiccha]

I installed HPC-GAP on two of my machines that have readline installed. On both machines GAP is using readline without any problems, but my HPC-GAP builds can't.

The path to the library is just /lib/libreadline.so.6.

[fingolfin]

This is a known issue, HPC-GAP currently does not have readline support, for technical reasons

[ssiccha]

Okay thanks. I thought I heard somewhere that it already supports readline. My mistake.

[fingolfin]

No need to apologize, you couldn't have known this -- and in fact I am reopening this issue, as I think it's good to document this issue this way.

[fingolfin]

See also issue #39

[rbehrends]

There are currently two practical issues that are getting in the way.

1. The easier, but still slightly tedious issue, is that of configuring readline. Autoconf normally grabs the information off the ./configure argument and then writes the necessary entries in config.h and Makefile. Here, scons will need to replicate figuring out the -L and -I options in a way that mirrors what autoconf does (so that the two don't disagree and we suddenly have readline enabled in config.h, but don't actually provide the include path or link in the library. This still shouldn't be too painful, outside of obscure configurations (and even then we can default to no to make sure that the default build doesn't break).
2. Internally, both GAP's line editor and readline have the problem that they aren't designed for HPC-GAP's use case, where the editor constantly runs in the foreground, while output is being generated and prompts may change spontaneously (remember, there is only one readline instance serving multiple threads that is even alive when the main thread is busy computing something); in general, most commandline editing facilities were designed for a sequential world. The prompt changes are easy to address in principle, and so is output that always comes in complete lines (you'll change the prompt if necessary and force a redraw). This still requires a fair amount of busywork, but is not impossible. The biggest problem is the output of partial lines, which requires more control over the terminal than we currently have and which may be difficult to reconcile with either line editor (or somebody could jump through the necessary hoops to implement it). A possible work around is to suppress the output of partial lines and add a notification symbol to the prompt when that happens. Such a notification as part of the prompt could also show information about output being available in other threads (the lack of such a notification is an ongoing source of confusion for users).

An alternative would be to not try and build a line editor into HPC-GAP (other than as a basic fallback version), but to create a smart protocol for a frontend (based on the current multi-threaded UI) that can interact with an external editor (for example, GAP could fork itself and exec such an editor if it is run in an interactive fashion/with the proper command line option). It so happens that lib/consoleui.g already has the necessary functionality, but would have to send/receive messages that could be parsed across pipes instead. This would also facilitate the use of more advanced frontends (including GUIs).