Martin Panter added the comment: For the record, this “operate-and-get-next” function is documented in Bash at <https://www.gnu.org/software/bash/manual/html_node/Miscellaneous-Commands.html#index-operate_002dand_002dget_002dnext-_0028C_002do_0029>. It is supposed to finish entering the current line, and it was taken from the history, bring up the following history item for editing. It hasn’t been added to Readline directly because it relies on how the application uses history (e.g. it is flawed in Bash for me because I use HISTCONTROL=erasedups).
Python’s “readline” module currently has runtime detection of Editline vs Gnu Readline. I am not sure if it is strictly needed, or just that it was easier than build-time detection, as hinted in <https://bugs.python.org/issue6877#msg92654>. It is confusing, because we have other build-time detection of particular Readline features. Perhaps you may be able to try out Editline using my patch for Issue 13501, but in my experience, the non-Apple patched Editline is too buggy to be useful in Python for much more than experimentation. I left a couple comments on Git Hub. I would prefer to expose more of this at the Python level, but that seems hard to do. See Issue 1690201 and Issue 1175004 for other attempts to add a custom function at the Python level. It is hard to do in a general way because rl_add_defun() only accepts a function pointer, and no opaque object to pass to the callback. I wonder how the ctypes library handles this when creating general function pointer objects. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22228> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
