The find API introduced in #704 can be expanded upon in the future to support:
It would also be great to have an api that gets the total number of matched instances, and the index of the currently active instance, as well as a mechanism to get notified when the total number or active index changes. This would allow a consumer to draw a find UI and provide some more info to the user.
@mofux this was one of the first thoughts I had, I left it out due to performance concerns as it's not the most efficient thing to convert a large buffer into searchable strings as each individual character is stored within it's own array. The buffer is basically structured like this: [number, string, number][][] so you need to iterate through the lines and then construct a string out of the line.
Definitely worth exploring later on whether my guesses around this are true though 👍. I added it to the list 😃
@Tyriar Interesting to see that a modern terminal emulator shares so many problems with code editors like ace or monaco, like line buffers, selection models, find api, tokenization. Actually, I remember that the cloud9 terminal does all the rendering through the Ace editor 😉
@mofux yeah it's been useful to have people who work on monaco to ask about things. A lot of stuff poses similar problems. The fact that the buffer is continuously trimmed and that it's common to run a command that get a crazy amount of data streamed in are biggest unique parts.
It would be nice to have a browser-style “find-as-you-type” logic. I think it would work if a couple functions were added:
findCurrentOrNext(needle)findCurrentOrPrevious(needle)These would expand the current selection if the needle is present at the 0-index of the current selection; otherwise they’d do a normal findNext or findPrevious.
Thoughts?
@FGasper yeah this sort of thing would be good, probably best tackled after this one: Find multiple instances on the same line. Added it to the list
Coming from #1649 I suggest to split up the functionality of the search addon into:
indexOf and return a cols/rows positions, feeding this back gives the next position, as an advantage this will not need any DOM related stuff.Most of this is done, let's track the rest in individual items: https://github.com/xtermjs/xterm.js/issues/1653, https://github.com/xtermjs/xterm.js/issues/1654, https://github.com/xtermjs/xterm.js/issues/1659
Most helpful comment
It would also be great to have an api that gets the total number of matched instances, and the index of the currently active instance, as well as a mechanism to get notified when the total number or active index changes. This would allow a consumer to draw a find UI and provide some more info to the user.