Whenever you suspect a bug, if possible, please reconfigure with
./configure --enable-debug and run rlwrap with a -d7 option. This will
create a file /tmp/rlwrap.debug that will help you (or me) find the
problem.

Many (most) bug reports, especially the really weird ones, stem from
"version skew" on distributions (RedHat, Debian) that have separate
development packages (e.g. readline and readline-dev). For some reason
it can happen that the devel package is out of sync with the main
package, and then really strange things may happen. So: always update your 
{readline, ncurses}-devel packages before you complain to me!


* Gotcha's

If rlwrap doesn't seem to do anything, chances are that the rlwrapped
program already does its own line editing. Using the -a (--always-readline)
option will make rlwrap use its own line editor.

If such programs do their own completion, it will be unusable under rlwrap


* General inadequacy and weak spots


The more sophisticated the terminal handling of rlwrapped program (the
"client") gets, the less rlwrap will be able to maintain its
transparency.  Of course, more sophisticated programs generally have
less need for rlwrap.

---

rlwrap cannot handle prompts that contain control characters (except
ANSI colour), though you may not notice this until your cursor almost
reaches end-of-line


---

older QNX: If 'configure' complains "Oops! Your 'rm' program seems unable to run
without file operands specified", export
ACCEPT_INFERIOR_RM_PROGRAM=yes before running 'configure'

---

The -m option uses the system() (3) library function to call an
external editor. I'm not quite sure how system() handles signals like
TSTP an WINCH (and "system" is a difficult name to Google for...)
Re-sizing the terminal may confuse the editor

--

The code that determines whether a cooked prompt should be overwritten
(when it turns out to not have been a prompt) is needlessly complex
and not quite correct (e.g. substitute prompts may be left standing
when they should be erased).