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
