Turning a page of text into a list you can use

The job appears constantly and has no name. You have a thread, a forwarded chain, an exported page or a block of notes, and what you need out of it is a list: the addresses, the links, the values, one per line, ready to paste somewhere that expects a list.

Doing it by hand is fine for six items and unbearable for sixty. Doing it with tools works well, provided the three steps happen in the right order.

Extract first

Take the values out before doing anything else to the text.

The reason is that every later step works on lines, and the values you want are not lines. They are embedded in sentences, wrapped in punctuation, and often several to a line. Removing duplicates from the original text compares whole lines, so two sentences carrying the same address are two different lines and both survive. Sorting the original sorts sentences. Only after extraction is each value on a line of its own, where the line-based tools do what their names suggest.

Extraction has one detail worth knowing about, and it is the one that produces broken output most often: punctuation at the end. A full stop is a legal character inside a URL, so any pattern that reads until whitespace will happily include the full stop that ended the sentence. The link then looks correct in a list and fails when clicked. The same applies to a closing bracket, a comma in a run-on list, and a quotation mark. Trailing punctuation has to be trimmed off after matching, not before.

For addresses, the matching is a shape test rather than a validity test: a local part, an at sign, and a domain containing at least one dot. Nothing running on your own device can tell you whether a mailbox exists, and a tool that claims to is guessing.

Deduplicate second, and keep the first spelling

Almost every list of this kind contains repeats, because the same person appears on several messages in a thread and the same link is cited twice in a document.

The rule that matters is which copy survives. Matching should ignore case, because a host name and a mailbox are not case-sensitive. What is returned should still be the first spelling that appeared, not the last one. This sounds like a detail until a name has a capital letter in it that somebody typed on purpose, and the list hands back the lowercase version because it happened to appear later.

There is a common implementation that gets this backwards without anybody noticing: building a lookup keyed on the lowercased value, which quietly overwrites each earlier entry with the later one. The output has the right number of rows, so nothing looks wrong.

Format last

Only once the list is the values you want, in the order you want, is it worth deciding how it should look.

Numbering is the usual next step, and the part worth getting right is alignment. Numbers grow a digit at a time, so the tenth line of an unpadded list starts one column to the right of the ninth. In a list whose whole purpose is being scanned down a column, that is the difference between useful and irritating. Padding fixes it, and the padding width has to be calculated from the largest number that will actually be printed, which is not the same as the line count whenever the numbering starts somewhere other than one.

A prefix and suffix on every line covers most of the rest: quoting a block for an email, adding a bullet, or wrapping each line in the syntax the destination expects. It is also the fastest way to turn a plain list into something structured, because a list of values with a comma appended and a quotation mark on either side is most of the way to being a query, and neither step needs anything cleverer than applying the same text to every line.

Whether to number at all depends on where the list is going. A destination that will import the list wants the values and nothing else, so numbering it first creates work for whoever has to strip the numbers back off. Numbering is for lists that will be read by a person, referred to by position, or discussed in a message where someone needs to say which item they mean.

Wrapping comes last, when the destination has a width limit. A commit message body, a plain-text email, or anything read in a terminal is conventionally hard wrapped at 72 columns. The decision that changes the result is whether to reflow the paragraphs, which rebuilds the line breaks from scratch, or to wrap each line where it already sits, which preserves a layout that was deliberate.

Where the work happens

For most text this is a matter of convenience. For a list of contact details it is not.

An extractor running on somebody else’s server receives every address in the list, and that is a meaningful thing to hand over in exchange for saving two minutes. A tool that runs in the browser can be verified rather than trusted: open the network panel, run the extraction, and watch for requests that never come.