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
case.
> - 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 >< http://www.brain-dump.org/ >< GPG key: 10C93617
Received on Wed Apr 06 2016 - 23:33:32 CEST