But now you’ve basically doubled or tripled the length of the whole sentence.

The primary usage I see of this is to replace some second or third person pronoun with the actual name of the person, which is much simpler than appending a short biography of the person and trivially easy to verify.

I've had this hit me directly with a serious sting. A company in which I was employed became subject of a state investigation, and the local newspaper wrote a story about the problem including a quote from a state investigator something like this: "They definitely have a problem (with XYZ)." XYZ was done in my department. The state investigator had made no mention of XYZ. The reporter had simply clarified the quote erroneously; XYZ had nothing to do with the problem. The state investigator would not say that he was mis-quoted, because the parenthetical material is not part of the quote, and the paper refused to correct the story for the same reason. But to any reader who does not know this obscure exception to the rule that what's in quotes is what they said, it meant I was the smartest guy in the room when and where things went bad.

That is already a thing. Simply put it in brackets and insert it into the quote.

Overwriting the quote makes the expression unclear, which does require readers seek original expressions or otherwise speculate.

Yeah, that is a better solution. It's a simple, clear rule: never alter the original quote, but you can insert bracketed words to make it clearer.

And it's parsable.

I think back to the one period after sentence move we've seen play out for a while now.

When two spaces are used, end of sentence is a parsable thing, easily differentiated from other uses, such as abbreviations.

Without them, assistive technology gets capitalization wrong all the time.

This kind of thing makes problem spaces way larger and more complicated than they need to be.

I don’t think that “Heather spoke to [Sam] to the conference” vs “Heather spoke to her [Sam] at the conference” provides all that much meaningful clarity.

It comes down to what brackets mean, and the reader understanding what is quoted.

In your second example, the quote is clear, verbatim as quotes are intended to be.

In the first example, what has been clear, precise syntax is not a matter of ambiguity.

In your example, it's somewhat clear, but inference is required to understand what was said.

The example given in the article actually does bring genuine ambiguity to what would otherwise be a precise, easily understood expression:

They may groan when Corky, denied the massive funding he’s asked for, tells the town council he’s going to “go home and bite [his] pillow,” the way I do now.

Did Corky say, "go home and bite pillow" broken English style?

Or, did Corky say something else?

Until this construct, we would know because "[his]" would be added into quote context. It would not be a modifier, essentially hiding or changing the quote.

Notably, what Corky did say isn't actually present in the expression, meaning we have to now trust the author interpreting things for us.

Breaking the line with how brackets are used is going to lead to significantly increased ambiguity, and that's going to happen because it will be employed to spin or otherwise manage far less trivial examples, and sorting it out will all take considerably more effort than it all would otherwise be, given brackets are never normally used to modify a quote itself.

And all for a bit of flow? I don't buy it. The whole affair diminishes how robust brackets are and introduced ambiguity into expression that does not add any real value.

Whenever I see “go home and bite [his] pillow”, I’ve always assumed the person spoke quickly and/or skipped a word, which the editor thought should be added. It never occurred to me before now that the editor actually replaced a word!

Right? Prior to this discussion, my thought was similar, typo, or something benign.

Replacing a word breaks the syntax and brings ambiguity to some use cases involving brackets and quotes that did not have it before.

As I mentioned elsewhere, a similar thing happened with the one space vs. two spaces to end a sentence.

In that last sentence, there is now ambiguity after "vs. " where there was not before. Right now I am on desktop, but if I were to input that sentence on my Android, "two" would be auto-capitalized, even though I am mid sentence.

I see this headed a similar direction.

Cases where the actual verbatim expression may be made more clear with something added in brackets will now overlap with cases where someone wants to replace a word in a quote...

Sigh :(

Me too, which lowers my opinion of the speaker!

Yeah, there is a cost to being precise. We can think of other ways to make it shorter, but we should respect the integrity of what is in quotes. Another option:

Spitballing:

"It is not worth doing," she said, [it=foobar].

We do this all the time in programming languages. Without introducing too much syntax, this is doable.

I'd say we only do something like that in programming if there's a benefit to using other values for `it` in other contexts, and if we'd like to refer to a template `"It is not worth doing" by name.

If you're just going to use it once, or if all usages have `[it=foobar]`, I don't think you'd do it.

I could imagine doing something like what you mention if I had moved code from another context, and I wanted to have a commit that shows plainly that it was moved verbatim. But then I'd make subsequent commit where I do the necessary substitution.

> If you're just going to use it once, or if all usages have `[it=foobar]`, I don't think you'd do it.

If you never pulled out code into its own separate function just in order to name some lines of code, you should give it a try. You can avoid a lot of comments and/or confusion by just structuring your code in a way that allows you to name lines of code as concepts and abstractions. No need for it to happen more than once for you to do so.

I agree with using descriptive identifier names and using function names to express intent of lines of code.

But I don't understand your point in bringing it up here.

> "It is not worth doing," she said, [it=foobar]

  baz(it) = "$it is not worth doing"
  baz("foobar")

`it` is neither a descriptive identifier, nor did I see a suggestion for what the function `baz` could be called to make it descriptive.

It wasn't referring to the specific identifier "it" here, but more in general as I took your point to mainly be about "if there's a benefit to using other values for X in other contexts", meaning that putting things into variables only serves the functionality of reuse in different contexts, not also to name passages of code.

> Otherwise we are on the slippery slope to, "oh, what they really meant to say is [phrase phrase phrase]".

Slippery slope arguments tend to ignore that if a result is actually unconscionable then regardless of the apparent slope we'll still actually stop somewhere. Additionally, they often could be applied just as well in reverse, indicating some sort of flaw in the reasoning: "We can no longer even substitute proper nouns into our quotations: how long is it till we can't use 'sic', and from there it's a slippery slope to not being able to fully quote people at all for fear of misrepresentation."

In this case though, what would be so bad about the use of brackets changing over time? Changes don't happen in isolation, so presumably people would adapt, recognizing that the author's interpretation probably plays a key role (much as it already does because of the author choosing the context to omit and the new home for an unsuspecting snippet).

Prior to this use, brackets were clear. Subtract them and what remains is quoted verbatim.

Using them this way breaks that and renders both past and future text less clear, and does not add real value otherwise.

Real ambiguity becomes codified into otherwise precise expression.

> Slippery slope arguments tend to ignore that if a result is actually unconscionable then regardless of the apparent slope we'll still actually stop somewhere.

I disagree. The point of the slippery slope argument is that no one knows where we'll stop, or if at all. We should be cautious in ever starting sliding.

> Otherwise we are on the slippery slope to, "oh, what they really meant to say is [phrase phrase phrase]".

As Einstein put it, "[Grammar nazis] are [really the worst]."

Although it happens often in natural communication, I find there is more chance for confusion, especially by a non-native reader, when a pronoun (or any proform) appears before its antecedent.

So resolving the pronoun with square brackets can be less confusing, to say nothing of the benefits of brevity.

https://en.wikipedia.org/wiki/Cataphora

> I find there is more chance for confusion, especially by a non-native reader, when a pronoun (or any proform) appears before its antecedent.

It depends on the native language. Spanish is flexible to a fault, so "a huge orange cat", "an orange huge cat", and even "a cat orange huge" are easy to understand... but correctly translating "un enorme gato naranja" to English is the hard part.

You're talking about ordering among adjectives, which is unrelated to pronouns.

> The Elements of Eloquence: How to Turn the Perfect English Phrase by Mark Forsyth. "Adjectives absolutely have to be in this order: opinion-size-age-shape-colour-origin-material-purpose Noun. So you can have a lovely little old rectangular green French silver whittling knife. But if you mess with that order in the slightest you’ll sound like a maniac."

You're right, my confusion even makes your point stronger.