On Fri, Feb 19, 2010 at 09:55:06AM -0800, Robin Lee Powell wrote: > You keep saying that, and it took me a while to figure out what you > meant, so let me expand. > > In screen, the exact work flow was: > > hilight a selection > > convert the newlines in the selection to something else > > copy the selection > > paste the selection > > I think what you're asking for is this work flow: > > copy a selection > > convert the newlines in the selection to something else > > paste the selection
I think the last two steps should be the same, like paste -r, then people can just bind what the want to the keys they want. > > I don't think any of us talking about emulating screen J actually > *care* which of those two is used; I certainly don't. Hopefully > everybody can ACK that they understand that you want the second one > and stop talking about J in copy mode. :) > > -Robin > > On Fri, Feb 19, 2010 at 05:11:04PM +0000, Nicholas Marriott wrote: > > 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 > > -- > They say: "The first AIs will be built by the military as weapons." > And I'm thinking: "Does it even occur to you to try for something > other than the default outcome?" See http://shrunklink.com/cdiz > http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ ------------------------------------------------------------------------------ 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
