Enhancement: Fix typos

[lcn2]

Scope - About this issue

Fix typos in "judges remarks / winner writeup / winner's remarks".

Fix typos in Makefiles.

Fix typos in rules and guidelines for a given year.

Typos include spelling and grammar.

NOTE: This writeup is subject to changes and revisions as the understanding of this issue evolves / improves. Check back to this note from time to time. When modification are made to this comment, we will try to add a note indicating that the scope of this issue has been updated.

Rules and guidelines

To preserve the rules, when a typo is fixed in a rules file, the original rules should be copied into orig.rules. This helps preserve the historic record.

To preserve the guidelines, when a typo is fixed in a guidelines file, the original rules should be copied into orig.guidelines. This helps preserve the historic record.

In some cases rules and guidelines had intentional "bugs". Some of those "bugs" may be in the form of a typo. As such this should NOT be fixed. When in doubt, ask an IOCCC judge.

Language

The spelling and grammar of text written by an IOCCC judge should be in "US English".

The spelling and grammar of winner, however, may differ depending on the origin of the winner.

Edit with some judgment in mind. :-)

Other files

Typos in other webs site files are in scope. Nevertheless, one should NOT edit typos in source code. Such types are "features, not bugs". :-)

[xexyl]

This is not a typo per se but I will fix it once I have the files that are modified committed. It would be annoying to figure out which ones to commit and which ones to not. Using git stash prior to fixing it and then doing git stash pop after a commit would possibly cause conflicts so I don't want to do that either.

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Of course the README files should match the Makefiles as well which I'll check at this point too. These are of course in earlier years so it won't interfere with the Makefiles you're working on. Still it might be a bit of time (some days) before I can do this.

With that I'm off to do other things for the rest of the day. Good day!

[lcn2]

Low priority question

In the FAQ you have:

1988/phillipps
Unbeaten for 12 years and counting...

Should the number of years be updated by now ? :-)

The "Unbeaten for 12 years and counting.." like should probably be removed as it may no longer apply.

[lcn2]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f43e94fc5494c6c2a05d34cb68d4ee91937 for this fix.

[xexyl]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f4 for this fix.

QUESTION

Oh thank you for that. Did you use sgit ? :-)

UPDATE 0

Actually that reminds me it needs a man page eventually ...

[xexyl]

Low priority question

In the FAQ you have:

1988/phillipps
Unbeaten for 12 years and counting...

Should the number of years be updated by now ? :-)

The "Unbeaten for 12 years and counting.." like should probably be removed as it may no longer apply.

See commit d582bb10aa0997aee0cb7fade13b18a4160b8727.

[xexyl]

Guess what I found ?

The newsgroup posting (well archive) of the first year! I'll add that to the README. This is from the FAQ. Well okay I'll add it once I have an idea how to display it. This might be something like perfectionism but in the sense of writing. I have a need for consistency (generally speaking) and a general layout (ironically this includes even for the IOCCC website :-) which might be a mistake or it might not be :-) ).

The diff that is very problematic:

diff --git i/1984/README.md w/1984/README.md
index f0277d63129983b00bfceb7032d0298602947ba0..8e2795b9bc1c8e251db1486f5ca208fbc99f7389 100644
--- i/1984/README.md
+++ w/1984/README.md
@@ -5,13 +5,14 @@ In 1984, the first contest was held.  The name of the contest was simply
 Look at the README.md file for the given winner for information
 on how to compile the winner and how to run the winning program.
 Look at the winning source and try to figure how it does what it does!
 You may then wish to look at the Author's comments for even more details.

-Restrictions against machine dependent code were not in the rules in 1984.
+Restrictions against machine dependent code were not in the [rules](rules.txt) in 1984.
 The source file size restriction was only 512 bytes.  Rules and results
-were posted to net.lang.c and net.unix-wizards.
+were posted to
+[net.lang.c](https://groups.google.com/g/net.lang.c/c/QYvDIZZgXp4/m/ZFCDmGm56XQJ) and net.unix-wizards.

Why is it problematic? Because it doesn't leave any room for the rules too which is an earlier post. If we could only find the link to one newsgroup (which might be true) then we might do the first rules as rules.txt (as I did) and then the second reference to Rules and results both being a different link to net.lang.c but what the text saying net.lang.c itself? What goes there? Yeah it's definitely my need for conciseness and preciseness[0] that's a problem.

[0] I hope you noticed the joke there. If you didn't: I am precise yes but far from concise .. generally speaking :-) I mean I can be at times but I am generally very very thorough .. often too thorough though to be fair to me a lot of what I do does need thoroughness. Still conciseness and I don't see eye to eye.

[xexyl]

QUESTION - is this a typo ?

Noticed something in the FAQ:

P.S. Part of the inspiration for making the IOCCC a contest goes to the Bulwer-Lytton fiction contest.

P^2.S. See the overall README for more details.

... specifically the P^2.S. part.

I can see how it might be intentional but I can equally see it as a typo. Should it be changed to e.g. P.S.2 or maybe better P.S.S. or better PSS ?

Btw you know the contest that you were inspired by to start this contest (which I only know about because of the FAQ .. years ago though)? Here's the 2022 grand prize. I think it's hilarious.

[lcn2]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f4 for this fix.

QUESTION

Oh thank you for that. Did you use sgit ? :-)

UPDATE 0

Actually that reminds me it needs a man page eventually ...

Not this time, sorry (tm Canada 🇨🇦)

[lcn2]

QUESTION - is this a typo ?

Noticed something in the FAQ:

P.S. Part of the inspiration for making the IOCCC a contest goes to the Bulwer-Lytton fiction contest.

P^2.S. See the overall README for more details.

... specifically the P^2.S. part.

I can see how it might be intentional but I can equally see it as a typo. Should it be changed to e.g. P.S.2 or maybe better P.S.S. or better PSS ?

Btw you know the contest that you were inspired by to start this contest (which I only know about because of the FAQ .. years ago though)? Here's the 2022 grand prize. I think it's hilarious.

P.P.S is a Post P.S. or Post Post Script : a Post Script after the Post script.

So "P.P." can be written as "P^2", so "P.P.S." can be written as "P^2.S.". So no, "P^2.S." is not a typo 🙂

P^3.S. It gets more obvious when you extend the number of P's

P^4.S. There is a practical limit to the power of P 😃

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something important or something else needs to be clarified, please ask again.

We are going to try and focus on critical path tasks now and return to addressing comments after we make useful progress on such tasks.

[xexyl]

QUESTION - is this a typo ?

Noticed something in the FAQ:

P.S. Part of the inspiration for making the IOCCC a contest goes to the Bulwer-Lytton fiction contest.

P^2.S. See the overall README for more details.

... specifically the P^2.S. part. I can see how it might be intentional but I can equally see it as a typo. Should it be changed to e.g. P.S.2 or maybe better P.S.S. or better PSS ? Btw you know the contest that you were inspired by to start this contest (which I only know about because of the FAQ .. years ago though)? Here's the 2022 grand prize. I think it's hilarious.

P.P.S is a Post P.S. or Post Post Script : a Post Script after the Post script.

You're right. That's what happens when you're dead tired. :-)

So "P.P." can be written as "P^2", so "P.P.S." can be written as "P^2.S.". So no, "P^2.S." is not a typo 🙂

I thought it was something like this. Thanks for confirming!

P^3.S. It gets more obvious when you extend the number of P's

I wouldn't have thought so actually.

P^4.S. There is a practical limit to the power of P 😃

In what way is it a practical limit ?

[xexyl]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f4 for this fix.

QUESTION

Oh thank you for that. Did you use sgit ? :-)

UPDATE 0

Actually that reminds me it needs a man page eventually ...

Not this time, sorry (tm Canada 🇨🇦)

Thanks for answering. But that's kind of silly of you :-) I mean it makes it so much simpler and easier.

But of course it's fine. Out of curiosity how did you do it? find and -execdir with sed or something else ? I figure I should ask as there's a chance I might learn something I didn't know or you had a way I've never thought of.

[lcn2]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f4 for this fix.

QUESTION

Oh thank you for that. Did you use sgit ? :-)

UPDATE 0

Actually that reminds me it needs a man page eventually ...

Not this time, sorry (tm Canada 🇨🇦)

Thanks for answering. But that's kind of silly of you :-) I mean it makes it so much simpler and easier.

But of course it's fine. Out of curiosity how did you do it? find and -execdir with sed or something else ? I figure I should ask as there's a chance I might learn something I didn't know or you had a way I've never thought of.

A vim of the command line that includes a grep -l and stuff if we recall correctly.

[lcn2]

In what way is it a practical limit ?

Too deep becomes excessive and silly

[xexyl]

In what way is it a practical limit ?

Too deep becomes excessive and silly

Ah yes .. and also not helpful with the original document / whatever I'd imagine.

[xexyl]

However I will mention it here. It's actually two things. One is consistency in wording and another is changing a word to another. It's very subtle but I believe it would be better to word

NOTE: This entry may not compile when using modern compilers.

as rather

NOTE: This entry might not compile when using modern compilers.

Why? Because may not can also be meant for permission. It's not really any different in meaning but it might be slightly clearer. As well some have a different wording like:

NOTE: The original source may not compile using modern compilers.

Thanks. See commit b2105f4 for this fix.

QUESTION

Oh thank you for that. Did you use sgit ? :-)

UPDATE 0

Actually that reminds me it needs a man page eventually ...

Not this time, sorry (tm Canada 🇨🇦)

Thanks for answering. But that's kind of silly of you :-) I mean it makes it so much simpler and easier. But of course it's fine. Out of curiosity how did you do it? find and -execdir with sed or something else ? I figure I should ask as there's a chance I might learn something I didn't know or you had a way I've never thought of.

A vim of the command line that includes a grep -l and stuff if we recall correctly.

Well grep -l shows files with matches of course. I wish you remembered what you did. It sounds interesting! Maybe the fact you can run commands when opening vim? I mean vim commands as you open the files.

[xexyl]

QUESTION about 1990/pjr

In the README you have:

Note that some compilers will be unable to compile the expression 'X=g()...' in main due to lack of temporary value space. One might want to try replacing main with:

    main(){X=s().v().o().o().l().S().d().l().i().o().w().N();}

...but is 'value space' supposed to be something else like variable space? I can see how value space might be correct but I want to be sure.

And I really am off to do other things for the rest of the day. I hope to return to this repo tomorrow now that the jparse prefix situation is resolved.

[xexyl]

QUESTION

Another question for now .. then I'm getting up to do other things!

I see in the shell entry of 1990 the following remarks from the judges:

This program implements a subject as well known Un*x utility whose original source was considered to be extremely obfuscated by many people, excluding its author. In fact, this utility was a major inspiration for the formation of this contest.

but the first sentence reads funny. What exactly were you trying to say? I can take some guesses but I'd rather be right when fixing it.

Back tomorrow I hope!

[lcn2]

QUESTION

Another question for now .. then I'm getting up to do other things!

I see in the shell entry of 1990 the following remarks from the judges:

This program implements a subject as well known Un*x utility whose original source was considered to be extremely obfuscated by many people, excluding its author. In fact, this utility was a major inspiration for the formation of this contest.

but the first sentence reads funny. What exactly were you trying to say? I can take some guesses but I'd rather be right when fixing it.

Back tomorrow I hope!

The reference is the the source of the Bourne Shell (/bin/sh) source. Moreover the Bourne Shell source (being bug fixed by Larry Base;, IOCCC co-founder) and the finger daemon (fingerd) source (being bug fixed my Landon) was the original information for the IOCCC. In this case "Un*x" was a codeword for "Unix" when there was a big issue over IP rights related to Unix vs. Open Source. The "well know Unix utility" was Bourne Shell (/bin/sh) source.

A rewrite might be:

This program touches on a well known Unix utility, the 6th edition Bourne Shell (`/bin/sh`), whose
original source was considered to be extremely obfuscated by many people (although Steve Bourne might disagree). Did you know that the Bourne Shell source was a major inspiration for the formation of the IOCCC back in 1984?

[xexyl]

QUESTION

Another question for now .. then I'm getting up to do other things! I see in the shell entry of 1990 the following remarks from the judges:

This program implements a subject as well known Un*x utility whose original source was considered to be extremely obfuscated by many people, excluding its author. In fact, this utility was a major inspiration for the formation of this contest.

but the first sentence reads funny. What exactly were you trying to say? I can take some guesses but I'd rather be right when fixing it. Back tomorrow I hope!

The reference is the the source of the Bourne Shell (/bin/sh) source. Moreover the Bourne Shell source (being bug fixed by Larry Base;, IOCCC co-founder) and the finger daemon (fingerd) source (being bug fixed my Landon) was the original information for the IOCCC. In this case "Un*x" was a codeword for "Unix" when there was a big issue over IP rights related to Unix vs. Open Source. The "well know Unix utility" was Bourne Shell (/bin/sh) source.

I didn't know he did that. That's cool! That's also cool that you fixed a bug (or maybe bugs?) in fingerd. Is this the discussion you had back then about the formation of the contest? I mean was it these issues you were discussing in particular?

The Un*x being useful in that way has been a problem with markdown files actually. I've been changing it to have the grave accents / backquotes so that it doesn't trigger italics. Sometimes I have thought of changing it to just be Unix since it's no longer a problem but I think so far I've just changed it to

`Un\*x`

instead.

A rewrite might be:

This program touches on a well known Unix utility, the 6th edition Bourne Shell (`/bin/sh`), whose
original source was considered to be extremely obfuscated by many people (although Steve Bourne might disagree). Did you know that the Bourne Shell source was a major inspiration for the formation of the IOCCC back in 1984?

Thanks! I knew it was referring to the Bourne shell and I know it was an inspiration of the contest (along with fingerd) but I wasn't sure exactly what you were trying to say. I'll do this sometime in the coming days.

UPDATE 0

Fixed formatting and discovered a weird problem: trying to fix formatting a strange thing is \\

`\`

didn't work for escaping the grave accent and <pre>..</pre> didn't work either so I put it in a code block instead. Well I always got the feeling that markdown is kind of finicky.

[lcn2]

QUESTION about 1990/pjr

In the README you have:

Note that some compilers will be unable to compile the expression 'X=g()...' in main due to lack of temporary value space. One might want to try replacing main with:

    main(){X=s().v().o().o().l().S().d().l().i().o().w().N();}

...but is 'value space' supposed to be something else like variable space? I can see how value space might be correct but I want to be sure.

And I really am off to do other things for the rest of the day. I hope to return to this repo tomorrow now that the jparse prefix situation is resolved.

While we didn't write this text, we guess that the word "value" can be replaced with "stack variable".

[xexyl]

QUESTION about 1990/pjr

In the README you have:

Note that some compilers will be unable to compile the expression 'X=g()...' in main due to lack of temporary value space. One might want to try replacing main with:

    main(){X=s().v().o().o().l().S().d().l().i().o().w().N();}

...but is 'value space' supposed to be something else like variable space? I can see how value space might be correct but I want to be sure. And I really am off to do other things for the rest of the day. I hope to return to this repo tomorrow now that the jparse prefix situation is resolved.

While we didn't write this text, we guess that the word "value" can be replaced with "stack variable".

Actually you did write it: it's in the judges' comments section.

I guess you mean value space can be replaced with stack variable but I think better would be stack space so I'll do that (done actually but not yet committed .. need to address other things first including other comments). Thanks for your feedback here!

[lcn2]

QUESTION about 1990/pjr

In the README you have:

Note that some compilers will be unable to compile the

expression 'X=g()...' in main due to lack of temporary

value space. One might want to try replacing main with:

    main(){X=s().v().o().o().l().S().d().l().i().o().w().N();}

...but is 'value space' supposed to be something else like variable space? I can see how value space might be correct but I want to be sure.

And I really am off to do other things for the rest of the day. I hope to return to this repo tomorrow now that the jparse prefix situation is resolved.

While we didn't write this text, we guess that the word "value" can be replaced with "stack variable".

Actually you did write it: it's in the judges' comments section.

I guess you mean value space can be replaced with stack variable but I think better would be stack space so I'll do that (done actually but not yet committed .. need to address other things first including other comments). Thanks for your feedback here!

The term "stack space" is fine too.

[xexyl]

While we didn't write this text, we guess that the word "value" can be replaced with "stack variable".

Actually you did write it: it's in the judges' comments section. I guess you mean value space can be replaced with stack variable but I think better would be stack space so I'll do that (done actually but not yet committed .. need to address other things first including other comments). Thanks for your feedback here!

The term "stack space" is fine too.

Thanks!

[lcn2]

We believe that, before we go further offline, we have addressed all questions and issues above.

Thank you @xexyl for applying your talents to find and fix typos!

[xexyl]

We believe that, before we go further offline, we have addressed all questions and issues above.

Thank you @xexyl for applying your talents to find and fix typos!

Thank you as well for acknowledging that and being appreciative!

Have a safe and fun time! I'm off until tomorrow for real now.

[lcn2]

We believe that we have addressed all open issues and questions above. Anything we missed should be re-asked below.

[xexyl]

LOW PRIO QUESTION - 2006/toledo1

Is this a typo? If so what is it meant to say? I don't have a clue in this case.

It will print move order. The algorithm is so simple that you can read
it in the source code, at the first glance it can appear checkered :-)
but don't dismail, jar, jar.

Specifically 'dismail'. The 'jar, jar' does not help me decipher it either. The only thing I can think of is 'dismal' but that can't be it can it?

[lcn2]

LOW PRIO QUESTION - 2006/toledo1

Is this a typo? If so what is it meant to say? I don't have a clue in this case.

It will print move order. The algorithm is so simple that you can read
it in the source code, at the first glance it can appear checkered :-)
but don't dismail, jar, jar.

Specifically 'dismail'. The 'jar, jar' does not help me decipher it either. The only thing I can think of is 'dismal' but that can't be it can it?

It was written by a judge whose 1st language was not english.

Perhaps this is a better text set:

It will print move order. The algorithm is so simple that you can read
it on the source code.  At the first glance it can appear checkered.
Nevertheless, don't be dismayed, jar, jar.  :-)

[lcn2]

We believe that we have addressed all open issues and questions above. Anything we missed should be re-asked below.

[lcn2]

QUESTION

How close are we to finishing this issue?

There are probably always going to typos. Closing this issue does not mean more typos won't be found. When they do after this issue closes, a pull request can always be made to fix.

Are there areas of the tree that need a typo fix pass? If so, please setup a TODO list. If we are ready to close this issue, please so advise.

[xexyl]

LOW PRIO QUESTION - 2006/toledo1

Is this a typo? If so what is it meant to say? I don't have a clue in this case.

It will print move order. The algorithm is so simple that you can read
it in the source code, at the first glance it can appear checkered :-)
but don't dismail, jar, jar.

Specifically 'dismail'. The 'jar, jar' does not help me decipher it either. The only thing I can think of is 'dismal' but that can't be it can it?

It was written by a judge whose 1st language was not english.

Perhaps this is a better text set:

It will print move order. The algorithm is so simple that you can read
it on the source code.  At the first glance it can appear checkered.
Nevertheless, don't be dismayed, jar, jar.  :-)

Done.

[xexyl]

QUESTION

How close are we to finishing this issue?

There are probably always going to typos. Closing this issue does not mean more typos won't be found. When they do after this issue closes, a pull request can always be made to fix.

Are there areas of the tree that need a typo fix pass? If so, please setup a TODO list. If we are ready to close this issue, please so advise.

Okay this is actually one I have a mental record of. I should go through all the README.md files up through the ones I have not checked yet. That could go quickly and I could probably finish it in one day. I don't think that can happen today but it can happen maybe Sunday - if not tomorrow before my cousin arrives.

But then a useful question to ask: the other issue, issue #3, could be considered a part of this one once the files I checked are rechecked. When I do the fixes to the README.md files (all of which have to be rechecked though some will go quickly) I can fix any typos.

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

[lcn2]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

[xexyl]

As far as typos / consistences go: I have finished 1984 and since I don't think anything else can be added to that year I think we're probably good there. I obviously have many more years to go but I will follow the order noted above so that everything should be good.

Of course as you say there will probably always be some form of typo or things that could be clearer but it would be nice if we're going through all this effort to get it in the best shape as possible. But then again there comes a point where we want to make it so that we can go on to better things namely the IOCCCMOCK.

[xexyl]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

It certainly would but what about what you suggested in the other issue - going through the files first and then look for README.md files so that one can make sure no additional typos can be added?

Of course I have not many years left to do a first pass of README.md files and so I could do that and then do a quick pass for either typos or formatting. I must say that for the formatting check pass I don't think I'd be changing words / adding things found so it's probably a minor chance that any typos would be introduced.

What do you think ?

[lcn2]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

It certainly would but what about what you suggested in the other issue - going through the files first and then look for README.md files so that one can make sure no additional typos can be added?

Sounds like a good idea to look at the README.md files.

Of course I have not many years left to do a first pass of README.md files and so I could do that and then do a quick pass for either typos or formatting. I must say that for the formatting check pass I don't think I'd be changing words / adding things found so it's probably a minor chance that any typos would be introduced.

What do you think ?

Sound like a good plan.

[xexyl]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

It certainly would but what about what you suggested in the other issue - going through the files first and then look for README.md files so that one can make sure no additional typos can be added?

Of course I have not many years left to do a first pass of README.md files and so I could do that and then do a quick pass for either typos or formatting. I must say that for the formatting check pass I don't think I'd be changing words / adding things found so it's probably a minor chance that any typos would be introduced.

What do you think ?

Sound like a good plan.

Good morning!

So let me make sure that I follow right.

Finish the last few years of README format fixes. Then go through the previously checked ones looking for typos. After that I can then go through them all once more to make sure that formatting is correct? Though it seems kind of wasteful to go through looking for typos and not checking formatting. Might just be more time efficient to do both.

[lcn2]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

It certainly would but what about what you suggested in the other issue - going through the files first and then look for README.md files so that one can make sure no additional typos can be added?

Of course I have not many years left to do a first pass of README.md files and so I could do that and then do a quick pass for either typos or formatting. I must say that for the formatting check pass I don't think I'd be changing words / adding things found so it's probably a minor chance that any typos would be introduced.

What do you think ?

Sound like a good plan.

Good morning!

Good morning but going back to sleep 🛌 after this.

So let me make sure that I follow right.

Finish the last few years of README format fixes. Then go through the previously checked ones looking for typos. After that I can then go through them all once more to make sure that formatting is correct? Though it seems kind of wasteful to go through looking for typos and not checking formatting. Might just be more time efficient to do both.

Doing both seems like a more efficient way to proceed, yes.

[xexyl]

Want me to do this soon (this = go through the files that I have to check again that I have not done any fixes in yet) ?

Sure, as closing this issue would look good to outsiders.

It certainly would but what about what you suggested in the other issue - going through the files first and then look for README.md files so that one can make sure no additional typos can be added? Of course I have not many years left to do a first pass of README.md files and so I could do that and then do a quick pass for either typos or formatting. I must say that for the formatting check pass I don't think I'd be changing words / adding things found so it's probably a minor chance that any typos would be introduced. What do you think ?

Sound like a good plan.

Good morning!

Good morning but going back to sleep 🛌 after this.

Hope you got more sleep! I've been sleeping in most days - just a bit but it's improvement.

So let me make sure that I follow right. Finish the last few years of README format fixes. Then go through the previously checked ones looking for typos. After that I can then go through them all once more to make sure that formatting is correct? Though it seems kind of wasteful to go through looking for typos and not checking formatting. Might just be more time efficient to do both.

Doing both seems like a more efficient way to proceed, yes.

It's how I'm going about it. Unfortunately not sure how long it'll take but I think that once I'm more recovered from Saturday I'll be able to do more as long as I have the time and - and this is a potential issue - I don't run into any questions. I can always not do those entries in question though.

[lcn2]

It's how I'm going about it. Unfortunately not sure how long it'll take but I think that once I'm more recovered from Saturday I'll be able to do more as long as I have the time and - and this is a potential issue - I don't run into any questions. I can always not do those entries in question though.

Best wishes then, and good sleeping 🛌 too.

[lcn2]

Just before sleeping again .. have we generally completed this issue? Certainly new typos can be fixed after closing. Nevertheless have we achieved general success on this issue an ready to close it, @xexyl ?

[xexyl]

Just before sleeping again .. have we generally completed this issue? Certainly new typos can be fixed after closing. Nevertheless have we achieved general success on this issue an ready to close it, @xexyl

No because I have not had a chance to go through all years yet.

I probably would be done but the other repo. Sorry. If you want me to work on this I can.

Which would you prefer?

[lcn2]

Just before sleeping again .. have we generally completed this issue? Certainly new typos can be fixed after closing. Nevertheless have we achieved general success on this issue an ready to close it, @xexyl

No because I have not had a chance to go through all years yet.

I probably would be done but the other repo. Sorry. If you want me to work on this I can.

When we start working on the "JSON tree search functions", we will probably need the mkiocccentry repo somewhat quiescent. That would be a good time to shift focus to this repo. But "JSON tree search functions" work will depend on resolving the questions around JSON level, JSON indenting and JSON formatting resolved first.

Which would you prefer?

Fair points, we can leave this open.

We suggest that you wait until the "JSON tree search functions" before shifting focus to this repo.

Really going back to sleep now. 🛌

[xexyl]

Just before sleeping again .. have we generally completed this issue? Certainly new typos can be fixed after closing. Nevertheless have we achieved general success on this issue an ready to close it, @xexyl

No because I have not had a chance to go through all years yet.

I probably would be done but the other repo. Sorry. If you want me to work on this I can.

When we start working on the "JSON tree search functions", we will probably need the mkiocccentry repo somewhat quiescent. That would be a good time to shift focus to this repo. But "JSON tree search functions" work will depend on resolving the questions around JSON level, JSON indenting and JSON formatting resolved first.

Which would you prefer?

Fair points, we can leave this open.

We suggest that you wait until the "JSON tree search functions" before shifting focus to this repo.

Really going back to sleep now. 🛌

Sure.

Sleep well!

[lcn2]

Status question

What years have been processed and what years still need to be worked over for typos?

We don't ask about every possible typo, there endless supply of them it seems sometimes. :-) We, instead, refer to the entries having had a reasonable scan where most of the more "awful" typos have been addressed, as per the top comment of this issue.

[xexyl]

Status question

What years have been processed and what years still need to be worked over for typos?

We don't ask about every possible typo, there endless supply of them it seems sometimes. :-) We, instead, refer to the entries having had a reasonable scan where most of the more "awful" typos have been addressed, as per the top comment of this issue.

Most years I think have been done but I will do another pass. Some years that I did not have a chance to go through at all yet haven't been checked either. Looking at the todo file it seems that I got to at least 2011 but I dimly recall doing a few more years after that.

Going through the files shouldn't take much time and I intend to do it at the same time as I verify that the formatting is okay. That includes changing spaces at ends of lines (like in author info) to be <br>.

[lcn2]

QUESTION

What years have been completed, and what years need to be finished in terms of fixing typos?

[xexyl]

QUESTION

What years have been completed, and what years need to be finished in terms of fixing typos?

I have to go through 2011+ and then do a final pass through the years.

That pass shouldn't take too much time although I might not do it in one sitting.

[xexyl]

As far as this issue and the consistencies fixes issue I remembered something that has to be done. Or rather something that has to be checked. I have a todo.md file that has things that have to be done. Now some if not most of those are part of checking the README.md and one or two have to do with bugs.md so might not apply to these two issues but they all should still be done.

One in fact is done in a sense but it has to be verified after everything else is done with the fixes in entries (consistencies and typos).

I have some good news too in that I think I can skip some of the years wrt an additional pass: just have a final pass. I did the years 2011 and 2012. In 2013 I did cable1 and birken but it appears that I might not have gone beyond that. I at least did not do cable2. I might have done others but these will be discovered in time.

I made this comment, modified to fit the issue, in the consistencies issue too.

I hope this is helpful and encouraging!

UPDATE 0

BTW: I did remove an entry from the todo.md file today as I actually did the task the other day in commit 4836ed462265105cf380715f674c122ac9b6d99f.