Add option to show open+close context for punctuation

[arrowtype]

Adds option to start the spacing string with open+close punctuation, if either the left or right character would logically have an associated open/close character. For example:

I got what I think is a full list of open/close punctuation from here and here, then did some editing to make these into strings, and some simple python to make them into dictionary entries:

open= "([{༺༼᚛‚„⁅⁽₍⌈⌊〈❨❪❬❮❰❲❴⟅⟦⟨⟪⟬⟮⦃⦅⦇⦉⦋⦍⦏⦑⦓⦕⦗⧘⧚⧼⸢⸤⸦⸨〈《「『【〔〖〘〚〝⹂﴿︗︵︷︹︻︽︿﹁﹃﹇﹙﹛﹝（［｛｟｢"
close=")]}༻༽᚜‘“⁆⁾₎⌉⌋〉❩❫❭❯❱❳❵⟆⟧⟩⟫⟭⟯⦄⦆⦈⦊⦌⦎⦐⦒⦔⦖⦘⧙⧛⧽⸣⸥⸧⸩〉》」』】〕〗〙〛〞〟﴾︘︶︸︺︼︾﹀﹂﹄﹈﹚﹜﹞）］｝｠｣"
for i, char in enumerate(open):
    print(f'"{char}": "{close[i]}",')

non-collapsed list to show open+close matches (Click to expand)

(    )
[    ]
{    }
༺    ༻
༼    ༽
᚛    ᚜
‚    ‘
„    “
⁅    ⁆
⁽    ⁾
₍    ₎
⌈    ⌉
⌊    ⌋
〈    〉
❨    ❩
❪    ❫
❬    ❭
❮    ❯
❰    ❱
❲    ❳
❴    ❵
⟅    ⟆
⟦    ⟧
⟨    ⟩
⟪    ⟫
⟬    ⟭
⟮    ⟯
⦃    ⦄
⦅    ⦆
⦇    ⦈
⦉    ⦊
⦋    ⦌
⦍    ⦎
⦏    ⦐
⦑    ⦒
⦓    ⦔
⦕    ⦖
⦗    ⦘
⧘    ⧙
⧚    ⧛
⧼    ⧽
⸢    ⸣
⸤    ⸥
⸦    ⸧
⸨    ⸩
〈    〉
《    》
「    」
『    』
【    】
〔    〕
〖    〗
〘    〙
〚    〛
〝    〞
⹂    〟
﴿    ﴾
︗    ︘
︵    ︶
︷    ︸
︹    ︺
︻    ︼
︽    ︾
︿    ﹀
﹁    ﹂
﹃    ﹄
﹇    ﹈
﹙    ﹚
﹛    ﹜
﹝    ﹞
（    ）
［    ］
｛    ｝
｟    ｠
｢    ｣

(I’m guessing there might be a more-clever way to do this with the Python Unicode module, but as it was, these had to be manually sorted a bit to make the correct open+close pairs.)

To be honest, I’m unsure of whether the vertical-specific characters should be included in here – I think someone would need a custom Space Center for vertical type, anyway. But, I figure it’s probably better to ere on the side of inclusivity rather than leaving things out, so I’ve left them in. Let me know if you feel that the list should be different!

Also, this PR removes the following unneeded code (the checkbox is false by default):

self.w.mirroredPair.set(False)

PS: Nice improvement for adding the context option text! I tried to carry that forward with this addition. Feel free to fix anything here you see fit, obviously, or let me know what could be done better. Thank you!

[cjdunn]

Thanks so much for adding this feature! This is mostly working for me, and I think it’s a great addition.

Only a few open+close pairs so far that I'd expect to work which are not working for me (I'm listing them here using AGL glyph names just so they’re easier to read):
/quoteleft /quoteright
/guilsinglleft /guilsinglright
/guillemotleft /guillemotright
/guilsinglright /guilsinglleft (I’ve seen these used in both directions, so it seems we should include both)
/guillemotright /guillemotleft (same as above)
/quotesingle /quotesingle (should be same glyph on both sides)

More questions:
–should the options for "start with mirrored" still result in starting with the mirrored string when all options are checked? Logically I think it should. Currently it does not.

–Should the open+close context continue into the spacing string, eg: HH[A]HOHO[A]OO ? I would expect for this to happen, but currently it does not.

What do you think? Thanks!

[arrowtype]

Thanks for your review!

a few open+close pairs so far that I'd expect to work which are not working for me

🤦‍♂️ Oops, haha, those were all working until I tried to be smart and add a comprehensive list.

• I now realize that there are separate categories for open punctuation vs initial punctuation and close punctuation vs final punctuation.
• I have added quotes back, plus I went through this list of Quotation Marks in various languages to (I think) add all possibilities.
• I adjusted the function so that it can return multiple options if there are multiple options, e.g. the pair O” should show both ”O” and “O”

should the options for "start with mirrored" still result in starting with the mirrored string when all options are checked? Logically I think it should. Currently it does not.

You’re right, a "start with mirrored" option should start with mirrored context. However, 1) the open+close context is more important for actual usage, and 2) the open+close context only shows up sometimes and I really want to see it when it does. So, I have moved open+close to be first and adjusted the option labels to not include "start with." Do you think this works, or do you feel that it actually is better to put the mirrored context first?

Should the open+close context continue into the spacing string, eg: HH[A]HOHO[A]OO ? I would expect for this to happen, but currently it does not.

I could be convinced, but at first, I actually don’t think so. For me, the purpose of the spacing string is to make sure that for pair A], the A looks centered in HA] and OA]. If we inserted the open+close context here, I think it would be harder to achieve similar spacing between open+close punctuation and control characters.

Questions:

• As you indicate in one of your questions, and expected spacing string might be HH‘RHOHO‘ROO. However, with this extension I currently get HOH‘RHOHO‘ROO (starting with HO rather than HH). This is also the case for lowercase: non‘rnono‘roo rather than nn‘rnono‘roo. Is this a bug, or intentional?

• This now checks the font’s unicodes inside openCloseContext() so that we don’t print out open+close combos that are missing one side or the other (it’s confusing if we try to, as that glyph just doesn’t appear in the space center). However, in a large enough font, this might slow things down. So, potentially we could move that to the top level, and only check unicodes when the CurrentFont changes. Then again, that might be over-optimizing without reason. What do you think?

• A slightly more abstract question, possibly better for an issue ... how else might we add in more context? E.g. probably, for a pair like V., users will want to also see W., Y., and maybe others as well. Is this something we could guess at (like open+close context), something that people are already able to just do with default MM features, or something that might require some kind of Ramsey-Street style user settings?

[cjdunn]

Awesome, this looks great.

I just made one change to the order of the pairs, so the /quoteright /quoteright and /quotedblright /quotedblright pairs come later than the /quoteleft /quoteright and /quotedblleft /quotedblright. So now when both show up the left right pair comes first, which makes more sense for the way I kern things, hope that’s OK with you.

Thanks for your review!

a few open+close pairs so far that I'd expect to work which are not working for me

🤦‍♂️ Oops, haha, those were all working until I tried to be smart and add a comprehensive list.

I now realize that there are separate categories for open punctuation vs initial punctuation and close punctuation vs final punctuation.
I have added quotes back, plus I went through this list of Quotation Marks in various languages to (I think) add all possibilities.
I adjusted the function so that it can return multiple options if there are multiple options, e.g. the pair O” should show both ”O” and “O”
should the options for "start with mirrored" still result in starting with the mirrored string when all options are checked? Logically I think it should. Currently it does not.

You’re right, a "start with mirrored" option should start with mirrored context. However, 1) the open+close context is more important for actual usage, and 2) the open+close context only shows up sometimes and I really want to see it when it does. So, I have moved open+close to be first and adjusted the option labels to not include "start with." Do you think this works, or do you feel that it actually is better to put the mirrored context first?

Yes, I think this is great.

Should the open+close context continue into the spacing string, eg: HH[A]HOHO[A]OO ? I would expect for this to happen, but currently it does not.

I could be convinced, but at first, I actually don’t think so. For me, the purpose of the spacing string is to make sure that for pair A], the A looks centered in HA] and OA]. If we inserted the open+close context here, I think it would be harder to achieve similar spacing between open+close punctuation and control characters.

OK, that’s fine to leave as is for the time being. I’ve got to use it more to know if this would be important to me or not, and if it would maybe warrant another check box, if it’s not the default. Hmm.

Questions:

As you indicate in one of your questions, and expected spacing string might be HH‘RHOHO‘ROO. However, with this extension I currently get HOH‘RHOHO‘ROO (starting with HO rather than HH). This is also the case for lowercase: non‘rnono‘roo rather than nn‘rnono‘roo. Is this a bug, or intentional?

This was indeed a typo, I’ve fixed it now.

This now checks the font’s unicodes inside openCloseContext() so that we don’t print out open+close combos that are missing one side or the other (it’s confusing if we try to, as that glyph just doesn’t appear in the space center). However, in a large enough font, this might slow things down. So, potentially we could move that to the top level, and only check unicodes when the CurrentFont changes. Then again, that might be over-optimizing without reason. What do you think?

This seems to be working for me and I’m not seeing any performance issues on my end, so I’m fine with having it in there unless we encounter any issues.

A slightly more abstract question, possibly better for an issue ... how else might we add in more context? E.g. probably, for a pair like V., users will want to also see W., Y., and maybe others as well. Is this something we could guess at (like open+close context), something that people are already able to just do with default MM features, or something that might require some kind of Ramsey-Street style user settings?

This is an excellent question, and something I’ve been thinking about. I'll move this to a new issue here:
#6

I'll add my small changes and I think this could be good for a next release, unless you have any other changes/additions for the open+close feature. Thanks again!

[arrowtype]

Awesome, thanks!

I just made one change to the order of the pairs, so the /quoteright /quoteright and /quotedblright /quotedblright pairs come later than the /quoteleft /quoteright and /quotedblleft /quotedblright. So now when both show up the left right pair comes first, which makes more sense for the way I kern things, hope that’s OK with you.

Good thinking! Same here. Thanks.

I’ve got to use it more to know if this would be important to me or not, and if it would maybe warrant another check box, if it’s not the default. Hmm.

Yeah, that might be a good idea. I have also wondered if there might be an easy way to allow people to control their context strings. Then again, I am unsure at what point we might be pointlessly duplicating features from MM. It looks like this is what you posted about in issue #6, so I’ll comment there.

I'll add my small changes and I think this could be good for a next release, unless you have any other changes/additions for the open+close feature.

I think this is at a good spot to release! Thanks for your quick reviews and help.