With these declarations your fragment is valid in both JavaScript and TypeScript:
class b {}
class c {}
const d = JSON.parse
const a = Promise.prototype.then.bind(Promise.resolve(1))
console.log(a<b,c>(d))
// TS output: Promise { <state>: "pending" }
// JS output: false false
Here's a bug I discovered in MS Word in 2004, which has survived the past 18 years of updates and is even present in the web version: https://1drv.ms/w/s!AgYiBqBjIZZpfkcvO9jnOel9T2o?e=tFA4wp If you join the two lines using a backspace at the start of the second line, the second line turns into gibberish.
The first line ("paragraph") has its style set to "BodyText3", but also has formatting on that section of text itself, overriding it. Once the lines are joined into one paragraph, the paragraph formatting appears in the second part because that text does not have a style to override it.
1. Create a Word document (most likely using the Blank document template, Normal.dotm)
2. Type text of first line; press Enter; type text of second line (technically Word calls these 'paragraphs'--Shift+Enter inserts a newline within the same paragraph)
3. Place cursor on first paragraph
4. Click a Paragraph Style from the Styles ribbon section to apply it (e.g., the second one, No Spacing)
5. Right click the style; choose Modify...
6. Change the formatting (e.g., the font to Wingdings)
7. Confirm the dialog
8. Select the entire first paragraph (doesn't matter whether you include the end-of-paragraph/newline)
9. Use manual formatting to override your changes to the style so the text matches the default style, Normal (e.g. use the listbox in the ribbon to change the font back to Calibri)
Done; if you now delete the newline, the second paragraph merges with the first and takes on its style, as parent points out.
Styles are the "proper" way to format Word documents (interesting to see what fraction of users actually use them). They're like a mix of HTML tags and styles: each paragraph (div) must have exactly one Paragraph Style, and each span of text can only have one Character Style. "Manual" formatting has highest precedence, followed by Character Style, followed by Paragraph Style. The benefits are the same as in HTML: semantic correctness and easy restyling of the entire document (e.g., by applying Themes from the Design tab). This sequence of steps is a fairly good demonstration of how they're used.
Just to clarify, this is not how I created the original document in 2004 :-) There were certainly no paragraph styles involved, and the edit actions had to include an undo, or it wouldn't happen. There was also no style inspector yet.
This is why I prefer just writing html/markdown and letting pandoc generate docx. Fiddling with the Word GUI when I know what I want and how to type it is just frustrating.
Just noticed that with this method, the backspace joins the two lines, whereas in the original it reveals the markup, but the newline between the lines remains.
Cool! This was pre-XML Word, and since introducing it became impossible at some point, I always just figured it had been a bug. Probably the bug was only in the creation, as I do remember the sequence of edit actions made no sense. I think it even had to include an undo.
This kind of thing can be easily debugged using the style inspector, "reveal formatting" which shows the formatting applied to the selected text and whether it's from paragraph formatting or direct text formatting.
How did you create the document? When I hit backspace it does "turn into gibberish", but because it seems to inherit the type choices from the ether between the two lines to put it into Wingdings in red with italic and strikethrough. Did you create that type setting?
I ran into it while editing an interview text that had colors for people's names. It was surprisingly easy to reproduce, but creating the buggy documents got fixed at some point. The font and styles were altered slightly for dramatic effect.
Aw man, the way MS Word leaves bold/italic markers lying around [the subject of that comic] and greedily applies formatting to stuff you purposefully didn't select, drives me bonkers ... mind you I caught LibreOffice emulating this behaviour the other day (after an update), I hope it can be retamed ...
Unfortunately, I lost the recipe (18 years is a long time), but I vaguely recall that the first line had markup that got canceled out, and that trying to delete the newline somehow deleted the end tag for that markup instead of the newline. It also happens when pressing delete at the end of the first line.
For me that didn't work. The red badge on System Preferences disappeared, but it came back the next day. Doing a `defaults delete com.apple.preferences.softwareupdate LatestMajorOSSeenByUserBundleIdentifier` got rid of it permanently.
While it could be my eyes playing tricks on me, the not stone circle one that is further away looks like it can be seen in the sheep field and the field beyond. Though it could also be my eyes playing tricks and finding patterns that I expect to be there.
Inspired by StackOverflow questions on React's new lifecycle methods, I created a light-weight package that visualizes which lifecycle methods are called and in what order. It can be installed with `npm -i react-lifecycle-visualizer`, but was mainly designed to run on StackBlitz:
