Re: [dev] structural regular expression support for vis

From: Marc André Tanner <>
Date: Fri, 10 Feb 2017 22:47:24 +0100

On Mon, Feb 06, 2017 at 10:25:35AM +0000, Raphaël Proust wrote:
> On 3 February 2017 at 20:30, Marc André Tanner <> wrote:
> > On Fri, Feb 03, 2017 at 10:00:37AM +0000, Raphaël Proust wrote:
> > […]
> >> :x/pattern/ t h c/replacement/
> >
> > Not sure this is flexible enough? How would you generalize this to
> > operate on the n-th dot in a convenient way?
> :x/pattern/ t5 h c/replacement/ ← pops five matches out, selects the
> sixth and replaces it.
> :x/pattern/ t2 T2 c/replacement/ ← pops the first two matches out,
> then the last two matches out, then replaces all the others.
> The idea of t and h is to mimic tail(1) and head(1). The
> capitalisation (t/T, h/H) corresponds to passing positive or negative
> counts to those filters (head -n 10/head -n -10, and similarly for
> tail).

I don't like that this would introduce 4 new commands. I believe the
same functionality can be better integrated in a different way. We
already have commands `g` and `v` to filter existing matches based
on a regular expression. Extending them to also support an optional
count specifier seems natural. As for the exact syntax it could be
similar to list comprehensions (e.g. to be able to express selecting
every n-th match) as found in various programming languages.

> > I thought about introducing a count specifier for either `x` and `y`
> > or `g` and `v`. Because these commands take a regular expression not
> > an address the count is unambiguous here:
> >
> > x3/pattern/ command
> > x/pattern/ g3 command
> >
> > would only execute command for the third match. Similarly, `y` and `v`
> > would execute it for all but the third match.
> I like this syntax, especially the g/v one (see below how it extends
> better). I don't think it's sufficient. Here are example of things I
> don't think this can do with suggestions on extending this syntax.
> - select the last match (albeit x-1 and g-1 could be used),

Yes, -1 could work.

> - select all but the first (G1 could be used, but X1 could not),

That is what the `v` command is for? It executes whenever its count
specifer (regex pattern) does *not* match. In this case: y1

> - select all but the n first (again Gn),

Maybe `gn-` or `v1-n` ?

> - select all but the n last (G-n).

`g1-n` or `vn-` ?

But maybe the added complexity is not worth it.

> >> So currently `X` is more like vim's `windo`. I use `bufdo` more often.
> >> I'm undecided whether offering both is worth the added complexity and
> >> features.
> >
> > I think it would be much cleaner to add both variants rather than
> > duplicate some functionality. If we had a proper way to loop through
> > files some vi originated commands like `bdelete` might become obsolete
> > and could be removed.
> W for window, X for file?
> Z, Y?

Or V and W, albeit V would have a conflicting meaning with v.

> It's not ideal, especially because `w` is for write…
> Alternatively, because these are less frequent than the other
> operators (x, g, c, etc.), maybe they don't need to be single letters.

That would make them a bit alien to the rest of the commands ...

> I have also started testing it and using the github issue tracker for
> your project. I'll use this thread for the design discussion and the
> issue tracker for minor things and other more specific improvements.
> Let me know if these are not your preferred channels.

That is fine. Thanks for the feedback.

 Marc André Tanner >< >< GPG key: 10C93617
Received on Fri Feb 10 2017 - 22:47:24 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 10 2017 - 23:00:07 CET