Consider omitting not applicable rows rather than displaying question marks

[lukaszgo1]

This example is rather silly but demonstrates the problem pretty well:

1. Display character information for the letter 's'.
2. Inspect the table and look for the CLDR value.

If value is missing currently question mark is shown which I personally find rather confusing. It would be better to omit rows with no values IMO. @CyrilleB79 What do you think? Would you accept a PR for this?

[CyrilleB79]

@lukaszgo1 thanks for your proposal.

1. I guess you meant 'row' instead of 'column'.

2. Which category is problematic for you? Only CLDR or also other ones.

3. Note also that in some cases, you may have English CLDR name available but not local name. In this case, you will have the following displayed for CLDR:
   englishCharacterName / ?
   I guess you would maintain the row in this case, but thus you do not completely get rid of the question marks.

4. Personaly, I am unsure if having row that may be present or not may change the way I am using the add-on. I do not exactly realize how often I count the number of control+alt+downArrow press to get a specific info. To circumvent this potential issue, I am thinking to put CLDR at the end after the block category; but I am still unsure. What do you think of it? In one hand, this is more clear because CLDR is not properly the same type of information than all other unicode info. On the other hand, It's interesting to have CLDR quite on the top because it is a more frequently used information.

5. Note also that removing unuseful rows is already done with Microsoft proprietary character set.

6. Also to keep in mind, I am thinking to add more information in the page; I have just opened Provide additional informations on character #6 to track it (even if it is low priority task for me). Thus maybe there will be many headings and tables.
   When Provide additional informations on character #6 is implemented, for personal locale symbol file, if there is no entry, should I remove the line or not?

It would be interesting discussing all these questions before writing a PR. I am interested to hear your thinking on all of these points.
points.

[lukaszgo1]

1. I guess you meant 'row' instead of 'column'.

Sure - my bad - I've amended the issue title and initial comment.

2. Which category is problematic for you? Only CLDR or also other ones.

CLDR is most commonly empty but I see no reason to thread some categories differently than others.

3. Note also that in some cases, you may have English CLDR name available but not local name. In this case, you will have the following displayed for CLDR:
   englishCharacterName / ?
   I guess you would maintain the row in this case, but thus you do not completely get rid of the question marks.

I've never seen this but that's because I'm using NVDA exclusively in English (Polish localization is messed up so badly as to being unusable). Having said that I believe this UX is rather confusing and the meaning of question mark is not explained in the documentation. My first thought would be to present localized name from CLDR if it exists and if not change the row header to something like "CLDR English" and omit the question mark.

4. Personaly, I am unsure if having row that may be present or not may change the way I am using the add-on. I do not exactly realize how often I count the number of control+alt+downArrow press to get a specific info. To circumvent this potential issue, I am thinking to put CLDR at the end after the block category; but I am still unsure. What do you think of it? In one hand, this is more clear because CLDR is not properly the same type of information than all other unicode info. On the other hand, It's interesting to have CLDR quite on the top because it is a more frequently used information.

My main reason for getting rid of the question marks is that when moving with alt+Ctrl+arrows through the table these cells are silent unless punctuation level is set to all so it can be easily confused with empty cells (which happens for unprintable characters like \t). I'd rather leave order as is.

6. Also to keep in mind, I am thinking to add more information in the page; I have just opened [Provide additional informations on character #6](https://github.com/CyrilleB79/charInfo/issues/6) to track it (even if it is low priority task for me). Thus maybe there will be many headings and tables.
   When [Provide additional informations on character #6](https://github.com/CyrilleB79/charInfo/issues/6) is implemented, for personal locale symbol file, if there is no entry, should I remove the line or not?

As I said above being consistent is nice so either all missing information should get question marks or all rows with missing info should be not present in the table IMO.

[CyrilleB79]

Turning back to this issue, here is my position today:

• I do not want to remove rows with no information, I prefer to have a predictable layout
• I may replace the question mark in Unicode table by something more suitable if we find something acceptable

Moreover, as examples of characters with missing information, you have:

• Unexisting characters, i.e. unassigned Unicode point, e.g. character "΢" (character 930=0x3a2)
• Character for which Unicode does not define a name such as control characters, e.g. carriage return that you can get when calling charInfo in Notepad at the end of a line (except last line)
• Character with no CLDR information, e.g. "s"
• Character with Unicode information in English but not in other languages; I have not yet found one (even if I recall having seen it in the past), but looking in NVDASources\nvda-cldr\locale, we can see that not all languages have the same number of rows.

At last, regarding Microsoft proprietary character set, the related information is now in a specific section table with its own heading so there is no more rows that can appear or not depending on the character.

[lukaszgo1]

Given the above I see two possibilities:

• Replace the question mark with something more complete e.g.e a word "missing". While it is longer it is also self explanatory.
• Document the meaning of the question mark being displayed in the table.