From Newsgroup: comp.editors

Is there in Vim a built-in simple (=non-scripting) way to automatically
number text entities by serial numbers; e.g. with an input of either

Lorem ipsum
Lorem ipsum
Lorem ipsum

or

Lorem # ipsum
Lorem # ipsum
Lorem # ipsum

to create (for example)

Lorem 1 ipsum
Lorem 2 ipsum
Lorem 3 ipsum

I've thought about something like Ctrl-v to mark a column and then have
some command to create the serial numbers, but while I can to

Ctrl-v !seq 1 3

that command will, unfortunately, replace the whole lines' contents by
the number sequence (and not only the marked column).

I can also work around it by a couple manual commands but, as said, I'm
looking for something simple, more straightforward.

For the second input sample above, with the '#' mark as placeholder, I
could also resort to an external program to do the serial numbering.[*]
So, generally, first inserting the hash marks with <Ctrl-v> I # <Esc>
(in case they are all in one column) then running the external script.
(But that would be not better than other workarounds or Vim-scripting.)

Janis

[*] E.g. with Awk: sub(/#/,++c)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Is there in Vim a built-in simple (=non-scripting) way to automatically number text entities by serial numbers; e.g. with an input of either

Lorem ipsum
Lorem ipsum
Lorem ipsum

or

Lorem # ipsum
Lorem # ipsum
Lorem # ipsum

to create (for example)

Lorem 1 ipsum
Lorem 2 ipsum
Lorem 3 ipsum

"Simple"? Probably not. It can be done. I've written tail recusive
macros to do things like this, grabbing a number to replace it on the
next line and then incrementing with ctrl-a, but recursive macros are
fraught with special cases to consider.

I've thought about something like Ctrl-v to mark a column and then have
some command to create the serial numbers, but while I can to

Ctrl-v !seq 1 3

that command will, unfortunately, replace the whole lines' contents by
the number sequence (and not only the marked column).

If you !nl instead you can number the lines and then move the number.
Using Gnu nl:

!nl -bp'\#' -w1 -s: -d ''

Number lines with a # in them, use minimum number width of 1, put a :
after the number, disable page break number rules.

Then move numbers with something like:

:g/^[1-9][0-9]*:.*#/ s,^\([0-9]*\):\([^#]*\)#,\2\1,

I can also work around it by a couple manual commands but, as said, I'm looking for something simple, more straightforward.

I would use a recursive macro for one large file, always formatted the
same, the two part nl and move for vi instead of vim or when formatting
makes a macro awkward, and a separate script (probably in perl) for a
regular operation.

[*] E.g. with Awk: sub(/#/,++c)

Not everything needs to be done by the editor.

Elijah
------
has never touched vimscript but that may have a way to do it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Tue, 7 Jul 2026 21:55:02 -0000 (UTC), Eli the Bearded wrote:

"Simple"? Probably not. It can be done. I've written tail recusive
macros to do things like this, grabbing a number to replace it on
the next line and then incrementing with ctrl-a, but recursive
macros are fraught with special cases to consider.

IsnrCOt there some version of Vim that uses Lua as its extension
language?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2026-07-08 04:50, Lawrence DrCOOliveiro wrote:

On Tue, 7 Jul 2026 21:55:02 -0000 (UTC), Eli the Bearded wrote:

"Simple"? Probably not. It can be done. I've written tail recusive
macros to do things like this, grabbing a number to replace it on
the next line and then incrementing with ctrl-a, but recursive
macros are fraught with special cases to consider.

IsnrCOt there some version of Vim that uses Lua as its extension
language?

I seem to recall that one of the features of the _neovim_ project
replaced the vim scripting language by lua. (Neovim is not a Vim
version, though.)

But note that Lua isn't necessary in Vim, one can use its native
scripting language. - Though my request was ideally looking for a
native support of that feature since I try to avoid externalities
(plugins, macros, external commands) as far as possible; I've no
plugins, only few macros that I rarely use, and only occasionally
use external commands on text sections.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2026-07-07 23:55, Eli the Bearded wrote:

In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Is there in Vim a built-in simple (=non-scripting) way to automatically
number text entities by serial numbers; e.g. with an input of either

[...]

"Simple"? Probably not. It can be done. I've written tail recusive
macros to do things like this, grabbing a number to replace it on the
next line and then incrementing with ctrl-a, but recursive macros are
fraught with special cases to consider.

Ctrl-a was actually what I was recently using manually; insert a column
of '1', mark column, then move cursor down one by one and type Ctrl-a;
works well when there's no side-effect on lines below the marked area.

I've thought about something like Ctrl-v to mark a column and then have
some command to create the serial numbers, but while I can to

Ctrl-v !seq 1 3

that command will, unfortunately, replace the whole lines' contents by
the number sequence (and not only the marked column).

If you !nl instead you can number the lines and then move the number.
Using Gnu nl:

!nl -bp'\#' -w1 -s: -d ''

I've occasionally used external line numbering with a block-cut/paste
to the desired location. Less elaborated (more simplistic) than your
approach but a sensible workaround anyway.

Number lines with a # in them, use minimum number width of 1, put a :
after the number, disable page break number rules.

Then move numbers with something like:

:g/^[1-9][0-9]*:.*#/ s,^\([0-9]*\):\([^#]*\)#,\2\1,

And at some point it's obviously time for a macro.

I can also work around it by a couple manual commands but, as said, I'm
looking for something simple, more straightforward.

I would use a recursive macro for one large file, always formatted the
same, the two part nl and move for vi instead of vim or when formatting
makes a macro awkward, and a separate script (probably in perl) for a
regular operation.

(I didn't understand your preference for Vi here, "instead of Vim".)

[*] E.g. with Awk: sub(/#/,++c)

Not everything needs to be done by the editor.

Right. - Since there's no simple builtin mechanism it might indeed be
worth to use such an external awk-primitive (perl in your case); mark
the region and call !sn (with a one-line awk script 'sn').

Elijah
------
has never touched vimscript but that may have a way to do it

I'd suspect so. But since I've also not touched vimscript myself, and
want to keep that independence, I'll continue to abstain. :-)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-07-07 23:55, Eli the Bearded wrote:

I would use a recursive macro for one large file, always formatted the
same, the two part nl and move for vi instead of vim or when formatting
makes a macro awkward, and a separate script (probably in perl) for a
regular operation.

(I didn't understand your preference for Vi here, "instead of Vim".)

Sometimes the vi I have is not vim. I learned vi on Bill Joy vi, but I
found vim less buggy and switched to that as my preferred vi. But I log
into a lot of machines and not all will have vim installed. So, like
when I write shell scripts for sh instead of bash, I keep in mind the non-improved ways to do things.

Elijah
------
actually very, very rarely uses bash with bash-isms, but ksh-isms sometimes
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

with <112igko$2n4ld$1@dont-email.me> Janis Papanagnou wrote:

Is there in Vim a built-in simple (=non-scripting) way to
automatically number text entities by serial numbers; e.g. with an
input of either

*SKIP* [ 4 lines 1 level deep]

Lorem # ipsum
Lorem # ipsum
Lorem # ipsum

to create (for example)

Lorem 1 ipsum
Lorem 2 ipsum
Lorem 3 ipsum

*SKIP* [ 5 lines 1 level deep]

I can also work around it by a couple manual commands but, as said, I'm looking for something simple, more straightforward.

:%s, # ,\=" " . line(".") . " "

You owe me 10min.

p.s. Also, vimBASIC isa bitch.

*CUT* [ 7 lines 1 level deep]
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

In comp.editors, Eric Pozharski <apple.universe@posteo.net> wrote:

:%s, # ,\=" " . line(".") . " "

You owe me 10min.

p.s. Also, vimBASIC isa bitch.

What if # should start at 1 even if the first "Lorem # ipsum" does not
appear until line 20?

Elijah
------
did not know you could trigger scripting from a substitute command
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2026-07-08 23:17, Eli the Bearded wrote:

In comp.editors, Eric Pozharski <apple.universe@posteo.net> wrote:

:%s, # ,\=" " . line(".") . " "

You owe me 10min.

???

p.s. Also, vimBASIC isa bitch.

???

What if # should start at 1 even if the first "Lorem # ipsum" does not
appear until line 20?

Indeed - that's a crucial restriction! (And replacing the '%' by a
range e.g. '<,'> also doesn't fix it.) I'd suppose you might be able
to use a static variable instead of 'line()', but I don't intend to
explore Vim's scripting (which I wanted to avoid in the first place).


Meanwhile, since the external command approach was so easy, and the
external command so trivially short, I slightly extended my original
Awk code - sub(/#/,++c) - and have now

{ while (match ($0, /#+/))
sub (/#+/, sprintf ("%0*d", RLENGTH, ++c))
print
}

with the additional properties to change the #-markers also if they
appear multiply on a line, and to be simply able to create leading
zeroes as in

Lorem ## ipsum
Lorem # ipsum ### xyz
Lorem # ipsum # # quit

Lorem 01 ipsum
Lorem 2 ipsum 003 xyz
Lorem 4 ipsum 5 6 quit

Elijah
------
did not know you could trigger scripting from a substitute command

Likewise. :-)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

with <eli$2607081717@qaz.wtf> Eli the Bearded wrote:

In comp.editors, Eric Pozharski <apple.universe@posteo.net> wrote:

:%s, # ,\=" " . line(".") . " "

You owe me 10min.

*SKIP* [ 1 line 0 level deep]

What if # should start at 1 even if the first "Lorem # ipsum" does not
appear until line 20?

Adopt to your context. Go wild.

*CUT* [ 3 lines 1 level deep]
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

with <112mtut$2n4lc$2@dont-email.me> Janis Papanagnou wrote:

On 2026-07-08 23:17, Eli the Bearded wrote:

In comp.editors, Eric Pozharski <apple.universe@posteo.net> wrote:

:%s, # ,\=" " . line(".") . " "
You owe me 10min.

???

Time spent digging through help.

p.s. Also, vimBASIC isa bitch.

???

:h sub-replace-special

I'd just spotted it. During grepping. Because peripheral vision. I
don't think I could find this otherwise:

:h sub-replace-expression

*CUT* [ 26 lines 2 levels deep]
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

Meanwhile, since the external command approach was
so easy, and the external command so trivially
short, I slightly extended my original Awk code -
sub(/#/,++c) - and have now

What follows is not a new answer to the OP's
original question, just some random curiosities.
May I first note that the approach of piping to an
external command is not a hack nor a kludge, but a
core idea of using a UNIX computing environment.
I personally do enjoy it, very much, and it's why
an ed-like editor, or at most classic vi, is all I
usually need to do all my programming and writing
work. UNIX is the IDE. In this specific use case
I do think piping to an awk script is a reasonable
and elegant solution. In vim, all you need is to
mark the lines where your # is (I use `V', then
select all the lines), and then:

:'<,'>!awk 'sub(/\#/,++c)'

In ed or vi, you can of course use register
marks instead of a selection, 'a,'b would be your
range for example, instead of '<,'>. I also enjoy
putting such commands into little shell scripts in
a directory in my home folder, and then adding the
directory to the $PATH of my editors using wrapper
shell functions, or aliases. For example:

~/.edit/nl

#!/bin/sh
# replace the string passed
# as arg1 with counter numbers.
awk "sub(/$1/,++c)"

then:

chmod +x ~/.edit/nl

then use a shell alias to call your editor, with
the added PATH directory, possibly putting this in
your ~/.bashrc file:

alias vi='PATH="$HOME/.edit/:$PATH" vi'

And now, in vi, you can just run:

:'<,'>!nl '\#'
or
:'<,'>!nl NUM

replacing # or NUM with numbers. As long as you
stick with POSIX tools, then your custom edit
scripts are going to be very portable, and no need
to worry about updates or management or complexity
of dozens of vim scripts and plugins. POSIX tools
tend to be very stable over time, you might go a
decade before a minor breaking change happens here
or there. And to have them on another machine is
a simple matter of scp for the .edit directory, or
even just typing the commands in yourself if you
don't need them frequently. I have little scripts
like this for all kinds of tasks, like centering
text (shell's printf is usually pretty useful), or
marking tasks in my to-do list with various status
markers (little sed scripts), various insertion
scripts for putting in separators or IDs or links,
I even have some tiny C programs, used in the same
way, for example to align the content of multiple
lines to some common part that match some regular
expression; to align some lines to the equal sign
for variable assignments, you do:

:'<,'>!align =

Emacs has a feature I enjoy, where you start
recording a macro using F3, and then each time you
press F3 again you add a macro step to increment a
counter, and print its value at the current cursor
position. The counter is persistent between macro
runs in the same session, so solving your problem
above is trivial in Emacs, without even needing a
placeholder character like # or such. Just F3, go
to the place you want the number, F3 again, then
F4 to finish recording, Then M-100 C-x C-e to run
it 100 times for example, and thus generate 100
line numbers. I've seen a few places where such a
feature would have made things easier, when I used
vim here and there.

Just some thoughts,
Happy editing, friends~


Best Regards,
Lumin Etherlight
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On 2026-07-10 01:15, Lumin Etherlight wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

Meanwhile, since the external command approach was
so easy, and the external command so trivially
short, I slightly extended my original Awk code -
sub(/#/,++c) - and have now

What follows is not a new answer to the OP's
original question, just some random curiosities.
May I first note that the approach of piping to an
external command is not a hack nor a kludge, but a
core idea of using a UNIX computing environment.

Yes.

I personally do enjoy it, very much, and it's why
an ed-like editor, or at most classic vi, is all I
usually need to do all my programming and writing
work. UNIX is the IDE. In this specific use case
I do think piping to an awk script is a reasonable
and elegant solution.

A core point of my original request is that, while the '!'
mechanism is standard, my own tools (like the awk scripts)
are _non-standard_! - That's the reason why I try to avoid
that and prefer Vim built-in solutions to externalities,
be it my own or, worse, third party external tools.

(In my personal environment I have tons of useful scripts
but when I change the working environment these scripts
will not be available!)

[...] For example:

~/.edit/nl

#!/bin/sh
# replace the string passed
# as arg1 with counter numbers.
awk "sub(/$1/,++c)"

Actually I didn't need to use arbitrary characters as
placeholders (in practice I see no advantage to allow
other characters; YMMV). *If* it would be necessary I
could always do a substitution, say, :<range>s/@/#/g
beforehand. For awk programs I also need no additional
shell as interpreter and my pure awk scripts are simply
like this

#!/bin/awk -f
sub(/#/,++c)

and directly usable without environmental changes and
complications (as illustrated below).

then:

chmod +x ~/.edit/nl

then use a shell alias to call your editor, with
the added PATH directory, possibly putting this in
your ~/.bashrc file:

alias vi='PATH="$HOME/.edit/:$PATH" vi'

That's all organizational ballast I don't need and avoid
if unnecessary.[*]

At this point I want to remind, and don't want to get me
wrong, that the original question was formulated exactly
as it was because I wanted something most simple without
(or with fewest possible) assumptions or environmental
changes. As a 40+ years long Unix user I'm well aware what
you can do with the Unix tool-chest ("IDE" as you called
it). It's not about what you *can* all do; we know that.
It's about minimizing dependencies and minimum impact.

And now, in vi, you can just run:

:'<,'>!nl '\#'
or
:'<,'>!nl NUM

replacing # or NUM with numbers. As long as you
stick with POSIX tools, then your custom edit
scripts are going to be very portable, and no need

(Your suggestion is using non-standard .bashrc, mind. No
biggie, though, since you can also use POSIX sh rc file.)

In case of non-standard setups I'd prefer ksh functions
and FPATH (instead of aliases and local PATH changes).

to worry about updates or management or complexity
of dozens of vim scripts and plugins. POSIX tools
tend to be very stable over time, you might go a
decade before a minor breaking change happens here
or there. And to have them on another machine is
a simple matter of scp for the .edit directory, or

You obviously have some specific working environments in
mind where you have full control over the environment.
That's fine. And privately, at home, I have that control.

But, over the decades of my professional work, that had
been only rarely the case; usually you just have what
the IT management allows within the respective policies.

even just typing the commands in yourself if you
don't need them frequently.

And that's what makes it a non-desirable approach, and
my seeking for a "most simple" way to tackle that.

I have little scripts [...]

Yes, and I'm sure most of us Unix folks have lots of
such useful home-brew (non-standard) scripts.

$ ls ~/bin | wc -l
229

Emacs has a feature I enjoy, [...]

I'm not interested in Emacs. - But I'm curious why you
are actually using two very different powerful editors.

Just some thoughts,

Thanks.

Janis

[*] I'd like to also note that I usually don't need or
use aliases. While my preinstalled .bashrc is full of
this crap my .kshrc contains just one line set -o vi .
I'm typically using shell functions, which are much
more flexible and have less restrictions than aliases.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Fri, 10 Jul 2026 02:15:33 +0300, Lumin Etherlight wrote:

May I first note that the approach of piping to an external command
is not a hack nor a kludge, but a core idea of using a UNIX
computing environment. I personally do enjoy it, very much, and it's
why an ed-like editor, or at most classic vi, is all I usually need
to do all my programming and writing work. UNIX is the IDE.

True enough. But there is a right way and a wrong way to do it.

The wrong way is to spawn a shell which then executes a command
string. This requires the command string to have any shell specials
properly escaped, which is a complication you can really do without,
and is often mishandled by lazy programmers.

The right way is to spawn the external command directly, and feed it
an array of command-line arguments, that donrCOt need any escaping of
shell specials, because there is no shell intermediary involved.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

On Fri, 10 Jul 2026 02:15:33 +0300, Lumin Etherlight wrote:

May I first note that the approach of piping to
an external command is not a hack nor a kludge,
but a core idea of using a UNIX computing
environment. I personally do enjoy it, very
much, and it's why an ed-like editor, or at most
classic vi, is all I usually need to do all my
programming and writing work. UNIX is the IDE.

True enough. But there is a right way and a wrong way to do it.

The wrong way is to spawn a shell which then executes a command
string. This requires the command string to have any shell specials
properly escaped, which is a complication you can really do without,
and is often mishandled by lazy programmers.

The right way is to spawn the external command directly, and feed it
an array of command-line arguments, that donrCOt need any escaping of
shell specials, because there is no shell intermediary involved.

Why is it the wrong way? I understand there
are caveats to it, but there are also advantages.
I prefer the spawning of an intermediary shell in
such cases, as it allows me to use shell features,
such as various shell expansions, especially shell
variables, plus allowing easy redirect of content
to temporary files, or reading and filtering stuff
from other files into my current file, and piping
the text from one command to another. I use such
things all the time, multiple times a day. I also
don't handle any escaping in the code of the tools
I build to work in this pattern, but instead make
it clear that a shell is being spawned here, and
the responsibility of any escaping is on the user.
Of course escaping is rarely an issue, because the
actual content of the file is never passed to any
sub-commands as an argument, but is always piped
around as standard input and output, thus requires
no escaping. What requires escaping is only the
arguments passed into the command by the user, and
that is no different from using a normal shell. I
do support the spawning of the external command
directly if the feature is /abstracted/ away, and
the user has no idea the shell will be there. For
example, you provide a search and replace feature,
which uses an external command internally. Users
don't really care about the implementation details
and just want to replace stuff. In that case, you
should of course not surprise them by spawning an
intermediate shell that would crash out with weird
errors if their replacement text has a dollar sign
or what not. But in cases where the feature being
advertised is specifically "you can use any shell
commands to do whatever you want", then I think it
is fair for the user to expect having the various
shell features they're used to. Personally, I use
wordexp(3) to add POSIX shell word expansion even
to some features that don't even spawn a shell; as
I said above, I find those expansions very useful
when building workflows that integrate UNIX tools.
Being able to do an :e wireguard-user{0..9}.conf,
or a :w ${CURRENT_FILE}.bak can be real handy, as
some minor examples.

Apologies if I missed your point somehow though :)


Best Regards,
Lumin Etherlight
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.editors

On Sat, 11 Jul 2026 03:23:53 +0300, Lumin Etherlight wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

The wrong way is to spawn a shell which then executes a command
string. This requires the command string to have any shell specials
properly escaped, which is a complication you can really do
without, and is often mishandled by lazy programmers.

The right way is to spawn the external command directly, and feed
it an array of command-line arguments, that donrCOt need any escaping
of shell specials, because there is no shell intermediary involved.

Why is it the wrong way? I understand there are caveats to it, but
there are also advantages. I prefer the spawning of an intermediary
shell in such cases, as it allows me to use shell features, such as
various shell expansions, especially shell variables, plus allowing
easy redirect of content to temporary files, or reading and
filtering stuff from other files into my current file, and piping
the text from one command to another.

If yourCOre writing a program, most of this can be done more robustly
within the program, rather than in an external shell.

[rest of wall of text deleted]

--- Synchronet 3.22a-Linux NewsLink 1.2