Allow to truncate header separators to 79 columns of dashes?

[ecm-pushbx]

Contributing.md says that the header is started and ended by lines with 80 dashes each. To appease 80-column-wide terminals we may want to only include 79 dashes instead. I don't know whether makelist would currently accept that variation in the format.

[shidel]

It will still recognize the header start and end with only 79 characters.

TheList/utilities/makelist/makelist.lpr

Line 933 in 1f118a9

HeaderBar:=StringOf('-', 70);

Because sometimes us humans cannot seem to count, it looks for 70+ characters to find the bounds of the header.

So, we could truncate them to that length. But, do we need to? Those headers are only in the source files for the list. I think most contributors will be editing them in a desktop editor or viewing them in a Linux terminal of some unknown width.

[andrewbird]

what goes in the last column that makes 80 dashes inappropriate?

[shidel]

what goes in the last column that makes 80 dashes inappropriate?

In the files, the header starts with a line of 80 - characters followed by a CRLF. If the terminal is 80 characters wide, it will print the last - and wrap to the next line. Then print a CRLF and move to the next line again. So, each bar can be displayed with a double CRLF after the header bar.

[shidel]

@ecm-pushbx Although it will detect the header at 70+ characters (because people cannot count), the current spec is 80.

But if you like, you can change the spec in the Contributing.md file to 79 characters. Or, possible to something like "a single line containing only - in a consecutive sequence of 75 or more"

[ecm-pushbx]

what goes in the last column that makes 80 dashes inappropriate?

In the files, the header starts with a line of 80 - characters followed by a CRLF. If the terminal is 80 characters wide, it will print the last - and wrap to the next line. Then print a CRLF and move to the next line again. So, each bar can be displayed with a double CRLF after the header bar.

Exactly what I had in mind.

So, we could truncate them to that length. But, do we need to? Those headers are only in the source files for the list. I think most contributors will be editing them in a desktop editor or viewing them in a Linux terminal of some unknown width.

I don't see the harm in changing it this way, except that conversion now so all files use <= 79 columns would require a massive commit touching every source file.

[shidel]

I don't see the harm in changing it this way, except that conversion now so all files use <= 79 columns would require a massive commit touching every source file.

That is only 11,408 files at the moment. :-)

Seriously though, if you want to do that, I am okay with it.

However, If you are going to do that, I will hold off on any more updates until you are finished. That way there are no merge conflicts.

Also, if you want to convert Notes: to Note: and BUGS: to BUG: as mentioned in another thread, this would be the time to make that change.

:-)

[ecm-pushbx]

I actually wanted to go all plural for Notes and BUGS. Are you fine with that too?

[ecm-pushbx]

Also, if you want to convert Notes: to Note: and BUGS: to BUG: as mentioned in another thread, this would be the time to make that change.

Reference: #70 (comment)

[shidel]

Also, if you want to convert Notes: to Note: and BUGS: to BUG: as mentioned in another thread, this would be the time to make that change.

Reference: #70 (comment)

That is fine. Singular or Plural doesn't really matter to me. I just don't think we need two different ones for each.

[ecm-pushbx]

I ultimately went with 76 dashes in #78 as a sort of compromise. That leaves some breathing room for any 80-column terminals. I specified the separator lines as >= 75 dashes in #79 (yet to be merged).