Re: [dev] structural regular expression support for vis

From: Marc André Tanner <>
Date: Fri, 3 Feb 2017 21:30:06 +0100

On Fri, Feb 03, 2017 at 10:00:37AM +0000, Raphaël Proust wrote:
> On 2 February 2017 at 17:46, Marc André Tanner <> wrote:
> > Sam supports a count specifier: s2/pattern/replacement/ only replaces
> > the second occurrence of pattern. This is currently not supported but
> > can be mimicked using:
> >
> > :/pattern/ // c/replacement/
> >
> > A more general variant of the count concept might be later integrated
> > into the x, y and/or g, v commands. Comments and syntax suggestions
> > welcome.
> My sam addressing is rusty, but IIRC, `/pattern/+/pattern/` search for
> the second match of `/pattern/`. (The `+` operator for addresses:
> “a1+a2 The address a2 evaluated starting at the end of a1.”)

That is correct, but `+` can be elided here. Also when pattern is
omitted the last used one is substituted in (this might be missing
from the vis man page, but it is mentioned in sam(1)). Hence
`/pattern///` is an abbreviation of your `/pattern/+/pattern/`.

> Maybe, rather than a special case for `s`, this suggest that the

Yes special cases should be avoided, but as illustrated above this is
actually not the case here.

> address `n/pattern/` could be read as `n` times `/pattern/` which is
> `/pattern/+…+/pattern/`. Would that interfere with the other
> addressing modes?

Yes, with the current semantics it searches for `pattern` at the end
of line `n`.

> I think it's ok because compound addresses all use
> explicit operators (`+`, `-`, `,`, `;`). As a result, `2/pattern/` is
> distinguishable from `2+/pattern/`, `2-/pattern/`, etc.

As mentioned above `+` can be elided, hence `2+/pattern/` and
`2/pattern/` are equivalent.

> Alternatively, a command to manipulate dot collections could be used
> to provide a "2nd match replacement" feature. In this case, new
> operations say `h` and `t` (short for head and tail) would select,
> respectively, the first of the multiple selected dots and all but the
> first dot.
> :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?

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.

> > * Multi file support is not really well supported:
> >
> > - The X and Y commands currently operate on windows, not files.
> > Meaning that if a file is being displayed in multiple windows
> > a given command will be executed once for every window. This is
> > desired in certain cases (e.g. `:X q` to close all windows without
> > unsaved changes) and unwanted in others (e.g.
> >
> > :X 0i,/* ISC licensed */\n
> >
> > to add a license template to the top of every file).
> 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.

> IIRC, X (and Y) can only appear at the beginning of the command.

I think they can be used arbitrarly, but "only one instance of either
`X` or `Y` may appear in a single command". This is actually currently
not enforced by vis.

Thanks for your comments!

 Marc André Tanner >< >< GPG key: 10C93617
Received on Fri Feb 03 2017 - 21:30:06 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 03 2017 - 21:36:15 CET