Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's up with all those equals signs anyway?

lars.ingebrigtsen.no

Post reply on HN
Print view View original

141–150 of 200 posts

Re: What's up with all those equals signs anyway?

#141

Post by sovande »

kstrauser wrote: post #115

For context, this is the Lars Ingebrigtsen who wrote the manual for Gnus[0], a common Emacs package for reading email and Usenet. It’s clever, funny, and wildly informative. Lars has probably forgotten more about email parsing than 99% of us here will ever have learned. The manual itself says[1]: > Often when I read the manual, I think that we should take a collection up to have Lars psycho-analysed. 0: https://www.g…

Not only the manual, but Gnus itself. I remember this guy from the university (UiO) when he started working on Gnus. He was a small celebrity among us informatics students, and we all used Emacs and Gnus, of course.

Re: What's up with all those equals signs anyway?

#142

Post by Jaxan »

fluoridation wrote: post #73
direwolf20 wrote: post #41

Earlier quoted context omitted.

SMTP is a line–based protocol, including the part that transfers the message body The server needs to parse the message headers, so it can't be an opaque blob. If the client uses IMAP, the server needs to fully parse the message. The only alternative is POP3, where the client downloads all messages as blobs and you can only read your email from one location, which made sense in the year 2000 but not now when everyone…

Hey, POP3 still makes sense. Having a local copy of your emails is useful.

Isn’t the only difference between pop and imap that pop removes the mail from the server? I only use imap, and all my email is available offline.

Re: What's up with all those equals signs anyway?

#143

Post by encom »

bityard wrote: post #118
josefx wrote: post #61

Earlier quoted context omitted.

I prefer the question about CPU pipelines that gets explained using a railroad switch as example. That one does a decent job of answering the question instead of going of on a, how to best put it, mentally deranged one page rant about regexes with the lazy throw away line at the end being the only thing that makes it qualify as an answer at all.

But--and this is crucial--the one about regexes is hilarious. It also comes from a time in Internet culture when humor was appreciated instead of aggressively downvoted.

It's because the author put effort into it. Most (online) humour is lazy, low effort, regurgitated meme spam. See: Reddit. It should be downvoted and ideally never posted at all.

This is also the reason why I consider the lack of images in IRC a feature.

Re: What's up with all those equals signs anyway?

#144

Post by encom »

fluoridation wrote: post #73
direwolf20 wrote: post #41

Earlier quoted context omitted.

SMTP is a line–based protocol, including the part that transfers the message body The server needs to parse the message headers, so it can't be an opaque blob. If the client uses IMAP, the server needs to fully parse the message. The only alternative is POP3, where the client downloads all messages as blobs and you can only read your email from one location, which made sense in the year 2000 but not now when everyone…

Hey, POP3 still makes sense. Having a local copy of your emails is useful.

Nothing stops you from locally archiving your email with IMAP.

Re: What's up with all those equals signs anyway?

#145

Post by comex »

tiagod wrote: post #138
perching_aix wrote: post #136

Earlier quoted context omitted.

It took me years to notice, but did you catch that the answer actually subtly misinterprets what the question is asking for? Guy (in my reading) appears to talk about matching an entire HTML document with regex. Indeed, that is not possible due to the grammars involved. But that is not what was being asked. What was being asked is whether the individual HTML tags can be parsed via regex. And to my understanding those…

I think even for single opening tags like asked there are impossible edge cases. For example, this is perfectly valid XHTML: />">

If you already know where the start of the opening tag is, then I think a regex is capable of finding the end of that same opening tag, even in cases like yours. In that sense, it’s possible to use a regex to parse a single tag. What’s not possible is finding opening tags within a larger fragment of HTML.

Re: What's up with all those equals signs anyway?

#146

Post by fluoridation »

Jaxan wrote: post #142
fluoridation wrote: post #73

Earlier quoted context omitted.

Hey, POP3 still makes sense. Having a local copy of your emails is useful.

Isn’t the only difference between pop and imap that pop removes the mail from the server? I only use imap, and all my email is available offline.

No, the difference is that IMAP doesn't store anything other than headers on the client (at least, not until the user tries to read a message), while POP3 eagerly downloads messages whenever they're available. A POP3 client can be configured with various remote retention policies, or even to never delete downloaded messages.

I don't have an IMAP account available to check, but AFAIK, you should not have locally the content of any message you've never read before. The whole point of IMAP is that it doesn't download messages, but instead acts like a window into the server.

Re: What's up with all those equals signs anyway?

#147

Post by floren »

kstrauser wrote: post #124
floren wrote: post #90

Earlier quoted context omitted.

Remember that back in the mists of time, computers used typewriter-esque machines for user interaction and text output. You had to send a CR followed by an LF to go to the next line on the physical device. Storing both characters in the file meant the OS didn't need to insert any additional characters when printing. Having two separate characters let you do tricks like overstriking (just send CR, no LF)

True, but I don’t think there was a common reason to ever send a linefeed without going back to the beginning. Were people printing lots of vertical pipe characters at column 70 or something? It would’ve been far less messy to make printers process linefeed like \n acts today, and omit the redundant CR. Then you could still use CR for those overstrike purposes but have a 1-byte universal newline character, which we a…

As I understand it (this may be apocryphal but I've seen it in multiple places) the print head on simple-minded output devices didn't move fast enough to get all the way back over to the left before it started to output the next character. Making LF a separate character to be issued after CR meant that the line feed would happen while the carriage was returning, and then it's ready to print the next character. This lets you process incoming characters at a consistent rate; otherwise you'd need some way to buffer the characters that arrived while the CR was happening.

Now, if you want to use CR by itself for fancy overstriking etc. you'd need to put something else into the character stream, like a space followed by a backspace, just to kill time.

Re: What's up with all those equals signs anyway?

#148

Post by saila »

kstrauser wrote: post #124
floren wrote: post #90

Earlier quoted context omitted.

Remember that back in the mists of time, computers used typewriter-esque machines for user interaction and text output. You had to send a CR followed by an LF to go to the next line on the physical device. Storing both characters in the file meant the OS didn't need to insert any additional characters when printing. Having two separate characters let you do tricks like overstriking (just send CR, no LF)

True, but I don’t think there was a common reason to ever send a linefeed without going back to the beginning. Were people printing lots of vertical pipe characters at column 70 or something? It would’ve been far less messy to make printers process linefeed like \n acts today, and omit the redundant CR. Then you could still use CR for those overstrike purposes but have a 1-byte universal newline character, which we a…

> now that Windows mostly stopped resisting the inevitable

I've been trying to get Visual Studio to stop mucking with line endings and encodings for years. I've searched and set all the relevant settings I could find, including using a .editorconfig file, but it refuses to be consistent. Someone please tell me I'm wrong and there's a way to force LF and UTF-8 no-BOM for all files all the time. I can't believe how much time I waste on this, mainly so diffs are clean.

Re: What's up with all those equals signs anyway?

#149

Post by liveoneggs »

kstrauser wrote: post #119
liveoneggs wrote: post #48

Earlier quoted context omitted.

This is incorrect

Are you certain? Not OP, but a huge chunk of early RFCs was about how to let giant IBM systems talk to everyone else, specifying everything from character sets (nearly universally “7-bit ASCII”) to end of line/message characters. Otherwise, IBM would’ve tried to make EBCDIC the default for everything. For instance, consider FTP’s text mode, which was primarily a way to accidentally corrupt your download when you forg…

I had a pre-'@' email address and it was able to communicate all over the world.

Re: What's up with all those equals signs anyway?

#150

Post by thedanbob »

stevekemp wrote: post #101
thedanbob wrote: post #46

I wrote my own email archiving software. The hardest part was dealing with all the weird edge cases in my 20+ year collection of .eml files. For being so simple conceptually, email is surprisingly complicated.

I wrote a console-based mail client, which was 25% C++ and 75% Lua for defining the UI and the processing. It never got too popular, but I had users for a few years and I can honestly say MIME was the bane of my life for most of those years.

Indeed. A big chunk of my email parser deals with missing or incorrect content headers. Most of the rest attempts to sensibly interpret the infinite combinations of parts found in multipart (and single-part!) emails.
Post reply on HN