complete strings from all windows
Closed this issue · 6 comments
Great plugin! Currently only panes in the current window are scraped. But it's possible to get strings from all windows with something like this:
tmux select-window -t :2 && tmux capture-pane -J -p -t 0
That captures strings from pane 0 of window 2 in the current session. Windows in the current session can be iterated with tmux list-windows.
Thank you!
We could also go one step further and complete from all sessions and also reach into the history of each pane (as you suggested elsewhere). The only downside to this would be possible performance issues which will depend on how the user is using tmux.
If one only uses three sessions with three windows each it should be fine. But if somebody uses heaps of sessions one might prefer to limit completion to the current session. This makes me consider introducing some customization regarding the scope of what is completed.
I will look into current session, all sessions and pane history and see how badly performance degrades.
Oh by the way: You don't need select-window in your example. Try this instead:
tmux capture-pane -J -p -t 2.0
General target-pane syntax: -t session:window.pane
Also list-windows is not needed as list-panes has the -s flag that list all panes in the current session (-a lists all panes in all sessions). So this is a working version:
tmux list-panes -s -F '#{window_active}#{pane_active} #I.#P' |
while read active pane; do
[[ $active -eq 11 ]] || tmux capture-pane -J -p -t "$pane"
doneShows how much I know about tmux!
Regarding performance: the loop knows how many strings it has seen, so a simple upper limit that breaks out of the loop would avoid the need for users having to fret about how many sessions/windows they have and whether they want to enable option foo or bar for the current session. The loop should always start by scraping the current window (and then other windows in the current session), so that users can expect the most "localized" strings to be present in the list.
Including scrollback history should definitely be optional, however, because it varies arbitrarily.
That's a great idea!