Re: [dev] structural regular expression support for vis

From: Marc André Tanner <>
Date: Mon, 28 Mar 2016 23:52:39 +0200

On Mon, Mar 28, 2016 at 06:46:40PM +0100, Connor Lane Smith wrote:
> On 27 March 2016 at 17:10, Marc André Tanner <> wrote:
> > You could also try `make local` which might or might not work ...
> It didn't. Anyway, today I unfortunately found myself with nowt but a
> Mac, though I did manage to get vis to compile. I had to make a couple
> of changes to get it to work. Diff attached, if you're interested. It
> needed _DARWIN_C_SOURCE because SIGWINCH is neither POSIX nor XSI.

As you noticed, ./configure && make should work. In principle I do not
like configure scripts either. However in this case it seemed more user
friendly because some dependencies are optional and could be auto detected.
Manually providing is still supported and the configure script
is not based on GNU autohell tools.

> Some problems I came across:
> Just a config issue I suppose, but I kept quitting the editor by
> accident, having typed 'x/foo/' without ':sam' in front of it.

Yes, I agree this is annoying. The question is how to best integrate
this with the existing vi command line. For example stuff like :wq is
muscle memory by now and should still work.

> If you write ':sam x' then I would expect it to split the selection
> into lines (defaulting to /.*/), as 'x' would in sam. Instead it says
> "bad regular expression."

Fixed. Previously only a space was recognized as /.*/ i.e (as in sam?)
you can write ':sam x g/foo'

> ':sam x/.*/g/foo/' selects those lines containing foo, but ':sam
> x/.*/' followed by ':sam g/foo/' seems to result in all but the last
> selection being lost.

Should be fixed. As of this morning duplicated cursors at the same
position are prevented. In case the regexp matches, g/ would try to
re-create the same exact selection and thus fail.

> Selections seemed dodgy after I did ':sam y/bar/'. I'm not sure what
> their behaviour was after that, but it didn't seem at all consistent
> again until I hit ESC.

We do not prevent selections from overlapping thus once your motion
commands cause an overlapping, all kinds of apparently strange things
can happen. Might this have been the issue you encountered?

If the selections span more than the current viewable area,
Ctrl-{u,d} (possibly with a count) is currently the only way to get an
overview of what actually was selected.

> I also got it to segfault on master, but there was a bit of
> key-mashing (in the command entry box) and I haven't managed to
> reproduce it.
> I'll let you know if I have any more progress with it.

Thanks for spending some time trying it out!


 Marc André Tanner >< >< GPG key: 10C93617
Received on Mon Mar 28 2016 - 23:52:39 CEST

This archive was generated by hypermail 2.3.0 : Tue Mar 29 2016 - 00:00:32 CEST