We move `tmp/format-headers.sh` into `bin/format-headers.sh`.
We also add a few missing empty lines to `README.md`.
We add `bin/format-headers.sh` to the `bin/README.md`.
We run `bin/format-headers.sh` to perform the above.
Performed `make www` to accomplish the above and to test under macOS.
Instead of code blocks the bug / (mis)features statuses are quoted
rather than in a code block. In the case that there is more than one a
line break was added at the end of all but the last one.
A bug status was renamed to be slightly more correct (maybe more than
one was renamed for the same purpose but at least one was).
The bug statuses in the quotes are now bold to let them stand out
better.
Given how problematic leading tabs in markdown files can be,
we have expanded all leading tabs in markdown files by:
```sh
find * -type f -name '*.md' -print |
while read -r file; do
rm -f "$file.tmp" ;
expand < "$file" > "$file.tmp" ;
mv -f -v "$file.tmp" "$file" ;
done
```
Given the previous changes to `bin/pandoc-wrapper.sh` and other recent
commits and recent pull requests, the were were **NO** changes to
any HTML files. This is a **good thing** as the expression goes.
No there are no leading tabs in any markdown files.
A check to catch any re-introduction of leading tabs
into any markdown file is on the way.
BTW: We do not have anything against leading tabs in files,
even though we have had to deal with their impact on forming
HTML from markdown files (as well as the calc source code).
It is just that this is one of those cases where tabs conflict
(sometimes caused by people wanting to change the classic
8-space tab model) with a desired outcome.
Perform `make www` to perform the above and test under macOS.
That is to say in the bugs file it will look something like:
STATUS: INABIAF - please DO NOT fix
but as a html file it is already bold as a heading. This means there is
no need in the index.html file to have the explicit **DO NOT** as it's
in a code block and it is not consistent in what is in bugs.html. For
instance 1984/mullender had:
STATUS: INABIAF - please **DO NOT** fix
but this meant the index.html file had the '**'s surrounding the DO NOT
which is not consistent with bugs.html.
While not strictly necessary, replacing the two ASCII tab characters
in the markdown copyright comment makes it easier to detect problematic
TAB indentation within markdown files.
After this commit, only 90 markdown files have leading ASCII TAB
characters. And again, while not strictly necessary, we can consider
running expand on those 90 markdown files to see what effect that
might have on the HTML files they produce.
Replace leading ASCII TAB characters with multiples of 8 ASCII SPACE
characters (the default action of the `expand(1)` tool) might have
an negative effect on some HTML formatting where **hack-a-round**
formatting was attempted to fix broken indentation caused by
problematic ASCII TAB characters.
Think of this as a baseline for evaluating leading
TAB characters within markdown files.
TODO: Consider either using `expand(1)` to replace leading ASCII
TAB characters with multiples of 8 ASCII SPACE characters AND/OR
modifying the appropriate `bin` tool to convert leading ASCII TAB
characters into multiples of 8 ASCII SPACE characters.
The bugs.{md,html} files, 1984/laman/README.md (and index.html) file and
thanks files were updated. The thanks file has some additional fixes
that were already in place but are relevant to this commit.
We added a space between the markdown triple code mark
and language that was enclosed in HTML comments.
So a line of the form:
````
```<!---c--->
````
became:
````
``` <!---c--->
````
This was done to **help** some code see that the HTML comment
string was not a markdown code specifier. Not all code
understands this after this changed. For example, `pandoc(1)`
still forms HTML classes of the form "<!---c-->"
when it encounters the above mentioned change.
We also fixed a problem with `2019/dogon/README.md` regarding
a markdown code block.
We also fixed a problem with `2020/yang/README.md` regarding
a markdown code block.
When language is specified in a markdown code block such as:
````
```c
printf("Hello, world!\n");
```
````
is used, the resulting HTML as produced by `pandoc(1)` combined
with our revised `ioccc.css` is not intent the code block well.
A temporary "_hack-a-round_" is to turn the "markdown code language
specifier" into an HTML comment. For example:
````
```<!---c-->
printf("Hello, world!\n");
```
````
This commits turns off existing markdown code language specifiers
for now, while preserving our ability to restore them in the future
when a better "_hack-a-round_" to the "markdown code language
specifier" problem is found.
The HTML impact if this "_hack-a-round_" is to produce HTML that
looks like this:
```
<pre class="<!---c-->"><code> .. </code></pre>
```
We might be able to create a complex set of classes for each markdown
code language (there won't be very many) in `ioccc.css`, or we might
find a more general CSS (or maybe `pandoc(1)`?) solution.
For now, this hack-a-round will have to do.
All code blocks in markdown have been intended by at least 4 spaces.
We add `--tab-stop=8` to all `pandoc(1)` executions in order to set
a better tab stop indentation, especially for tab intended code blocks.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.5.3 2024-03-26"
to "1.6 2024-03-31".
Fixed `1991/brnstnd/sorta.README.md` so that the sorta code
is code blocks.
Removed unneeded paragraph group in copyright in `inc/footer.default.html`.
Fixed excess whitespace after list Author on entry `index.html` page.
Changed `bin/output-index-author.sh` VERSION from "1.5.2 2024-03-26"
to "1.6 2024-03-31".
Performed `make www` to perform the above and test under macOS.
TODO: Fix the problem of the initial line of code being extra intended.
TODO: Fix excess whitespace around code that is inline.
The inc/footer.default.html now has a common Copyright and CC BY-SA
4.0 License section for all generated HTML files.
All markdown files have a similar Copyright and CC
at the bottom in the form of an HTML comment.
As requested on GitHub: a tool that will be written, readme2index, will,
as explained:
'... will take the converted HTML from the README.md markdown and
inject it into an HTML template. Things such title, award one and
author information will be injected into the HTML page ahead of the
HTML that was converted from the README.md markdown. Without going
into details of HOW at this time, the result will be a coherent HTML
index.html page with the winner title / award, winning author
information, and important file links come from other sources and
NOT from the README.md file.
The text from the 1st award line, thru the authorship information,
and up to but not including the "## To build:" line in the README.md
file will just get in the way. Moreover authors might be tempted to
try and maintain that top of README.md text instead of working with
the author/_author_handle_.json and winner .winner.json files.
This was done with my[0] sgit(1) (https://github.com/xexyl/sgit) tool like:
sgit -o -n -e '/^## To build:/,$p' '[12][0-9][0-9][0-9]/*/README.md'
[0] Is that shameless self-promotion? I don't know but I don't care: it
is generally a very useful tool and has been used in other repos too.
Besides, I've done it many times before and it's a great example that I
will be adding to the README.md file of the tool, one I hadn't thought
of doing.
As the definition of INABIAF changed, again, and since it took no more
than ten seconds to fix, I have fixed this entry.
As the thanks file was updated for this some other things that had been
left out were also fixed at the same time as these were already in the
file but not committed. There was also a typo fix in there.
The entries referenced in `bugs.md` now have, below the
"To build:" section, a "Bugs and (Mis)features section text"
that matches the `bugs.md` status.
Several entries had their "STATUS" changed from:
"STATUS: INABIAF - please **DO NOT** fix" to:
"STATUS: known bug - please help us fix":
This was done because, while some of the bugs were minor,
inviting someone to try and fix the issue does nil harm.
In a few cases a more difficult bug was also changed to
the "please help us fix".
While we do NOT want to waste time fixing such entries NOW,
letting others become involved and to try to fix the entry
is a good thing as to encourages people to study the entry
and try to fix the entry. We don't need to accept a fix
that is offered, and of the fix transforms the source in
a less than desirable way, such a fix (if accepted) could
be become a alt source code.
It turns out that putting a / in a level 2 header
makes it hard to link to in some cases.
So instead of using a level 2 header of the form "year/dir"
we use a level 2 header of the form "year dir".
As the `bugs.md` has grown, the need to link into a specific
section of the `bugs.md` has become apparent. While there
are links the entry's `bugs.md` section, due to the
complexity of a head such as:
the links within the header will make it hard for
markdown to html to form such links.
Instead the level 2 header has been transformed into:
vvvvvvvvvvvvvvvvvvv--- level 2 header below ---vvvvvvvvvvvvvvvvvvv
^^^^^^^^^^^^^^^^^^^--- level 2 header above ---^^^^^^^^^^^^^^^^^^^
We made a test modification to `1984/laman/README.md` to
refer to this section as:
vvvvvvvvvvvvvvvvvvv--- reference to the level 2 header below ---vvvvvvvvvvvvvvvvvvv
The current status of this entry is:
```
STATUS: INABIAF - please **DO NOT** fix
```
For more detailed information see [bugs.md#1984/laman](/bugs.md#1984-laman).
^^^^^^^^^^^^^^^^^^^--- reference to the level 2 header above ---^^^^^^^^^^^^^^^^^^^
One advantage of the above section is that it contains only
a single link into `bugs.md`.
In particular we use the following string as a link into `bugs.md`:
/bugs.md#1984-laman
We plan to verify that this is the proper way to link into `bugs.md`
after we push this commit.
During these edits, we discovered a set of quasi-duplicated
big entries spanning from 1998 thru 2013. We say quasi-duplicated
because the repeated information was not the same.
We made a guess in `bugs.md` as to which parts were correct,
however our guess may have been incorrect. Therefore, we
preserved the two sets in two files.
The 1st set of 1998 thru 2013 is found in: `bugs-1998-2003-parta.md`.
The 2nd set of 1998 thru 2013 is found in: `bugs-1998-2003-partb.md`.
Please inspect the sets, and if needed, update `bugs.md` as needed.
Please remove `bugs-1998-2003-parta.md` and `bugs-1998-2003-partb.md`
when you are done.
As in:
sgit -e 's/# To run/# To use/g' '*README.md'
This makes consistent the message for how to use the program. 'How to
use' was chosen because one can run a program just by doing './foo' but
that doesn't imply that's how to use it but the purpose of the section
is how to use it.
Having to click on the links in each README.md file will have to be done
to verify the links work but it appears to be in the form of:
/bugs.md#YYYYauthor-readmemd
To make sure that this looks okay before doing it for the rest of the
entries I am doing this test commit to make sure the link works okay and
the format looks okay. If any problems are found (which I expect) they
will be corrected and once things look okay the rest of the files will
be done as well.
The judges noted that some new compilers dislike ... but that was a
very long time ago now so I added in parentheses 'in 1984' to be
explicit about it.
This commit includes the two entries not already done (other changes
besides a final typo and formatting pass) in 1984, anonymous and laman.
This commit means that the entries of 1984 have each had their README.md
file formatted and typo fixed one more time and this should be good for
publication.
I paid a lot of attention to 1984/mullender partly because it is one of
Landon's all time favourite entries to this day and partly because it
felt like it was a good idea especially as there is a lot of
instructional value in the author's remarks that I located a while back.
However this did take quite some time so I probably won't do that for
many more entries if any more as it will slow things down tremendously.
There was an unfortunate typo fix in this README.md too: a typo in the
file, possibly a typo from the copy paste (think I copied from an image
but it might have been a pdf too in which case the original person
adding the remarks in the book cited made a typo / copy-pasted the
information from the author), which could cause confusion when reading
the remarks.
The years 1984, 1985 and 1986 have had all winning entry README.md files
updated. This includes formatting, adding author's comments (which in
these years means nothing but still have the section there to indicate
that there were no comments) and possibly other things.
I have updated some - not all - of the 1987 winning entry README.md
files. I have to do other things now but I want these committed. I will
work on the other README.md files another time.
There are many more fixes to be made but I wanted these in. Even the
files I have checked will have to be checked again in more detail but I
needed these committed so I could fix something in another file that
will need a new branch. More updates to README.md files will then be put
into yet another branch if the pull requests have not yet been merged
before I get to these updates (which really ought to be a lot of
fun! :-) )
Landon Curt Noll