On 02/22/2016 01:05 AM, Paul Eggert wrote:
This one will require a bit more thinking.
The original design goal was to run 'tzselect' on a traditional 24x80 alphanumeric screen. It was important to keep the commentary short, so as to not overrun the columns. Switching to a more-consistent layout convention would probably make us go over the limit.
It doesn't, see below.
In this way of selection, it's more important for the alternatives to be easy to understand, than for them to be consistent. Of course consistency and ease of understanding often go hand in hand, but not always.
Perhaps you have a different selector in mind, and in that case we might need to consider having a portable scheme that will work with both kinds of selectors (albeit perhaps not as nicely as a scheme tailored for your particular selector). Am I right in my guess?
Hello Paul, You are correct that I have written a tzselect style application using a 'dialog' UI. However, my submission is not tailored to it. I need both versions to work well. Besides, I would not knowingly make a submission to benefit my needs at the detriment of a project. The reasons I stated, and the examples given, are the true motivation of the patch. Using the same format to represent different data types makes it impossible to reliably interpret the information. Throughout development I have been extensively testing and comparing both tzselect applications, which is how the bugs in the reference implementation were discovered. String length has been taken into consideration in defining the zone table comment standard format. The only part of the definition that has significant impact on length is: * Use full words in favor of abbreviations. It is intentionally worded to not exclude the use of abbreviations. As it turns out, no abbreviations were need to prevent (any further) breaking of 80 columns (the current comments are already broken). So lets evaluate the impact of the zone table comments on the shell 'select' function. First lets define the scope of the discussion as limited to the third round of tzselect input, choosing a local region, using the zone1970.tab file. There are only two countries with more than 24 local regions which could use a two column select menu: US and CA with 29 and 28 regions respectively. To insure two column capability the strings must be limited to 35 characters. For single column menus the string max is 76 characters. The current zone table comments for US and CA far exceed the ability to use a two column select menu. Using the standard format decreases the longest string for US and stays the same for CA: US: current longest comment 71 characters, patched 61 CA: current longest comment 75 characters, patched 75 The longest comment in the zone1970.tab file is for MX Durango: current 84 patched 79 The patch reduces MX Durango's length, but still exceeds the 76 character limit. This is the contents fault, not the format. Addressing the length issues is on my todo list, but that needs to be a separate submission. Summery: most of the comments require a limit of 76 character, the two exceptions, US and CA, far exceed the 35 character limit to facilitate two columns. In other words, unless there are drastic changes in the content of the US and CA comments, then all comment strings have a 76 character max. Both with and without this patch there is only one comment in violation, MX Durango. PATCH COMMENT LENGTH STATS 149 (74%) reduced or unchanged 41 (20%) less than 5 character increase 11 (05%) less than 18 character increase Attached is a head to head comparison of the current zone1979.tab comments and the patched versions.