Re: [dev] [st] a real (I think) feature request

On Sun, Nov 01, 2009 at 02:01:06PM -0500, John Yates wrote:
>What made this mechanism so pleasant to use was that all text areas in
>the screen (editing buffers, input panes, and output transcripts)
>shared a common set of editing key bindings, similar to vi or emacs.
>A very common idiom was to list a directory, switch the input pane to
>disconnected mode, copy the directory listing to the input pane,
>modify that copy of the listing using some regular expression
>substitutions to turn it into one or more commands on each file, and
>revert the input pane to connected mode. Obviously in any *nix
>environment one can do the same thing by redirecting the output from
>ls to a file, open that file in an editor, modifying it, saving it,
>and finally sourcing the edited file in one's shell. The input pane
>mechanism simply made such operations faster and more intuitive: no
>inventing a file name, no opening a separate editor, no issuing a
>source command to one's shell.

This actually isn't especially difficult to do in vim or some
other editor. In vim alone, for instance, you can do something
like,

     :r !ls
     :v/\.js/d|s/^/rm /
     :w !sh

Most shells let you edit your commandline with an editor, too.
For instance, FreeBSD's sh(1) allows this with <Esc>v by
default, in vi mode. There's an edit-command-line script for
zsh, and I assume something similar for bash.

You can almost do the same with 9term's hold mode, but you'd
have to use sed or awk. You can definately do it with acme's
win(1) somewhat more easily, though.

-- 
Kris Maglione
Faith is a cop-out.  If the only way you can accept an assertion is by
faith, then you are conceding that it can't be taken on its own
merits.
	--Dan Barker