Command line editing

ROOT
1

Hi,

In emacs style command line editing, incremental search action of Ctrl-r (^R) is strange, and Ctrl-s (^S) does not work since v5.22.

Do you have any idea?

Thanks,
SN

2

Hi,

For me, ^S works: it freezes the terminal (but Ubuntu did disable that, so you’ll have to enable it explicitly before).

How is ^R strange?

Axel.

3

Hi,
Thank you for your reply.

I did this with ROOT 5.30/00 on Ubuntu 11.04 and Mac OS X 10.6.
When “~/.root_hist” is like below, and type ^R + "macro"
0 .x macro0.C
1 .x macro1.C
2 .x macro2.C
3 .x macro3.C
4 .x macro4.C
5 .x macro5.C

I want to reverse one by one (5, 4, 3, …, 0).
First time typing ^R + “macro” gives me back 5. (This is OK.)
Typing ^R again, incremental search is reset and I cannot have any results.
Third-time ^R starts a new incremental search.

In ROOT 5.20/00, ^S used to work as forward search.
Will you tell me how I can set the behavior of ^S?
“stty stop undef” in bashrc does not work for ROOT.

SN

4

Does nobody ever use incremental search?
It is very stressful for me to use ROOT interactively without command line editing.

The commands with Meta are broken too in 5.30, (M-b, M-f, M-d, and M-Backspace).
These commands works just after launching ROOT.
After I type some lines (opening files, executing macros…), they stop working.

Thanks,
SN

5

Hi,

Thanks for reporting the ^R^R issue; now fixed in the trunk. I have implemented M-backspace.

I cannot reproduce the problem with M-b etc not working. Can you find something that reproduces this reliably?

Axel.

6

Hi,

Just type ^R^R to invoke incremental search.
Then the commands with Meta stop working.

SN

7

Hi SN,

awesome, thanks a lot!!! I had reports of this before but nobody was able to come up with a simple recipe that would allow me to reproduce it. Well done.

Now fixed in the trunk and v5-30-00-patches!

Cheers, Axel.

8

Hi Axel,

Don’t know if this has been covered yet, but I get funny behavior when using C-a/C-e and the current editing line wraps around. The keys work flawlessly otherwise. I am using this afs build of root:

/afs/cern.ch/sw/lcg/app/releases/ROOT/5.30.01/x86_64-slc5-gcc43-opt/root

I first noticed this when I downloaded your textinput library from svn a few days ago and tried to play around with your example main function to achieve a ‘tab-completion’ in castor paths. I was able to succeed, however, many files in castor have extremely long names and if I try to edit the line with C-a/C-e the cursor gets confused.

You should be able to reproduce this in the root prompt with something like:

.! ls “/afs/cern.ch/user/g/griffith/public/…/…/…/…/…/…/…//afs/cern.ch/user/g/griffith/public/…/…/…/…/…/…/…//afs/cern.ch/user/g/griffith/public/…/…/…/…/…/…/…/”

Then if this wraps around in your terminal do:
C-a # works
C-e # somewhere in the middle
C-a # now the cursor is very confused

Also another request for M-F/M-B is it possible to make these more like bash? A word in my bash prompt ends at a ‘/’ not only at ‘"’ or ’ '. I would understand, however, if others may prefer the current implementation .

Cheers,
Justin

9

Hi Justin,

Thanks for your report and your nice example! It’s now fixed in the trunk and v5-30.

Cheers, Axel.

10

Hi,

Concerning the word boundaries: That’s the string literal in Editor.cpp:425. I am not sure what it should be, but e.g. emacs agrees with you - and I wouldn’t mind. We should presumably add all non-identifier characters as word-boundaries. But then “find_first_of” is inefficient; it should be reverted. Or maybe we should just code the condition by hand.

Would you be able to suggest a patch?

Cheers, Axel.

11

Hi Axel,

Thanks for the fix. So it is also fixed in the svn trunk of textinput that you link in the root blog?

If I can think of a patch I will certainly let you know, however, I doubt I could come up with an efficient solution. The issue doesn’t really bother me that much was just curious and am now glad to see exactly where in the code I can play with it.

Thanks,
Justin

12

Never mind already updated the trunk and see the fix in my test app.

13

Hi Axel,

A possible solution is to use the TString type ‘IsAlnum’ type function which uses:

root.cern.ch/root/html/src/TString.cxx.html#1663

isalnum

cplusplus.com/reference/clib … e/isalnum/

which seems to have a valid c++ header. So assuming that isalnum takes advantage of the ‘possible’ fact that the alphanum chars are consecutive(depending on platform?), one could just write an efficient function that looks for first/last non-alnums.

So I have attached a fast implementation that checks for the last non alnum character. I have tested it against std::string::find_last_of(" ")// and results seem to be consistent. I have also tested it verse
std::string::find_last_of(“all_non_alphanum_charactersI could think of”) and see that my implementation is much faster. Either way doing 10M tests on each imp never exceeds 2 seconds.

So I think that emacs/bash/csh/tcsh word-boundaries can be implemented efficiently(at least on my computer…), however, users of zsh maybe be in for a surprise(an office mate who uses zsh does not like its(zsh) current implementation).

Cheers,
Justin

P.S. root libs only necessary for TStopwatch
isalnum.cxx (1.43 KB)

14

Hi Axel,

Attached is a tarball with a proposed patch to Editor.cpp. I just made two functions instead of using std::string::find_first/last_of. Also I have updated the previous standalone speed test since I want to find the first non alphanumeric after finding at least one alphanumeric. This avoids cases such as:

root[0]: asdfsdf iiiioi asdfbasdfb iiiiii

where each individual space is searched causing multiple spaces in a row to be treated as multiple space rather than a single block of uninteresting characters. Note that although my functions perform the same on my SLC5 amd64 as std::string::find_last_of(" "), the std::string function is about 2x faster on my MAC. Still my functions are faster(4x) than string::find_last_of(“manychars”). Any implementation seems to be much faster than ones fingers can move.

It also seems that undo(^_) does not work properly. Actually it does repaste, however, the line is not being redrawn and the cursor does not move.

root[1] asdf;laksdf
^a^k
^_
root[2]
\r
Error: Symbol as is not defined in current scope (tmpfile):1:
*** Interpreter error recovered ***
root[3]
//press arrow up
root[3] asdf;laksdf

Cheers,
Justin
bundle.tgz (4.27 KB)

15

Hi,

Awesome! Thanks! Slightly modified and committed.

Thanks for reporting the ^_ bug; now fixed.

Cheers, Axel.

16

Great!

Thanks,
Justin

17

Hi Axel et al.,

is the Ctrl-R issue really solved in root 5.30.02 ? I had it in 5.30 and today I downloaded the patches but it still does not work…Does it work for everybody else ? for me ^R only finds the first istance and then it resets itself at the second try. Thanks cheers
giulia

18

Hi Giulia,

Does this work for you properly in v5.32?

Philippe.