Follow-up Comment #2, bug #13733 (project mc):
first a correction on my side: meanwhile i did actually experience a sequence
being torn apart, so the "one packet" theory simply does not hold. :(
going slightly overboard, one could apply some heuristics to determine the
worst-case line latency automatically.
i'm not sure it is a good idea to make the timeout a proper option only. it
makes sense to have the setting depend on the location, or rather on the
route to the location. an env variable seems to be the by far the most
appropriate means of achieving this. having separate settings for certain
$TERM seems interesting as well, as i might want to extend the timeout for
terms where i have to enter esc sequences manually - but that can be scripted
in the startup script as well.
other than that the patch seems reasonable (i did not test it, but i don't
see any code paths which you could have skipped if you tested it at all ;).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=13733>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
