💾 Archived View for thrig.me › blog › 2023 › 06 › 18 › formfeed-rabbithole.gmi captured on 2023-09-08 at 16:13:08. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-07-10)

➡️ Next capture (2023-11-14)

-=-=-=-=-=-=-

A Formfeed Rabbithole

but rabbits are all cute n' fluffy and this ain't

Paragraph support in vi(1) is weird, like much else. For one, formfeed characters in the first column delimit paragraphs. This was documented but not implemented historically, and a version of vi that ended up in OpenBSD went with the documentation over the implementation.

        /*                                                              \
         * !!!                                                          \
         * Historic documentation (USD:15-11, 4.2) said that formfeed   \
         * characters (^L) in the first column delimited paragraphs.    \
         * The historic vi code mentions formfeed characters, but never \
         * implements them.  It seems reasonable, do it.                \
         */                                                             \
        if (p[0] == '\014') {                                           \
                if (!--cnt)                                             \
                        goto found;                                     \
                continue;                                               \
        }                                                               \

How does your vi-like behave? Try a file with first column formfeeds in it, and then have at the } key!

    $ perl -E 'say "\014is this a paragraph?" for 1..10' > x.txt
    $ vim -u NONE x.txt
    ...

x.txt

Or use control+v control+l to get a formfeed, assuming control+v does the usual "literal next" thing. ASCII "ff" maps to "L" just as "bel" maps to "G" or "etx" maps to "C". Follow the columns in ascii(7), though not all renditions make the "^L" to "ff" relationship clear.

These days the use of literal ^L in files is probably rare; there are often not printers to eject a page from, or if there are, that's being done by a software program (PostScript?) sent to and executed by a program execution environment that may or may not actually be a physical printer, and the relevant call probably does not involve a literal ^L.

But, however,

Please use formfeed characters (control-L) to divide the program into pages at logical places (but not within a function). It does not matter just how long the pages are, since they do not have to fit on a printed page. The formfeeds should appear alone on lines by themselves.

https://www.gnu.org/prep/standards/standards.html#index-control_002dL

and you might see similar ancient edicts from the elder days when code was often sent to real printers with real paper; nytpu on the #gemini IRC channel linked some ADA pragmas to that effect—"backwards compat with 1983 version". Or maybe that programming language you use does make active use of ^L?

Omake Interlude

https://www.youtube.com/watch?v=Iir7uYIzvcc

There's probably a more suitable clip where they do the whole "L" thing, but w3m and duckduckgo don't make the best interface for youtube, and more likely my search skills have rusted through years of misuse.

USENET Oddity

Formfeed (US-ASCII 12) (which is sometimes referred to as the "spoiler character") signifies a point at which the reading agent SHOULD pause and await reader interaction before displaying further text.

https://datatracker.ietf.org/doc/html/draft-ietf-usefor-useage-01

--- .-. -- .- -.-- -... . -.-- --- ..- -.-. --- ..- .-.. -.. .--- ..- ...
- . -. -.-. --- -.. . - .... . ... .--. --- .. .-.. . .-. ... - --- -- .-
-.- . - .... . -- .... .- .-. -.. . .-. - --- .-. . .- -..

bs pbhefr gurer vf ab fgnaqneq sbe ubj gb vaqvpngr be rapbqr fcbvyref

bphflog links

bphflog index

next: Communicative Culture