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.
We fix more markdown links in markdown files that refer to files
internally to the web site.
Added tmp tools to find and print various markdown links:
* `tmp/md-links.sh` - print all markdown links
* `tmp/md-token-links.sh` - print all markdown links that start with a **%%TOKEN%%**
* `tmp/md-local-links.sh` - print all markdown links to a local file
* `tmp/md-link-paths.sh` - print local file paths referenced in markdown links
Fixed a number of markdown formatting problems with `thanks-for-help.md`.
Fixed markdown links to files in `thanks-for-help.md`. Improved
heading levels in `thanks-for-help.md`, and made entry sections consistent.
Changed all markdown links that end in "))" to end in a better way.
Explained in `markdown.md` why we are avoiding markdown links that
end in "))".
Ran `make www` to perform the above.
TODO: Fix stuff we broke by mistake doing the above.
TODO: Fix more broken markdown links.
Fixed internal URLs in `1992/buzzard.1/index.html`
Also fixed an internal URL in `1992/buzzard.2/buzzard.2.README.md`.
Ran `bin/readme2index.sh -v 1 1992/buzzard.1` and
`make gen_other_html` to perform the above.
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.
The script had "s surrounding the git ls-files command which turned it
to a single file which of course is wrong.
Ran script again fixing many README.md files that had incorrect number
of blank lines for critical headers.
This will have to be done a final but a good number of files have been
corrected.
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.
Fixed cases where there was a bad trailing backslash.
Improved a few cases where a code block was needed
to highlight some text.
Changed a few cases where a code block needed to
declared as, say, a sh code block.
Fixed a few cases where the winner information was not properly formatted.
Plus a few nits and clarifying text was added.
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.
The use of the markdown trailing whitespace to indicate
line break should NOT be done when the following line is empty.
This removes such improper use of whitespace in README.md files.
Format and typo fixes. Starting with this year I actually did more
thorough typo fixes. It might be that I did some of this in earlier
years too but I am sure I did it for this year and beyond (at least up
through 1995 .. not sure about years beyond that that I have also
edited). Even so I'll probably want to do another pass through all files
before I can say that the typo issue is resolved. That includes possibly
other files and the worst of all files in my entries.
There were many many README.md files with the wrong heading level for
different sections. These have been changed.
To help go through the changes it should be noted I used sgit and also
here is what is changed:
The 'Try', 'To build' and 'To run' lines have two '#'s. Some had one and
others had three.
An exception is that in 1984/anonymous/README.md for the alternative
code that had three '#'s. This is not consistent yet and it might be
that only two are desired. But for now that one at least has three.
This includes removing a statement that this could not compile under
macOS. I'm not sure what happened but I suspect it was the wrong data
file perhaps one of the files left by the script. Either way it does
work with macOS.
Fixed formatting as well.
With the exception of lmfjyh which relies on a bug in gcc (that was
fixed in gcc 2.3.3) we have got all 1993 entries to compile under linux.
A couple will not compile under macOS and this is because gcc under
macOS is actually clang despite what many might have you believe (see
below) which is more strict about the second and third arguments of
main().
In a couple entries we used patches from Yusuke Endoh. Thank you Yusuke!
In others we (that is I aka Cody / @xexyl) fixed them (myself). There
was a question to be answered about whether to add #include lines to the
files themselves or add -includes to the Makefile. Since there are
pending changes to the Makefiles which will affect the CFLAGS (and
there's no CINCLUDE variable in these Makefiles yet) we opted for
updating the source files themselves.
One more note about the Makefiles: the 1993/Makefile was modified but I
added an XXX note to it to indicate that it should be fixed once the
other Makefiles are fixed. Specifically it now allows from 1993 one
to run `make' and compile the entries. The comment has what it used to
read and should be but for now is not because of a problem in the other
Makefiles.
As far as gcc under macOS as you can see it is not actually gcc but
clang:
$ /usr/bin/gcc -v 2>&1|head -n 1
Apple clang version 14.0.0 (clang-1400.0.29.202)
If you were to use clang -v under linux you might see something like:
$ clang -v 2>&1|head -n 1
clang version 15.0.7 (Fedora 15.0.7-1.fc37)
and with gcc:
$ gcc --version |head -n 1
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
If you do by chance have gcc compiled and installed under macOS these
entries will probably work there.
There is one exception:
$ find . -name '*.hint' -execdir git mv '{}' README.md \;
git statufatal: destination exists, source=1992/albert/albert.hint, destination=1992/albert/README.md
Looking at the two files they differ quite a bit so I've not changed it.
I'll bring this up on GitHub.
Cody Boone Ferguson