I love the concept of lexical differential highlighting [0] (discussed here [1]). It makes reading math so much easier, especially in dense code. However I don't know of any editor that implements a feature like this.
If you paste the following code into the example block in [0] you can see how useful this can be:
while (b - a).abs() > EPSILON {
let c = a + (a - b) * f_a / (f_b - f_a);
let f_c = J(c);
if f_c * f_b == 0.0 {
a = b;
f_a = f_b;
} else {
f_a /= 2.0;
}
b = c;
f_b = f_c;
}
I ran into this issue recently [0]. Apparently the integrated VSCode terminal sets its own (very high) cap by default, but other shells don't, so all of my testing in the VSCode shell "hid" the bug that other shells exposed.
Semi-related, one of the `imessage-exporter` contributors provided a great write-up on reverse engineering the handwritten and digital touch message protobufs [0]. The reconstructed proto files are [1] [2].
The plist is probably a binary plist (header bytes `bplist00`) generated by NSKeyedArchiver, and then the specific data you need is encoded inside. Edited iMessages are stored in the exact same way. Luckily the plist itself is not that complex–but typedstream is pesky to work with.
The plist is no issue, but it's the values therein where you run into typedstreams. For every setting for the Script Editor's formatting, is a separate dictionary, with an NSColor and NSFont key set to a data type value. The data is a base64 encoded `streamtyped` file. Passing it through base64 decode and running `file` on the output gives back `NeXT/Apple typedstream data, little endian, version 4, system 1000`, just as in the OP.
The only reason I want to do this is because I wipe a Mac nearly weekly, and need it setup more or less the same way again. I could probably just drop the .plist in that directory and bobs your uncle, but I also would change the fonts Script Editor is using to a third-party font not installed, so I don't want to have to worry about weird order of operation BS, and also find a way to set it to any arbitrary font, as I often change out the "fixed width" font I use in all the editors for that week (I have favorites, not just a favorite, gotta keep it fresh, ya know).
I figured that since Script Editor, and the AppleScript components of macOS are so old and creaky, forgotten leftovers in the Yellow Box that no one bothered to fix. I had no idea typedstreams were still being used in modern Apple software.
iMessage uses a very strange amalgamation of typedstream (message content), keyed archives (app messages, sticker data), and protobufs (Digital Touch, handwriting) for different features. I wonder what motivated all of those design decisions.
This is stuff is such a PIA to parse. I assume it's just different teams doing different features over the years, and being alternately repulsed/seduced by each format. Probably features are implemented as libraries so there isn't a master oversight - they aren't trying to make iMessage's internal formats follow a consistent plan, just let all the libs coexist...
Maybe they should be repulsed, considering all of the journalists that are getting persecuted and/or murdered because they are getting pwned through iMessage serialization bugs :)
Apple provides Messages for Business [0], but if you have a machine that can read the iMessages as they come in, you could use the library [1] that powers `imessage-exporter` as a bridge.
I see how that helps with the usual case of inserting a value under the original key if it wasn't there, but I don't see how it helps in this case of checking a different key entirely if it wasn't there.
If you want something a bit more robust and cross-platform, including support for the undocumented TypedStream-stored text data, you can use my open source software: https://github.com/ReagentX/imessage-exporter
https://github.com/ReagentX/imessage-exporter