Teletype docs enhancements (redesign in progress)


I’m with @scanner_darkly on this liking the horizontal and vertical lines. Could you output a version with both?

Also agree with @Leverkusen about font size on variation 3 and 4 - too small for me.


Here you go @unity2k: vertical lines and underlines for the headers: cheatsheet.pdf (63.7 KB)

I haven’t expended much energy trying to get the line thickness to match. It’s not my favourite as I find it a bit too fussy. But if there is a lot of interest I can start fiddling with line widths and lengths.

The fonts in variation 4 are the same as in 1 and 2 (size and typeface).

@scanner_darkly 2 versions is doable, but I’d rather avoid it. I suspect once the turtle and timeline OPs are added the amount of white space will decrease. Also the JF OPs really need splitting into short and long descriptions which will give you more space for non-core OPs.

Also, it’s pretty easy to build your own without page breaks, or page breaks in different places (or different fonts, etc) if you’ve got Python 3.6 and Latex (either TexLive/MacTex/MikTex) installed.



I also meant to ask why some of the entries have commands or symbols right justified such as PRM?

Please keep in mind that my comments/questions at this time are based on nothing more than observations as I just put my order in for a Teletype this past week. So many PRM over there makes sense to everyone else.


Here you go @unity2k: vertical lines and underlines for the headers: cheatsheet.pdf2 (63.7 KB)

This is my favorite one by now!



The right-justified entries are aliases for the commands. They are shorter, valid ways to type the same commands in a slightly less readable manner.


Great work here. Can’t wait to see 2.1’s bevy of new operators and mods :+1:


@sam newest version has my vote.

I am confused as to why the second page has about 1 full column and 4 empty ones, and the last page has all 5 columns, but they are all short.

The behavior of filling up a column before starting another would be my preference, as I feel like the pattern is more scalable. My thinking is around there being just a small out of overflow onto a page…could possibly be weird to have the columns be really short at the top due to dispersing the content.


PR opened


I will try to get the behaviour consistent, no promises as to which “consistent” we get. A lot of it comes down to the foibles of the multicol Latex package, which I don’t have that much control over.

Sounds line column dividers and heading underlines is what everyone wants. I’ll have a bit more of a fiddle with line widths and lengths.


Here we go then. Fixed the columns on the last page, the downside with how it’s done is that we end up with dividers even when there is no content.

The heading underlines and column dividers both have the same thickness now, 0.2pt. You might not see how thin they are without a 4K/Retina display. I’m going to print a page out later this afternoon to check it works on paper.

cheatsheet.pdf (63.2 KB)


I’ll look at it as space for notes :slight_smile:


As always, what a spectacular contribution, @sam. Thanks for all that you do for the TT!!


I just printed out the first page. Looks great.

I’ll aim to get the PR in later this week.

Should we cut a new release (2.0.2) for it? Or I could just re-upload the 2.0.1 release with the cheat sheet added in?

@sliderule is that going to mess with your plans to get 2.1 out?


2.1 is ready. I set a hard release date, but I can PR right now if we want to get the ball rolling.


Are you able to build the docs yet? If so we could just roll the cheatsheet into your release.


@sam the lines are not a bother in my mind.

I’m excited to take a look at the pr when it’s up. After it’s merged and everything is finalized, I’d be happy to figure out the particular config to generate an 8.5x11 inch letter size and get both that and the A4 for @tehn to put as downloads on the site (unless you have another idea there)


I can build them, but I still get the table-too-wide bug. This might build fine.

If you want, open a PR against my master branch and I’ll give it a shot. (It will let me see that side of the PR process as well.)


o, and @sliderule @sam as far as getting a version number in the docs (both standard and this cheat sheet). Do we want to have that done for 2.1.0/after as a PR to the master branch/? I’d be happy to look at opening a PR for that, just trying to figure out the right time to try and tackle (assuming after the cheatsheet PR is in so I can add the version to both).


i can make the sheets available on the docs site prior to a PR.

is this one final? would be good to version the filename, and also possibly print a version in the file itself (but that can come later)


What is the date?

I can PR against your repo, but that means it stops being your ‘private’ repo on the internet, and it becomes one which you must not rebase or otherwise force push. At least until my PR has been merged. Ready for that?

How bad does the A4 version print on US letter?

What I would like to have is a single text file (either /version.txt or /src/version.txt) that contains the current release version. And then for each build system to include that however it sees fit. You can tackle this if you want to, but you’ll need to wrangle with /module/Makefile and /module/gitversion.c (autogenerated by the Makefile) to get it working for the firmware side of things. If you’re happy with that feel free to take it off my hands.

Otherwise I will try to do it either after @sliderule’s PR has landed, or as a PR against his branch.

The root Makefile has a rather handy target for building a release zip file, adding version names might complicated that. But we should be able to get the version in all the docs, either from @jlmitch5 or from myself.

I’ll have more time to work on this on Wednesday or Thursday. I’d like to open a PR up (wherever that is) then.