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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmux-users
