On 2 February 2017 at 17:46, Marc André Tanner <m...@brain-dump.org> wrote:
> […]
> In the meantime lots of bugs have been fixed. I would like to encourage
> all sam/acme users who are also somewhat familiar with vi(m) to try out
> current master of vis and report back on their experience:
>
> https://github.com/martanne/vis
> http://repo.or.cz/w/vis.git
I'll try it in the next few days and report. A few comments now.
> * Changes do not need to be in sequence, but only non-overlapping i.e.
> the following works as expected:
>
> :x/Emacs/ { d i/V/ a/i/ }
>
> * The s (substitute) command was dropped. Instead :x/pattern/c/replacement/
> can be used for global search and replacement. The registers \1-\9 refer
> to sub expression matches. & contains the complete matched text, hence:
>
> :x/Vi/ c/>&</
>
> has the same effect as:
>
> :x/Vi/ { i/>/ a/</ }
One thing that always bothers me with regexes is that the same syntax
(parens) is used for both overriding precedence (e.g., `(foo)*` to
specify that star operates on the sequence `foo`) and groups (to be
recalled with `\1`–`\9`).
Anyone else is bothered by this?
> 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.”)
Maybe, rather than a special case for `s`, this suggest that the
address `n/pattern/` could be read as `n` times `/pattern/` which is
`/pattern/+…+/pattern/`. Would that interfere with the other
addressing modes? 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.
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/
Capital letters `H` and `T` can be used for “the last” and “all but the last”.
This second approach is also much more powerful because it is not
restricted to addresses but in any command (included in nested `{…}`).
In a way, sam already had iterator (x y) and filter (g, G) and these h
and t simply add other forms of collection management.
Some of the number-before-address conciseness can be recovered in this
heads-and-tails approach by allowing counts for the `h`, `t`, `H` and
`T` commands. E.g., `:x/pattern/ t10 h c/replacement/`.
> * 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.
IIRC, X (and Y) can only appear at the beginning of the command. Maybe
there can be longer named commands for sifting through specifically
buffers or windows, and then there is the matter of deciding which
should X default to.
Additionally, it might be interested to sift through the files of the
current directory (e.g., to apply a command to each of the .c files).
I guess it is less important because vis seem to support globbing in
`:e` by default.
Cheers,
--
______________
Raphaël Proust
