ved's address parser recognizes line numbers, ., $, and current-relative
offsets, but not regex search addresses. GNU ed accepts /pattern/ and
?pattern? anywhere an address is allowed; ved reports them as an unknown
command.
$ ved
a
alpha
beta
.
/beta/p
? unknown command: /beta/p
GNU ed prints beta for the same input.
The BRE engine in src/bre.rs already provides the matching this needs, so the
work is in src/address.rs. Address gains a variant carrying the pattern and
a direction, parse_one recognizes the / and ? delimiters with backslash
escaping, and resolve_one scans forward or backward from the current line,
wrapping at the buffer ends the way ed does. Resolution would need the buffer's
text, which resolve_one already receives.
Two related cleanups belong with this work. src/address.rs carries a comment
saying search addresses "wait for slice 5 when the regex engine arrives" —
slice 5 shipped the engine without them, so the comment describes a plan rather
than the program, and it should state the present limitation instead. And the
README's "Limitations worth knowing" section lists the two intentional
ed-inherited limitations without mentioning this one; whether or not the
feature lands, that section should say search addresses are unsupported, since
the compatibility claim above it leads a reader to expect them.
Compound offset addressing ($-5, 5-3) is a separate gap in the same file
and is not covered here.
ved's address parser recognizes line numbers,
.,$, and current-relativeoffsets, but not regex search addresses. GNU ed accepts
/pattern/and?pattern?anywhere an address is allowed; ved reports them as an unknowncommand.
GNU ed prints
betafor the same input.The BRE engine in
src/bre.rsalready provides the matching this needs, so thework is in
src/address.rs.Addressgains a variant carrying the pattern anda direction,
parse_onerecognizes the/and?delimiters with backslashescaping, and
resolve_onescans forward or backward from the current line,wrapping at the buffer ends the way ed does. Resolution would need the buffer's
text, which
resolve_onealready receives.Two related cleanups belong with this work.
src/address.rscarries a commentsaying search addresses "wait for slice 5 when the regex engine arrives" —
slice 5 shipped the engine without them, so the comment describes a plan rather
than the program, and it should state the present limitation instead. And the
README's "Limitations worth knowing" section lists the two intentional
ed-inherited limitations without mentioning this one; whether or not the
feature lands, that section should say search addresses are unsupported, since
the compatibility claim above it leads a reader to expect them.
Compound offset addressing (
$-5,5-3) is a separate gap in the same fileand is not covered here.