Bug 215528

The -F and -f options are incorrectly specified, as detailed in the attached fix patch to the manual pages source file.

For convenience, the diff from the resultant text is:

30,38c30,37
<      -F foldwidth
<              Causes vis to fold output lines to foldwidth columns (default
<              80), like fold(1), except that a hidden newline sequence is used,
<              (which is removed when inverting the file back to its original
<              form with unvis(1)).  If the last character in the encoded file
<              does not end in a newline, a hidden newline sequence is appended
<              to the output.  This makes the output usable with various editors
<              and other utilities which typically don't work with partial
<              lines.
---
>      -f      Causes vis to fold output lines at N columns (default 80, over‐
>              ridden by -F.), like fold(1), except that a hidden newline
>              sequence is used, (which is removed when inverting the file back
>              to its original form with unvis(1)).  If the last character in
>              the encoded file does not end in a newline, a hidden newline
>              sequence is appended to the output.  This makes the output usable
>              with various editors and other utilities which typically don't
>              work with partial lines.
40c39,40
<      -f      Same as -F.
---
>      -F foldwidth
>              Set the column width to foldwidth when using -f.
51,52c51,52
<              still doubled and hidden newline sequences inserted if -f or -F
<              is selected.  When combined with the -f flag, vis becomes like an
---
>              still doubled and hidden newline sequences inserted if -f is
>              selected.  When combined with the -f flag, vis becomes like an

Created attachment 178241 [details]
patch for vis(1) man page

Comment 3 Daniel Ebdrup Jensen 2021-01-16 22:36:47 UTC

vis(1) lives in src/contrib and, as of the transition to git, is a vendor subtree which means the patch should be filed with NetBSD, at which point FreeBSD can pull it in.

To file a report with NetBSD, please visit:
https://www.netbsd.org/support/send-pr.html

..or simply not bother, it's not as if anyone cares!

Comment 5 Mateusz Piotrowski 2021-01-18 13:27:55 UTC

(In reply to Jamie Landeg-Jones from comment #4)

Oh we do care. We really appreciate every single contribution and would love to see the patch eventually land in FreeBSD's vi. :)

(In reply to Mateusz Piotrowski from comment #5)

Sorry, *blush* it had been a long day!

I'll get on to NetBSD

Cheers!

Comment 7 Daniel Ebdrup Jensen 2021-01-18 14:06:48 UTC

(In reply to Jamie Landeg-Jones from comment #6)
I have some apologies to make too; I think I might've come off as a bit curt, which I can only explain, but not excuse, because I was busy with another hairy diff while I was handling this, during the January 2021 Bugathon.