Message11029
Okay, with these more preccise reproduction-steps I can reproduce it and I think I found the issue. It seems like jline-semantics differ from CPython's readline.c.
In particular the semantics of get/set_history_length seems to be different:
In CPython it only affects history file size while in memory actual length of history is always "unlimited" (?) (as far as it can be with finite memory).
In jline this value affects also history in memory and defaults to 500.
Also semantics for -1 == unlimited seems not to be implemented in Jython. Finally if history exceeds max length (e.g. 500), indexes continue to grow and it's actually the low indexes 1, 2,... that become invalid. So in your case you would have to keep track of the actual index and your 500 history items would not be indexed 1,...500 but e.g. 25...524. Unfortunately readline offers no public way to retrieve current max-index. You can get it via readline._reader.history.index().
I think I can fix Jython's readline to comply with CPython semantics in the described sense, if this is actually desired. Jim: What is your opinion on this? |
|
Date |
User |
Action |
Args |
2017-01-20 03:48:46 | stefan.richthofer | set | messageid: <1484884126.3.0.939163154227.issue2541@psf.upfronthosting.co.za> |
2017-01-20 03:48:46 | stefan.richthofer | set | recipients:
+ stefan.richthofer, kmac |
2017-01-20 03:48:46 | stefan.richthofer | link | issue2541 messages |
2017-01-20 03:48:45 | stefan.richthofer | create | |
|