Re: [dev] structural regular expression support for vis

From: Joshua Haase <hahj87_AT_gmail.com>
Date: Wed, 06 Apr 2016 18:40:44 -0500

Marc André Tanner <mat_AT_brain-dump.org> writes:

> On Wed, Apr 06, 2016 at 01:07:10PM -0500, Joshua Haase wrote:
> 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).

Thanks for clearing my head on the issue.

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

Maybe it just need to be documented, as they are isolated conceptualy:

- `!` operator only works when visual selection is active (visual mode).

- `:!` command only works on command mode.

They also can be represented in complete form to avoid misunderstandings.

> 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.

I used the sam `:!` command without a selection to insert information
from commands at the cursor position.

The intended behavior is not "filter my char trough command" (as I have
not selected the char) but rather:

   "insert the result from command before cursor position".

The behavior I expected from multiple cursors and without a selection
was in the same vein:

   "insert the result from command before every cursor position."

Previous commits did The Right Thing (TM), both when no selection was
made and when selection is active for one cursor.

Last commit does the former on no selection, and breaks the `:. |` solution,
and `:. <` as well.

Since the introduction of `:. <` sam, I would be happy by using `:<` to
archive the functionality I expected from `:!`.

I just think that when no address is specified, the default address
should be the current selection as in `:. |`

>> - When using multiple cursors and no selection, `<` command filters the
>> entire line instead of adding the input of that command on the
>> cursor positions.

As before, since I haven't selected the line, this is not expected.

>> `:. | 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 `>`.

It doesn't make sense to filter a single character (unless you have
*selected* them for some reason, who knows). As explained before, since
there is no selection, an insertion on the position is expected.

I also think adding a default address of "current selection" to all those
commands makes perfect sense.

>> 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.

Can you elaborate on use cases?

I can see that `:!` is needed when input from the user is expected,
but the the output is added to the current position on the file,
just as expected from the other commands.

It may also be the case that some filter require user interaction and
fails because of user not being able to provide it.

So I fail to see why there is a need to differenciate `:. |` and `:!`
behavior.

> 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.

I think it would be better to have the undo and lose the selection
rather than losing both state and selection as it currently happens.

Also, selection recovery on undo would be great to have, but it's not required,
since you get visual feedback on where the selection is.

Yeah, selecting again may be annoying in some cases... but we'll be fine.

Maybe storing just the last selection along with the piece list before a
*group* operation would do.
Received on Thu Apr 07 2016 - 01:40:44 CEST