[RFC] Syntax for minor variations in tidbits

[dgw]

This is a working draft, and may be revised based on feedback in the comments. Where appropriate, I will note if a change has been made.

Use case

Avoiding the creation of multiple, nearly identical factoids while still providing more variety than a single factoid under the current system.

Example

Replace this list of tidbits for the same trigger:

I will not $verb the $noun!
I will not $adverb $verb the $noun!
I will not $verb the $nouns!
I will not $adverb $verb the $nouns!
I will not $verb a $noun!
I will not $adverb $verb a $noun!
I will not $verb $nouns!
I will not $adverb $verb $nouns!
I will not $verb $who's $noun!
I will not $adverb $verb $who's $noun!
I will not $verb $who's $nouns!
I will not $adverb $verb $who's $nouns!

with this single factoid:

I will not {$adverb|} $verb {the|a|$who's} $noun{s|}!

Note that the list of factoids would double in size from 12 entries to 24 if, for example, it was also desired for Bucket to possibly say "I will $verb the $noun!" etc. With the proposed syntax, that could be folded into the example with =~ s/not/{not|}/.

Why new syntax

This behavior can sort of be implemented by creating variables. The drawbacks are:

• Normal users cannot create variables.
• Variable values cannot be empty.
• Variable values cannot contain nested variables.
• Even if an op makes a new unprotected var, creating a variable for use in just one or two factoids is kind of like driving brads with a sledge hammer…or a jackhammer.
• Variables' shortcomings often still result in a need to create multiple factoids with slight variations.

New syntax would eliminate these drawbacks, respectively, as follows:

• Normal users can embed the new syntax in factoids at will.
• Two pipes (||) or an empty alternative at the beginning or end of the list ({| or |}) represent a variation where that element does not appear (with multiple consecutive spaces collapsed before output).
• Alternatives can contain variables, or partially modify a variable reference.
• No variables are needed.
• One factoid with the variation syntax obviates the need to create multiple variant factoids manually.

One of the obvious arguments against this is that it would make the syntax for teaching Bucket even more arcane. In an effort to use something reasonably intuitive, I've proposed curly braces and pipes in this example. Pipes are intuitive regex "or" syntax, and curly braces appear in string interpolation when using languages like PHP—whose $variables Bucket's vars resemble in text. But the syntax is up for discussion just as much as whether to implement the idea.

Implementation considerations

• Expand variation syntax before running through variables (allows varying the variables used in a factoid as well—see $noun{s|} at end of example).
• Is it necessary to limit the number of options per variation block ({list|of|options}) and/or the number of blocks allowed per factoid (as variables are)?

Status

• 2017-04-24:
  • Plugin written and put into production on my instance for testing.
  • Plugin uses a new signal (not yet added to master) to resolve the variation syntax before variables are expanded.
  • Variations can themselves contain | if it is escaped with \: {variations|can|contain\|pipes|by escaping} yields the candidates ["variations", "can", "contain|pipes", "by escaping"].
  • The plugin at present implements no limits on variation block length or number of variation blocks in a tidbit.
• 2017-08-31:
  • Plugin has proved itself in production on my instance, save for a quirk in Perl's split routine that ignored empty variations at the tail of the block (since fixed).
  • The new signal (pre_expand) was merged to master back in May.

[zigdon]

That looks like a great plugin, but I wouldn't enable it for the main instance. It does complicate the syntax, and would underweight these folded tidbits in comparison to others.

That said, it does degrade gracefully, and I don't think it would break many existing factoids.

[dgw]

I see your point about underweighting the new folded tidbits, but I'm not going to worry about it too much because the intended use case is to replace factoids that currently have several slight variations with just one folded factoid.

With regard to breaking existing factoids, it might be better to use {{double braces}}, like MediaWiki transclusions or Liquid output tags. Is there a dump of the main instance's database (from any time in the past year, probably) that I could query for potential conflicts with different syntax ideas? My instance is nearing 6k factoids, but that's nothing compared to the main one.

[zigdon]

out of ~140k factoids, about 5 will be affected.

Still think it should be a plugin though, not on by default -- both for avoiding unneeded complexity in the main code, and also to make it easy to enable/disable.

[dgw]

3,750 lines of code and we're worried about the added complexity of maybe a dozen more, lol.

No matter. I wrote this plugin tonight. Had to add a new plugin signal in &expand because I couldn't wrap my head around how it might be done using the existing db_success signal. If there's a way, I'm happy to rewrite my plugin and drop the new signal. Otherwise, expect a PR for the new signal soon, but I'll want to battle-test the plugin for a good while (think weeks) before submitting it for inclusion.

[dgw]

I've a couple questions regarding this when you have a moment, @zigdon.

1. Do you want this plugin included with Bucket?
2. If so, would you still want it to be included if I implemented support for nested variations? Core doesn't allow nested variables, so I can imagine that could be a deal-breaker. (It's also convoluted, and while I've made some progress on theory tonight I'm not entirely sure I'll actually finish the feature.)

Whatever the answer to question 2, if the answer to question 1 is "Yes", I'm happy with the plugin as-is and ready to open a PR for review.