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?
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
