On Fri, Feb 19, 2010 at 09:59:47PM +0100, clemens fischer wrote: > Robin Lee Powell wrote: > > > On Fri, Feb 19, 2010 at 05:25:36PM +0100, clemens fischer wrote: > > > >> 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. > > > > See, this (having the options in code) is exactly what I don't want. > > I want all the J options to be configurable by the user, which is why > > I suggested a command to rotate through all the options it is passed. > > I understand. Note that I want at least one of the selection-op's to be > a user configurable, user supplied script. Having a few hard-coded ones > for the simple case of replacing newlines is just a convenience, > I needed that often. > > If I understand correctly, you and Nicholas are striving for a more > generic, reusable solution, and that is certainly fine with me. I just > cannot imagine how this works in the case of selection post processing. > If you mean to rotate through key-bindings, I already see "letter > starvation" as a problem. > > >> > 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. > > > > How does that help get J-type behaviour? That is: how could that be > > used to rotate through N options with one key?
I want something sort of like this too, although with better syntax. It has been on the todo list for ages but no time. > > It doesn't. But it allows to have any number of J<x> commands without > cluttering up one keytable. X?Emacs has make-keymap like many other > interactive programs. I threw it in because rotating through key > bindings was mentioned. > > > 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