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

151–160 of 200 posts

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

#151

Post by flomo »

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,…

When they process these emails, it's fairly common to import everything into a MS Outlook PST file (using whatever buggy tool). That's probably why these look like Outlook printouts even though its Yahoo mail or etc.

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

#152

Post by mmooss »

fluoridation wrote: post #146
Jaxan wrote: post #142

Earlier quoted context omitted.

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 c…

Also, IMAP syncs the other way. If you locally tag a message locally or move it to another folder, it also happens on the server.

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

#153

Post by mmooss »

encom wrote: post #144
fluoridation wrote: post #73

Earlier quoted context omitted.

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

Nothing stops you from locally archiving your email with IMAP.

How do you do that, by default? Can you tell an IMAP client to work like POP3 and download everything?

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

#154

Post by kstrauser »

floren wrote: post #147
kstrauser wrote: post #124

Earlier quoted context omitted.

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 l…

I don't think that's right. Not saying that to argue, more to discuss this because it's fun to think about.

In any event, wouldn't you have to either buffer or use flow-control to pause receiving while a CR was being processed? You wouldn't want to start printing the next line's characters in reverse while the carriage was going back to the beginning.

My suspicion is there was a committee that was more bent on purity than practicality that day, and they were opposed to the idea of having CR for "go to column 0" and newline for "go to column 0 and also advance the paper", even though it seems extremely unlikely you'd ever want "advance the paper without going to column 0" (which you could still emulate it with newline + tab or newline + 43 spaces for those exceptional cases).

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

#155

Post by somat »

perching_aix wrote: post #136
lvncelot wrote: post #60

Earlier quoted context omitted.

> It's the same class of bug as manually parsing HTML with regex, it works right up until it doesn't I'm sure you already know this one, but for anyone else reading this I can share my favourite StackOverflow answer of all time: https://stackoverflow.com/a/1732454

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…

The thing is, even when parsing html "correctly" (whatever that is) regexes will still be used. Sure, There will be a bunch of additional structures and mechanisms involved, but you will be identifying tokens via a bunch of regexes.

So yes, while it is an inspired comidic genius of a rant, and sort of informative in that it opens your eyes to the limitations of regexes, it sort of brushes under the rug all the places that those poor maligned regular expressions will be used when parsing html.

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

#156

Post by rireads »

fredley wrote: post #19
lordnacho wrote: post #2

I love how HN always floats up the answers to questions that were in my mind, without occupying my mind. I, too, was reading about the new Epstein files, wondering what text artifact was causing things to look like that.

Me too. I first assumced it was an OCR error, then remembered they were emails and wouldn't need to go through OCR. Then I thought that the US Government is exactly the kind of place to print out millions of emails only to scan them back in again. I'm glad to know the real reason!

I just want to add that I would expect the exact same thing from the German government. Glad to see we're not all that different

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

#157

Post by kstrauser »

saila wrote: post #148
kstrauser wrote: post #124

Earlier quoted context omitted.

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 muc…

Ugh, I didn't realize it was still that bad.

How far can you get with setting core.autocrlf on your machine? See https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura...

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

#158

Post by kstrauser »

liveoneggs wrote: post #149
kstrauser wrote: post #119

Earlier quoted context omitted.

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.

My first reading was that you were disagreeing with the bits about email worrying about compatibility, and that part seemed reasonably true to me.

As to the other bits, I think even in the uucp era, email was mostly internal, by volume of mail sent, even though you could clearly talk to remote sites if everything was set up correctly. It was capable of being a worldwide communication system. I bet the local admins responsible for monitoring the telephone bill preferred to keep that in check, though.

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

#159

Post by LAC-Tech »

noduerme wrote: post #28

Great. Can't wait for equal signs to be the next (((whatever this is))). Maybe it's a secret code. j/k On a side note: There are actually products marketed as kosher bacon (it's usually beef or turkey). And secular Jews frequently make jokes like this about our kosher bros who aren't allowed to eat the real stuff for some dumb reason like it has too many toes.

Great. Can't wait for equal signs to be the next (((whatever this is))). Maybe it's a secret code. j/k

Yeah clearly you guys are the biggest victims in all this... get in there and make it about you!

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

#160

Post by kstrauser »

comex wrote: post #145
tiagod wrote: post #138

Earlier quoted context omitted.

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.

For any given regex, an opponent can craft a string which is valid HTML but that the regex cannot parse. There are a million edge cases like:

   this! -—> but do count  this -->
and

   this --> but do count  this —->
Now your regex has to include balanced comment markers. Solve that

You need a context-free grammar to correctly parse HTML with its quoting rules, and escaping, and embedded scripts and CDATA, etc. etc. etc. I don't think any common regex libraries are as powerful as CFGs.

Basically, you can get pretty far with regexes, but it's provably (like in a rigorous compsci kinda way) impossible to correctly parse all valid HTML with only regular expressions.

Post reply on HN