What's up with all those equals signs anyway?

Post by vbezhenar » Tue, Feb 03, 2026, 4:45 PM UTC

throwaway_61235 wrote: post #93

bayesnet wrote: post #74

Earlier quoted context omitted.

I know this is grumpy but this I’ve never liked this answer. It is a perfect encapsulation of the elitism in the SO community—if you’re new, your questions are closed and your answers are edited and downvoted. Meanwhile this is tolerated only because it’s posted by a member with high rep and username recognition.

As someone who used to write custom crawlers 20 years ago, I can confirm that regular expressions worked great. All my crawlers were custom designed for a page and the sites were mostly generated by some CMS and had consistent HTML. I don't remember having to do much bug fixes that were related to regular expression issues. I don't suggest writing generic HTML parsers that works with any site, but for custom crawlers…

Post by ErigmolCt » Tue, Feb 03, 2026, 4:48 PM UTC

beejiu wrote: post #12

> So what’s happened here? Well, whoever collected these emails first converted from CRLF (i.e., “Windows” line ending coding) to “NL” (i.e., “Unix” line ending coding). This is pretty normal if you want to deal with email. But you then have one byte fewer: I think there is a second possible conclusion, which is that the transformation happened historically. Everyone assumes these emails are an exact dump from Gmail,…

Post by bjourne » Tue, Feb 03, 2026, 5:01 PM UTC

SoftTalker wrote: post #83

layer8 wrote: post #33

Earlier quoted context omitted.

Mails are (or used to be) processed line-by-line, typically using fixed-length buffers. This avoids dynamic memory allocation and having to write a streaming parser. RFC 821 finally limited the line length to at most 1000 bytes. Given a mechanism for soft line breaks, breaking already at below 80 characters would increase compatibility with older mail software and be more convenient when listing the raw email in a te…

In early days, many/most people also read their email on terminals (or printers) with 80-column lines, so breaking lines at 72-ish was considered good email etiquette (to allow for later quoting prefix ">" without exceeding 80 characters).

Post by kstrauser » Tue, Feb 03, 2026, 5:11 PM UTC

School-Cotton wrote: post #121

philistine wrote: post #114

Earlier quoted context omitted.

The whole argument hinges on one word in your post: arbitrary. I parse my own HTML I produce directly in a context where I fully control the output. It works fine, but parsing other people’s HTML is a lesson in humility. I’ve also done that, but I did it as a one time thing. I parsed a specific point in time, refusing to change that at any point.

It also hinges on another word: parsing . There are things other than parsing that you might want to do. For example, if you want to count the number of ` ` tags in an HTML document, that doesn't require parsing it, and can indeed be done with regex.

Post by badc0ffee » Tue, Feb 03, 2026, 5:29 PM UTC

josefx wrote: post #35

tiborsaas wrote: post #20

> We see that that’s a quite a long line. Mail servers don’t like that Why do mail server care about how long a line is? Why don't they just let the client reading the mail worry about wrapping the lines?

RFC822 explicitly says it is for readability on systems with simple display software. Given that the protocol is from 1982 and systems back then had between 4 and 16kb RAM in total it might have made sense to give the lower end thin client systems of the day something preprocessed.