Add bowties and deprecate join

[T0mstone]

This is a necessary preliminary step to unblock #26, see also #26 (comment).

I went with slightly different names from what's in the Proposals Document draft since .l and .r already have a use for the big operator, so using them entirely for filling felt wrong. I think the way they're called here is a better alternative.

The big ones don't have filled variants afaik, so I don't think defining them with a .stroked modifier as well makes much sense. Thus, it's now a trichotomy for this symbol: stroked, filled, or big.

As for the deprecation: I'm thinking of the process we discussed some time ago for stuff like this: Deprecate the original and add the new name in one typst version, then undeprecate and change the original name to the new symbol in the next typst version.

[MDLC01]

Ugh this is unfortunate. There is no way of deprecating the mai' variant of a symbol. What you did will show a warning for all variants of join as well...

[Enivex]

Ugh this is unfortunate. There is no way of deprecating the mai' variant of a symbol. What you did will show a warning for all variants of join as well...

Remove the top level symbol and create a new variant for default fallback, then mark that as deprecated instead

[MDLC01]

With the way things are implemented, I fear this may not warn at all.

Warnings are hard to reason about when it comes to symbols. I'll think about this tomorrow.

[T0mstone]

Ugh this is unfortunate. There is no way of deprecating the mai' variant of a symbol. What you did will show a warning for all variants of join as well...

That is entirely intentional, as they would be removed and replaced by variants of bowtie.big.

[MDLC01]

Great then!

[Enivex]

It's somewhat unfortunate that l and r are used for entirely different things within the same symbol. But I guess it's unavoidable.

[Enivex]

I think it makes more sense to just put this at the top level (without stroked), unless there are additional variants not included here.

[T0mstone]

That's what I had originally, but my thinking was that it makes more sense to keep .stroked when there's also .filled. That's also how it is for e.g. hourglass.

[Enivex]

Currently we aren't entirely consistent (which we ideally should improve upon), but in my mind it makes more sense when there is no canonical variant. In this case the stroked one is the canonical variant, and stroked just serves as extra noise.

Not to mention the big variants are variants of the stroked ones.

[T0mstone]

Remember that it's not required. Since stroked is the first variant, bowtie is automatically a shorthand for bowtie.stroked. A part of me thinks that users could be confused when some symbols only have stroked available as a modifier and some only have filled.

[Enivex]

Remember that it's not required. Since stroked is the first variant, bowtie is automatically a shorthand for bowtie.stroked. A part of me thinks that users could be confused when some symbols only have stroked available as a modifier and some only have filled.

I know that it's not required, but I don't think that's a good reason to add unnecessary modifiers.

[Enivex]

If we have .stroked we should have it for everything that is not filled

I really don't agree. Stroked and filled are used essentially as our versions of "white" and "black" in unicode naming.

It makes perfect sense to have both stroked and filled when there is no canonical version of the symbol.

In this case the regular bowtie symbols are canonical, and the filled ones are exceptional.

[Enivex]

Notice how the unicode names mention "black" specifically, but not "white" for the regular ones.

[T0mstone]

I really don't want the added complexity of enshrining a "canonical version" for some symbols by means of omitting certain modifiers for them. That's another data point users will have to remember and seems like a totally unnecessary restriction. It's conceptually so much simpler to just have both modifiers for everything with those two styles, whether one of them is canonical or not.

[Enivex]

I would say that having .stroked is more complexity, not less. Why should I have to arbitrarily have to remember which operators get the stroked, only because they have a filled variant? I do not like relying on fallback, because it's unpredictable and brittle to codex changes. Almost everyone who want these symbols will want the .stroked variants.

[MDLC01]

I do not like relying on fallback

But fallback is a feature. If you choose not to use it, then of course you may have to specify annoying modifiers.

My view is that most changes do not affect fallbacks. When they do, we should be careful about it. And we should have a way to specify which fallbacks can be relied on, and which cannot (e.g., with the minimal modifier set proposal I link everywhere).

[T0mstone]

It's somewhat unfortunate that l and r are used for entirely different things within the same symbol. But I guess it's unavoidable.

I think it's unambiguous enough as long as we don't have bowtie.l/bowtie.r on their own. (Tho these would currently automatically exist as shorthands, so #51 could improve the situation here).

[knuesel]

Compared to the old join.l we lose some clarity with bowtie.big.l: the name has nothing to suggest what happens on the left side. An idea could be to replace the big modifier with join:

bowtie
  .stroked ⋈
  .filled ⧓
  .filled.l ⧑
  .filled.r ⧒
  .join ⨝
  .join.r ⟖
  .join.l ⟕
  .join.l.r ⟗

Edit: though I would also prefer not including stroked so:

bowtie ⋈
  .filled ⧓
  .filled.l ⧑
  .filled.r ⧒
  .join ⨝
  .join.r ⟖
  .join.l ⟕
  .join.l.r ⟗

[Enivex]

Compared to the old join.l we lose some clarity with bowtie.big.l: the name has nothing to suggest what happens on the left side. An idea could be to replace the big modifier with join:

This is problematic both because we're trying to get away from join, and because it would be counter to every other n-ary operator (which we use .big for).

[T0mstone]

I've added .stroked to the big variants as you suggested.

I've also changed the order so that bowtie.l and bowtie.r resolve to the large variants since that's probably more likely what the user would want (tho ideally with #51 those would just be forbidden here).

[Enivex]

I've added .stroked to the big variants as you suggested.

I've also changed the order so that bowtie.l and bowtie.r resolve to the large variants since that's probably more likely what the user would want (tho ideally with #51 those would just be forbidden here).

You also need to change the deprecation message

[T0mstone]

You also need to change the deprecation message

Not changing that was actually intentional. My thinking was that suggesting the full version might lead to worse UX since users may not know that the .stroked part is optional.

[Enivex]

You also need to change the deprecation message

Not changing that was actually intentional. My thinking was that suggesting the full version might lead to worse UX since users may not know that the .stroked part is optional.

Well, that is the full name of the symbol. I think every other deprecation message so far has used the full name.

[T0mstone]

I'm also fine with changing it (the deprecation message). What do the others think?

[MDLC01]

I think we should suggest the simplest version of the name that we know we won't break in the near future. In this case, this would be without .stroked.

Fallback is a feature. It has many drawbacks, but there are also some cases where it makes sense to use it. I would argue this is on of them.