Re: [dev] structural regular expression support for vis

From: Marc André Tanner <>
Date: Wed, 6 Apr 2016 23:33:32 +0200

On Wed, Apr 06, 2016 at 01:07:10PM -0500, Joshua Haase wrote:
> sam features work generally fine, just a few notes:
> - Since commit ab2d1ddd0 the `!` command stopped working (did bisect),
> but the command is still in the documentation and default config file.
> The commit f47ecc3518e2 claims to reimplement the command but doesn't.
> Is the intended behavior to drop `!` command in favour of sam cmds?

We have to be somewhat careful with the nomenclature here. There currently
exists both a vi operator `!` (filter) and a sam command `!` (launch
interactive program). The former is implemented in terms of the sam
command `|` (filter).

This inconsistency should probably be removed, however `|` has already
a meaning in vi (namely go to the count column).

I think the latest commit should fix the vi operators `!` and `=`.

> Otherwise, `!` only works on primary cursor, even when using multiple
> cursors.

Here you are referring to the sam command `!` which redirects stdin to
the program being launched. This is for example used for the file
open dialog (based on the vis-open shell script) invoked by `:e .`
I believe doing it only for the primary cursor makes sense in this

> - When using multiple cursors and no selection, `<` command filters the
> entire line instead of adding the input of that command on the
> cursor positions.
> `:. | cmd` and `:. < cmd` work fine and I think this should be the
> default behavior of `|`, `<` and `>` when not specifying addresses
> (this also works on selections).

This might indeed be better for `<`, but does it make sense to filter
a single character through an external process? I don't think this
should be the default for `|` and `>`.

> Also, if we are to keep `! cmd`, it could be an alias for `:. | cmd`.
> This will also fix `!` on multiple cursors.

See explanation above for the purpose of the `!` sam command.

> - When using sam commands, calling undo once does not restore the
> previous state.
> One can restore previous state by calling undo several times, but
> expected behavior is to call it once, as it is logically one
> operation. This is what sam does.

I agree this would be better. Implementing the basic functionality is
trivial (I have a local patch), making sure the cursors are all placed
correctly after such an undo operation does not seem that simple ...

In general there should probably exist a way to restore past selections.

> Thanks and keep up the good work!

Thanks for the feedback!

 Marc André Tanner >< >< GPG key: 10C93617
Received on Wed Apr 06 2016 - 23:33:32 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 06 2016 - 23:36:12 CEST