Running racket in a terminal with readline 6 has excruciating delays
in response and bizarrely slow pasting. The culprit is probably a bug
in readline v6.2 that causes the rl_event_hook to be called repeatedly
even when input is ready. See also the discussion here:
http://lists.gnu.org/archive/html/bug-readline/2012-06/msg00005.html
It's not clear whether racket can work around the issue in readline 6,
but it can at least use readline 5 instead when it is available.
Using `call-as-atomic' isn't right, because that allows an escape
via `call-as-nonatomic'. Assuming that `call-as-nonatomic' isn't
used, it seems like `call-as-atomic' should be ok, anyway, but
somehow its leads to unbalanced `end-atomic' calls.
The `on-size' method is called in atomic mode,
and we can't call into the editor's sizing functions
in atomic mode.
Watch out for refresh and/or window-sizing problems.
Add `file-position*', which can return #f instead of raising
an exception when a port's position is unknown. Change
`make-input-port' and `make-output-port' to accept more
kinds of values as the initial position.
These changes make it possible to synchronize a port's
position with a `port-commit-peeked' action. It's ugly,
which I think reflect something broken about position
tracking in the port protocol (which seems difficult to fix
without breaking compaibility).
Providing a port instead of a reading or writing procedure
redirects the read/write to the specified port. This shortcut
is kind of a hack, but the run-time system can easily streamline
the redirection when it's exposed this way.
Using the new redirection feature reduces overhead in
`with-output-to-bytes' and `pretty-print'.
Previously, the use of `pretty-print' for `print' by `racket/main'
and the use of `transplant-output-port' by `pretty-print' caused
a flush to happen.
This problem highlights a potential general issue, which is that
`pretty-print' happened to always flush its output before, and
some programs may accidentally depend on that behavior.
