I think the place for deciding how lines should be joined is in paste-buffer or save-buffer (they can use common code if necessary), not in the copy mode.
On Fri, Feb 19, 2010 at 05:25:36PM +0100, clemens fischer wrote: > Robin Lee Powell wrote: > > > Copying from my other post: > > > > The other aspect to it is having a key that can shift between the > > various options. My idea there is to store the > > pass-through-before-pasting command in a (window?) option, and make > > a tmux command that takes an option name and a list of possible > > values. Every time it's called, it checks for the current value in > > the list, and moves to the next one. This would be a fully general > > solution that people could use for other things. > > > > (end copy) > > Nicholas Marriott suggested in: > Message-ID: <20100218225106.gd17...@yelena.nicm.ath.cx> > Archived-At: > <http://permalink.gmane.org/gmane.comp.terminal-emulators.tmux.user/350> > > to make tmux rotate through any multi-valued option like boolean options > toggle. This is much like your idea. > > What I have in mind is something special for any selection and would > only apply to copy-mode: a per-window (per-pane?) option in a special > struct hanging off of "struct window"(?), roughly: > > struct selection_op { > int (*fun)(struct screen_sel *)[5]; > unsigned cur_selection_op; > }; > > Then there would be five possible selection operators coded as functions > and selected by repeated use of 'J' in copy-mode. There would be > functions joining the lines of the selection by spaces, commas, > line-feeds plus a function running an execlp(3) on a new per-window > possibly named "selection-op", which should point to a user supplied > program given the selection on stdin. > > I'm not sure if it's worth the trouble to have selection_op.fun be > a list or splay-tree. > > > Rather than rotating through option settings, though, it could just as > > easily rotate through key bindings. > > I'd rather prefer real nested keymaps, where some key could be defined > as opening an entire new key-space, such that eg. ABC would be defined > as > > newkmap groups > newkmap subgroups > bind A readkey groups > bind B readkey subgroups > definekey groups Escape abort > definekey subgroups C-g abort > definekey subgroups C <some-command> > > This is ratpoison syntax, btw. For the existing keybindings tmux could > have a top-level keymap, of course. > > > clemens > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
