Remove duplicate suggestions

[Thomas-D-C]

Background

It would be nice that the context menu doesn't suggest useless items. (I'm using only casing.)
For ex when I ask for i, it suggests i/I/I/I.

Proposed solution

For each suggested text transformation, after the transformation is made, check whether:

• it's the same as original,
• it's already suggested upper.

If yes, remove the item.

It would also be useful for code casing, in all cases where is there only one word to handle.
I don't think it would be useful for those with special characters.

Alternatives

It could be seen as an alternative to #30, although it is more of a complement.

[Thomas-D-C]

• it's the same as original,

• it's already suggested upper.

If yes, remove the item.

If it's the same as original and it's not already suggested upper, it could be disabled instead of removed.

---

Currently:

It could be reduced to:

(with item grayed)

[tdulcet]

If it's the same as original and it's not already suggested upper, it could be inactivated (not selectable) instead of removed.

Interesting, this is a lot easier to implement than removing the menu items, although there would still be duplicates:

I included this change in #96. Let me know if it would satisfy your request.

[Thomas-D-C]

If it's the same as original and it's not already suggested upper, it could be inactivated (not selectable) instead of removed.

Interesting, this is a lot easier to implement than removing the menu items, although there would still be duplicates

Why is it difficult to remove the menu items?
Annoying: duplicates are the most important.

I included this change in #96. Let me know if it would satisfy your request.

Anyway it's an improvement. Please keep it! :-)

[tdulcet]

Why is it difficult to remove the menu items?

Removing the menu items is not difficult per say, it is determining which items to remove. By default, Unicodify provides a nested context menu with descriptions of each menu item:

It would likely be confusing for users if they had to go into a different submenu and select a different menu item then what they actually wanted in order to get the desired conversion/casing.

Anyway it's an improvement. Please keep it! :-)

No problem, I will keep this change in #96 and it should be included in the next update.

[Thomas-D-C]

Why is it difficult to remove the menu items?

Removing the menu items is not difficult per say, it is determining which items to remove.

If I said "So, disable them instead.", would it be the same difficulty, or is it a UI pb only?

By default, Unicodify provides a nested context menu with descriptions of each menu item

It would likely be confusing for users if they had to go into a different submenu and select a different menu item then what they actually wanted in order to get the desired conversion/casing.

I might suggest making a setting to allow users to choose that, but maybe the Show a readable description of the transformation setting is enough: if checked, users need all items to avoid any confusion; if not, it's useless (IMHO even with the nested context menu).

[tdulcet]

If I said "So, disable them instead.", would it be the same difficulty, or is it a UI pb only?

One would not want to remove the menu items per say, as there is a performance cost to add them back. Instead, one can ether disable or hide each of them (by updating the respective property), both of which are equally easy to do. The problem is then determining which ones to hide. The way the add-on is currently designed, each menu item is handled independently, with no knowledge of the other items.

[Thomas-D-C]

If I said "So, disable them instead.", would it be the same difficulty, or is it a UI pb only?

The problem is then determining which ones to hide. The way the add-on is currently designed, each menu item is handled independently, with no knowledge of the other items.

OK, so it would be the same difficulty, because it's not sequential.

Well, what would be some ways to make each menu item know the value of those above it, but not those below it?
Maybe a shared array, with each menu item knowing its position on it? (hope not too high cost!)

[tdulcet]

Well, what would be some ways to make each menu item know the value of those above it, but not those below it?

Yeah, we would either need to iterate through the conversions beforehand to determine which ones to make visible or maintain some shared state while updating them. This is something we can consider for a future update.

The question is whether the duplicates should be removed/hidden per category (the four listed on the options page) or for all of the conversions combined. In the latter case, those separator lines should probably be removed as well.

There is also the question of which combination of options should enable this feature. I would say the "readable description" should be off, while the "live preview" should be on. The "nested context menu" option should probably be off as well, unless maybe if we were hiding the duplicates per category.

[Thomas-D-C]

Well, what would be some ways to make each menu item know the value of those above it, but not those below it?

Yeah, we would either need to iterate through the conversions beforehand to determine which ones to make visible or maintain some shared state while updating them. This is something we can consider for a future update.

I hope it will be soon. :-)
Unfortunately I don't know JavaScript, so I can't make PR.

But maybe I can help you with the algorithm?
What are the advantages and disadvantages of each?

When my computer is slow I see that menu items can be updated after the menu is open. Is it the same for hiding?
Can you be aware when the last menu item has finished?
If yes, when they have finished, you can launch an iterative process which will tell each menu item if it has to be hidden.

The question is whether the duplicates should be removed/hidden per category (the four listed on the options page)

AFAIK, duplicates cannot happen for the 2 first categories, am I wrong?
If I'm right, you can care about duplicates only for the 2 last categories.

or for all of the conversions combined.

I don't need to have each of them twice, and what is obvious is that no one needs duplicates in the same sub-menu when they have the same title.

So if you want to make the best extension possible, and with the mindset that if readable description is checked, users need all items to avoid any confusion, it will be the same about nested context menu.

In the latter case, those separator lines should probably be removed as well.

Still if you want to make the best extension possible, yes, it would be better. :-)
(Keep me aware of the constraints, so I can see how I can help you.)

There is also the question of which combination of options should enable this feature. I would say the "readable description" should be off, while the "live preview" should be on.

You're true: We need to check both, since when they're both unchecked readable description preempts.

The "nested context menu" option should probably be off as well, unless maybe if we were hiding the duplicates per category.

---

Disable duplicates handling

If live preview and not readable description then:

Enable duplicates handling

Case nested context menu:

Checked:

Reset the duplicates handling process for each sub-menu

Unchecked:

Reset the duplicates handling process only once at the beginning

---

Have you recently checked the case where readable description is checked and live preview is unchecked?
The readable description appears twice: once normal and once transformed. Is this a bug?

When they're both unchecked, the readable description appears transformed. Maybe this is a bug too, but I like it. :-)

[tdulcet]

When my computer is slow I see that menu items can be updated after the menu is open. Is it the same for hiding?

Every time the context menu is opened on an editable context and the "live preview" option is enabled, all of the menu items are updated. It does not matter how they are updated (hidden, disabled, changing the title, etc.), it is all the same speed.

Can you be aware when the last menu item has finished?

Yes, but the updating is slow (requires calling an async Web Extension API), so one would not want to wait for that to complete or do it more than once per menu item.

AFAIK, duplicates cannot happen for the 2 first categories, am I wrong?

The Unicode fonts only support ASCII characters and usually only a small subset, so for example if the user selects text without any Latin letters, there would be conversions that would not make any changes to the text and thus there would be duplicate menu items. Here are the supported characters for each Unicode font (note that ASCII characters are used as placeholders missing ones):

unicodify/src/common/modules/data/Fonts.js

Lines 166 to 192 in 374ed91

	SerifBold: "𝐀𝐁𝐂𝐃𝐄𝐅𝐆𝐇𝐈𝐉𝐊𝐋𝐌𝐍𝐎𝐏𝐐𝐑𝐒𝐓𝐔𝐕𝐖𝐗𝐘𝐙𝐚𝐛𝐜𝐝𝐞𝐟𝐠𝐡𝐢𝐣𝐤𝐥𝐦𝐧𝐨𝐩𝐪𝐫𝐬𝐭𝐮𝐯𝐰𝐱𝐲𝐳𝟎𝟏𝟐𝟑𝟒𝟓𝟔𝟕𝟖𝟗",
	SerifItalic: "𝐴𝐵𝐶𝐷𝐸𝐹𝐺𝐻𝐼𝐽𝐾𝐿𝑀𝑁𝑂𝑃𝑄𝑅𝑆𝑇𝑈𝑉𝑊𝑋𝑌𝑍𝑎𝑏𝑐𝑑𝑒𝑓𝑔ℎ𝑖𝑗𝑘𝑙𝑚𝑛𝑜𝑝𝑞𝑟𝑠𝑡𝑢𝑣𝑤𝑥𝑦𝑧",
	SerifBoldItalic: "𝑨𝑩𝑪𝑫𝑬𝑭𝑮𝑯𝑰𝑱𝑲𝑳𝑴𝑵𝑶𝑷𝑸𝑹𝑺𝑻𝑼𝑽𝑾𝑿𝒀𝒁𝒂𝒃𝒄𝒅𝒆𝒇𝒈𝒉𝒊𝒋𝒌𝒍𝒎𝒏𝒐𝒑𝒒𝒓𝒔𝒕𝒖𝒗𝒘𝒙𝒚𝒛",
	SansSerif: "𝖠𝖡𝖢𝖣𝖤𝖥𝖦𝖧𝖨𝖩𝖪𝖫𝖬𝖭𝖮𝖯𝖰𝖱𝖲𝖳𝖴𝖵𝖶𝖷𝖸𝖹𝖺𝖻𝖼𝖽𝖾𝖿𝗀𝗁𝗂𝗃𝗄𝗅𝗆𝗇𝗈𝗉𝗊𝗋𝗌𝗍𝗎𝗏𝗐𝗑𝗒𝗓𝟢𝟣𝟤𝟥𝟦𝟧𝟨𝟩𝟪𝟫",
	SansSerifBold: "𝗔𝗕𝗖𝗗𝗘𝗙𝗚𝗛𝗜𝗝𝗞𝗟𝗠𝗡𝗢𝗣𝗤𝗥𝗦𝗧𝗨𝗩𝗪𝗫𝗬𝗭𝗮𝗯𝗰𝗱𝗲𝗳𝗴𝗵𝗶𝗷𝗸𝗹𝗺𝗻𝗼𝗽𝗾𝗿𝘀𝘁𝘂𝘃𝘄𝘅𝘆𝘇𝟬𝟭𝟮𝟯𝟰𝟱𝟲𝟳𝟴𝟵",
	SansSerifItalic: "𝘈𝘉𝘊𝘋𝘌𝘍𝘎𝘏𝘐𝘑𝘒𝘓𝘔𝘕𝘖𝘗𝘘𝘙𝘚𝘛𝘜𝘝𝘞𝘟𝘠𝘡𝘢𝘣𝘤𝘥𝘦𝘧𝘨𝘩𝘪𝘫𝘬𝘭𝘮𝘯𝘰𝘱𝘲𝘳𝘴𝘵𝘶𝘷𝘸𝘹𝘺𝘻",
	SansSerifBoldItalic: "𝘼𝘽𝘾𝘿𝙀𝙁𝙂𝙃𝙄𝙅𝙆𝙇𝙈𝙉𝙊𝙋𝙌𝙍𝙎𝙏𝙐𝙑𝙒𝙓𝙔𝙕𝙖𝙗𝙘𝙙𝙚𝙛𝙜𝙝𝙞𝙟𝙠𝙡𝙢𝙣𝙤𝙥𝙦𝙧𝙨𝙩𝙪𝙫𝙬𝙭𝙮𝙯",
	Script: "𝒜ℬ𝒞𝒟ℰℱ𝒢ℋℐ𝒥𝒦ℒℳ𝒩𝒪𝒫𝒬ℛ𝒮𝒯𝒰𝒱𝒲𝒳𝒴𝒵𝒶𝒷𝒸𝒹ℯ𝒻ℊ𝒽𝒾𝒿𝓀𝓁𝓂𝓃ℴ𝓅𝓆𝓇𝓈𝓉𝓊𝓋𝓌𝓍𝓎𝓏",
	ScriptBold: "𝓐𝓑𝓒𝓓𝓔𝓕𝓖𝓗𝓘𝓙𝓚𝓛𝓜𝓝𝓞𝓟𝓠𝓡𝓢𝓣𝓤𝓥𝓦𝓧𝓨𝓩𝓪𝓫𝓬𝓭𝓮𝓯𝓰𝓱𝓲𝓳𝓴𝓵𝓶𝓷𝓸𝓹𝓺𝓻𝓼𝓽𝓾𝓿𝔀𝔁𝔂𝔃",
	Fraktur: "𝔄𝔅ℭ𝔇𝔈𝔉𝔊ℌℑ𝔍𝔎𝔏𝔐𝔑𝔒𝔓𝔔ℜ𝔖𝔗𝔘𝔙𝔚𝔛𝔜ℨ𝔞𝔟𝔠𝔡𝔢𝔣𝔤𝔥𝔦𝔧𝔨𝔩𝔪𝔫𝔬𝔭𝔮𝔯𝔰𝔱𝔲𝔳𝔴𝔵𝔶𝔷",
	FrakturBold: "𝕬𝕭𝕮𝕯𝕰𝕱𝕲𝕳𝕴𝕵𝕶𝕷𝕸𝕹𝕺𝕻𝕼𝕽𝕾𝕿𝖀𝖁𝖂𝖃𝖄𝖅𝖆𝖇𝖈𝖉𝖊𝖋𝖌𝖍𝖎𝖏𝖐𝖑𝖒𝖓𝖔𝖕𝖖𝖗𝖘𝖙𝖚𝖛𝖜𝖝𝖞𝖟",
	Monospace: "𝙰𝙱𝙲𝙳𝙴𝙵𝙶𝙷𝙸𝙹𝙺𝙻𝙼𝙽𝙾𝙿𝚀𝚁𝚂𝚃𝚄𝚅𝚆𝚇𝚈𝚉𝚊𝚋𝚌𝚍𝚎𝚏𝚐𝚑𝚒𝚓𝚔𝚕𝚖𝚗𝚘𝚙𝚚𝚛𝚜𝚝𝚞𝚟𝚠𝚡𝚢𝚣𝟶𝟷𝟸𝟹𝟺𝟻𝟼𝟽𝟾𝟿",
	DoubleStruck: "𝔸𝔹ℂ𝔻𝔼𝔽𝔾ℍ𝕀𝕁𝕂𝕃𝕄ℕ𝕆ℙℚℝ𝕊𝕋𝕌𝕍𝕎𝕏𝕐ℤ𝕒𝕓𝕔𝕕𝕖𝕗𝕘𝕙𝕚𝕛𝕜𝕝𝕞𝕟𝕠𝕡𝕢𝕣𝕤𝕥𝕦𝕧𝕨𝕩𝕪𝕫𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡",
	Circled: " !\"#$%&'()⊛⊕,⊖⊙⊘⓪①②③④⑤⑥⑦⑧⑨:;⧀⊜⧁?@ⒶⒷⒸⒹⒺⒻⒼⒽⒾⒿⓀⓁⓂⓃⓄⓅⓆⓇⓈⓉⓊⓋⓌⓍⓎⓏ[⦸]^_`ⓐⓑⓒⓓⓔⓕⓖⓗⓘⓙⓚⓛⓜⓝⓞⓟⓠⓡⓢⓣⓤⓥⓦⓧⓨⓩ{⦶}~",
	CircledBlack: "🅐🅑🅒🅓🅔🅕🅖🅗🅘🅙🅚🅛🅜🅝🅞🅟🅠🅡🅢🅣🅤🅥🅦🅧🅨🅩⓿❶❷❸❹❺❻❼❽❾",
	Squared: " !\"#$%&'()⧆⊞,⊟⊡⧄0123456789:;<=>?@🄰🄱🄲🄳🄴🄵🄶🄷🄸🄹🄺🄻🄼🄽🄾🄿🅀🅁🅂🅃🅄🅅🅆🅇🅈🅉[⧅]^_`🄰🄱🄲🄳🄴🄵🄶🄷🄸🄹🄺🄻🄼🄽🄾🄿🅀🅁🅂🅃🅄🅅🅆🅇🅈🅉{|}~",
	SquaredBlack: "🅰🅱🅲🅳🅴🅵🅶🅷🅸🅹🅺🅻🅼🅽🅾🅿🆀🆁🆂🆃🆄🆅🆆🆇🆈🆉",
	Parenthesized: "🄐🄑🄒🄓🄔🄕🄖🄗🄘🄙🄚🄛🄜🄝🄞🄟🄠🄡🄢🄣🄤🄥🄦🄧🄨🄩⒜⒝⒞⒟⒠⒡⒢⒣⒤⒥⒦⒧⒨⒩⒪⒫⒬⒭⒮⒯⒰⒱⒲⒳⒴⒵0⑴⑵⑶⑷⑸⑹⑺⑻⑼",
	// https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)
	Fullwidth: "　！＂＃＄％＆＇（）＊＋，－．／０１２３４５６７８９：；＜＝＞？＠ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺ［＼］＾＿｀ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ｛｜｝～",
	// Adapted from: https://rupertshepherd.info/resource_pages/superscript-letters-in-unicode
	// https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
	Superscript: " !\"#$%&'⁽⁾*⁺,⁻./⁰¹²³⁴⁵⁶⁷⁸⁹:;<⁼>?@ᴬᴮꟲᴰᴱꟳᴳᴴᴵᴶᴷᴸᴹᴺᴼᴾꟴᴿˢᵀᵁⱽᵂˣʸᶻ[\\]^_`ᵃᵇᶜᵈᵉᶠᵍʰⁱʲᵏˡᵐⁿᵒᵖ𐞥ʳˢᵗᵘᵛʷˣʸᶻ{|}~",
	Subscript: " !\"#$%&'₍₎*₊,₋./₀₁₂₃₄₅₆₇₈₉:;<₌>?@ₐBCDₑFGₕᵢⱼₖₗₘₙₒₚQᵣₛₜᵤᵥWₓYZ[\\]^_`ₐbcdₑfgₕᵢⱼₖₗₘₙₒₚqᵣₛₜᵤᵥwₓyz{|}~",
	SmallCaps: `ABCDEFGHIJKLMNOPQRSTUVWXYZ${smallCaps}`,
	AllSmallCaps: smallCaps,
	Unicase: `${smallCaps}abcdefghijklmnopqrstuvwxyz`

Still if you want to make the best extension possible, yes, it would be better. :-)

Yes, we always want to make the best extension possible! 🙂 Of course, that has to be balanced with how many users might use this functionality and the additional complexity. Because the readable description option is enabled by default, I am not sure how many users would explicitly disable it.

The readable description appears twice: once normal and once transformed. Is this a bug?

No, that is the expected behavior.

When they're both unchecked, the readable description appears transformed. Maybe this is a bug too, but I like it. :-)

Yeah, this was the original behavior I implemented. The "readable description" and "live preview" options were added later by @rugk.

Thanks for that flow chart of your desired behavior with the various combinations of options. That should be very helpful for if/when someone implements this feature.

[rugk]

I don't see a flow chart, where is a flow chart?

So from what I read, whether we disable/hide the menu item does not matter much, but actually this can result in UX issues and needs to consider all different options of the extension in mind. 🙃

Much has been said, but we would indeed need to think through all options, a flow-chart indeed sounds very useful.
And I agree, we must avoid:

• (1) users not finding "their" option, because it is hidden somewhere
• (2) users being confused, because an option appears multiple times (what this issue is about)

So this is kind of an UX tradeoff as both aims seem to contradict each other.

in the essence, AFAIK, when you see a "readable description" we should allow any duplicates. Only when you only(!) see the live preview, this algorithm could apply.
And in such a case, we could actually hide the items. Except if they are in sub-categories, because then we would violate the aim (1). Yet again, except if that is inside the same sub-menu. That would be fine.
And finally, yes, I agree separators also need to be handled.

The idea sounds easy, the implementation does sounds way less easier if you think about all this…

Implementation

As for an implementation hint, here is the relevant code (actually the whole file more or less, but this is what matters):

unicodify/src/background/modules/ContextMenu.js

Line 123 in 374ed91

async function buildMenu(unicodeFontSettings, exampleText = null) {

As you can see, it already is quite complex, so making it even more complex sounds fun… 😉

[tdulcet]

I don't see a flow chart, where is a flow chart?

@tDeContes used the Markdown quote syntax, so it is somewhat hidden at first glance: #93 (comment). Converting it to a list may be more readable, although GitHub does support creating actual flow charts:

1. Disable duplicates handling
2. If live preview and not readable description then:
   1. Enable duplicates handling
   2. Case nested context menu:
   3. Checked:
      1. Reset the duplicates handling process for each sub-menu
   4. Unchecked:
      1. Reset the duplicates handling process only once at the beginning