Well, I got used to the fact the “Control-S” doesn’t work.
I’s either silently ignored (when “root” is started in a “gnome-terminal”) or it’s interpreted as DC3/XOFF (when “root” is started in an “xterm”, which requires a following “Control-Q”, aka DC1/XON, in order to “resume” normal work).
However, up to ROOT 5.28 “Control-R” was working.
Well, in ROOT 5.30 it’s not working any more.
This started to be really annoying to me.
Does anybody know any remedy?
After a long search today, I have finally found three utilities which provide line-editing capabilities as a command wrapper:
rlwrap - (GNU) readline wrapper
rlfe - “cook” input lines for other programs using (GNU) readline
ledit - line editor (note: it uses OCaml instead of GNU readline)
Does anybody have any experience (good or bad) in using any of these utilities with ROOT?
Hi,
How is ^R not working? Which platform, which terminal, which keyboard? What do you expect it to do, what does it do for you?
^S has different implementations on different terminals and for different OSes, no wonder it behaves differently 
ROOT doesn’t do anything special with it - for that exact reason.
Cheers, Axel.
I run Ubuntu 10.04.3 LTS / i686.
Simple standard utilities, like emacs, have no problems with “Control-S” in ANY teminal.
In ROOT 5.30, when I press “Control-R” I get:
root [0] [bkw’’]
then, when I type “2.54” I get (what I expect):
root [0] [bkw’2.54’] 2.542.54
then when I press “Control-R” again the search is finished and I get:
root [0] 2.542.54
instead of the “previous” instance of “2.54” from the history.
And of course, in any modern ROOT version (e.g. 5.28), I can only “search backwards” - “forward searches” do not work at all as handling of “Control-S” is broken.
Hi,
“broken” would mean that it was meant to do something I prefer ^S to stop terminal output - it’s very handy for massive debug output. Emacs is not like ROOT: it has a defined window. So I prefer to leave ^S as is: stop output if available through the terminal.
Regarding ^R: if I understand you well than all you request is that ^R stops backward “regexp” search instead of going to the previous one (again, “does not work” is a pretty strong statement for that ? That’s not the behavior I see e.g. in bash and the one I am used to, so I prefer to keep it the way it is: let ^R skip to the next match in the history.
Did I misunderstand you anywhere?
Cheers, Axel.
Hi,
I now realize that you said 5.30 shows the unwanted behavior for ^R. Do you agree that this is fixed in v5.32 and the trunk?
Cheers, Axel.
For the moment I have ROOT 5.18, 5.28 and 5.30.
In 5.18 both Control-R and Control-S work well (moreover, Control-S works as “forward-incremental-search” when ROOT is displaying its prompt AND it works as “DC3/XOFF” when ROOT is running a macro / executing a command … so IT CAN BE DONE).
In 5.28 only Control-R works (Control-S handling is broken).
In 5.30 none of them works.
Hi Pepe,
Could you try with either the trunk or v5.32?
Thanks,
Philippe.
Hi,
^R is NOT broken in v5.30, unless your statement above is wrong. You said:
So ^R does work, only you want it to work better (^R doing incremental search). It does incremental search in v5.32 and the trunk. Could you confirm, please?
Cheers, Axel.
I don’t think there can be any consensus reached among us on this issue.
What you consider a “feature” is clearly a “bug” for me.
That said, I tried the current ROOT “trunk@42917”.
Ctrl-S does not work at all.
Ctrl-G handling is broken now (as compared to ROOT 5.28).
Ctrl-J doesn’t work as expected.
Ctrl-R seems to work but its line handling is partially broken - if the first found history line is long, it misbehaves (below I press … Ctrl-R 2 . 5):
root [0] [bkw''] .q
root [0] [bkw'2'] 2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
root [0] [bkw'2.']
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
root [0] [bkw'2.5']
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
if I now press Ctrl-R again, I get (note the second line which was not “cleaned”):
root [0] [bkw'2.5'] 2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
The tail of the history was:
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54*2.54
.q
Hi Pepe,
Could you explicit how ‘Ctrl-G’ and ‘Ctrl-J’ currently fail (for clarification)?
Thanks,
Philippe.
Well, in general I would like to have the “readline” behavior:
Ctrl-G - abort an incremental search and restore the original line
Ctrl-J - end an incremental search
http://www.bigsmoke.us/readline/shortcuts
http://unixhelp.ed.ac.uk/CGI/man-cgi?readline+3
http://cnswww.cns.cwru.edu/php/chet/readline/readline.html
I’m not sure, but I think in ROOT 5.18 (I know it’s very old) everything was fine.
Hi Pepe,
this is not a question of consensus, it’s a question of what I can reproduce and thus repair.
With your new detailed reports (thank you!) I see one bug: long lines are not cleared properly and instead mess up the screen. I will fix it and created savannah.cern.ch/bugs/index.php?91752 as a reminder.
The behavior in 5.18 was: “Typing ESC or any other editing character accepts the current match and loads it into the buffer, terminating the search.” (The code agrees So while ^G nor ^J were not handled explicitly, any input but e.g. ^R / ^S and ESC did the job. I will implement ^G and ^J as you proposed. ^G is already handled but does the wrong thing 
And I see that ^S was working, and stopped with the introduction of the textinput library. I will implement that, too, even though it has lower priority - you are the first to ask I suppose it’s because usually people search backwards in history.
Again, thanks for insisting and allowing me to reproduce the problem!
Cheers, Axel.
Sorry, I forgot about “Esc” (i.e. “Ctrl-[”) -> it should do the same as “Ctrl-J”, I believe.
Hi,
Yes, that was the plan… but I see that it currently fails. I have now fixed it in the trunk. Thanks for your report!
Cheers, Axel.
Hi,
^G, ^J, ESC, and ^R with long lines are now implemented / fixed. Thanks for your reports!
Cheers, Axel.