Improved first couple of client operations.

Now we check errors sensibly rather than via cavalier .unwrap(); we
cache accounts as well as statuses per id; and we verify the returned
id against the one we asked for (to make it not an obvious attack
avenue to file things under the returned id).

Filled in all the rest of the menus.

Also, the actions that aren't implemented yet are clearly marked with
'NYI', and been if you try to select them.

Enough menu handling to [ESC][X][X]!

Don't let menu items go way over to the right.

The allocation of 3/4 of padding space to the left-hand side is
intended for cases where there isn't room to put the = signs in the
middle. When there is, we should do it.

Forgot trailing '.' on FileStatusLine without proportion.

Begin actually displaying menu options!

Reduce some of the unused-stuff warnings.

Perhaps I should turn all these warnings off until I've actually used
all the unused stuff? I'm sure they're very useful once your program
is supposed to be finished, but while it's still only half-written,
yes I _know_ I haven't got round to using all these fields yet.

Changed my mind about using Box<dyn TextFragment>.

I think it's going to be a better idea to have each user of
TextFragment separately make an enum that permits precisely the kinds
of TextFragment they want. Firstly, this means we can be statically
sure no rogue weird ones got in there by accident; secondly, it
immediately solves all the problems of finding the ones that need
special handling at render time (extensible-file indicators etc).

And thirdly - this is definitely a thing I'm having trouble getting
used to in Rust - if I _do_ need one particular client of TextFragment
to do everything by means of a list of perfectly generic Box<dyn
TextFragment>, I can choose to do it in _that_ client module, and
text.rs doesn't have to lift a finger to support it!

Delete some of my commented-out prototype code.

The new Tui structure now replicates almost all the useful
functionality of that. The only exception is the extra loop where we
re-split each line returned from render() to the screen width, in case
it's overlong. But that can't be centralised into the current code: it
will have to live in the draw() method of ActivityState types that
need it (particularly, those rendering paragraphs), because they'll
need to know when it happened in order to count screen lines
correctly.

Store an OurKey in FileStatusLine and MenuKeypressLine.

Now we have a representation for keystrokes that can trigger actions,
this is the first step towards a DRY representation in which each menu
and status line configures just once the a set of triples (keypress,
help text, action to take).

Not sure what form the 'action' part of that triple will take yet,
though.

Put x first in all coordinate pairs.

This is the universal convention _almost_ everywhere. When writing
actual curses programs I've sometimes reversed it, because curses's
API puts line before column. But (a) ratatui is the sensible way round
in the first place; (b) if my plan in this code is to localise the
curses-type library as hard as possible into one module, then I
wouldn't want to allow its conventions to leak into the rest of the
code _anyway_.

So, here we speak (x,y) like normal people, and since ratatui happens
to be sensible, we do so _everywhere_; if for some reason we had to
work with actual curses, we'd localise the swap to tui.rs.

Make a start on ActivityStates drawing themselves.

This begins to bring the pieces together: our Main Menu now has its
correct header line, although as yet nothing else.

More structure.

Now we hand off to subsidiary traits that can treat menus, files and
editors all differently.

Start of the main TUI code.

So far, I've made a struct that encapsulates the Ratatui state and
some subthread comms machinery, i.e. does the physical work. Then
there's a sub-struct to contain the logical UI state (so it can be
borrowed mutably without having to re-borrow the main struct), which
gets to draw things on the screen, update itself in response to
keypresses, and tell the physical side what to do after the
keypress (options currently limited to 'beep', 'exit', or 'just redraw
and go round the loop again').

Currently the UI itself is just "hello, world". I think menus are
next.

Implement a specialised stack of UI activities.

I think this mostly matches Monochrome's rules about what activities
you can and can't have stacked on top of each other. To wit, you
basically get an arbitrary keypath of menus from the Main Menu, plus
optionally a single utilities-menu thing pushed on top of that.
Utilities things replace each other rather than stacking, so that
popping the stack returns to the non-utility below it.

(An exception on real Monochrome is that popping from Send Message
replaces it with the Users On screen - also a utility-class activity -
rather than popping back to the topmost non-util. Mastodon has no such
thing, so we can omit that special case here. If anything like that
were needed anyway, it could be special-cased inside pop().)

Forgot to wrap overlong lines.

End-to-end PoC: we format and display a sample toot!

Half-arsed attempt to set up a Client type.

It _compiles_, but I'm not at all sure the API is what it ought to be.
Still, I'll press on with it for the moment and figure out how it's
wrong later.

And prime the ExtendableIndicator.

Perhaps we're ready to start on another module now!

MenuKeypressLine

FileStatusLine priority-sensitive rendering.

All right, ColouredString wants an is_empty()

Wait, we can match on strings! Much nicer.

Mass change of .to_string() to .to_owned().

I've just figured out that the former means 'use the Display trait'
whereas the latter means 'change ownership and lifetime'. In the case
of &str, both do what I want, but .to_owned() is a clearer
specification of how _little_ I wanted.

First half of FileStatusLine. Rendering undone.

Changed my mind again about constructor API

Media entries.

UserListEntry, which was easy

Notification log formatting

Re: header.

ExtendableIndicator, without the hard part

Diagnose unsupported markup tags

Aha, Iterator::position is a bit nicer

First-draft HTML parser

Get the QualNames out of my html::Receiver.

push_para

FileHeader text implementation

Render paragraphs by wrapping them.

Build paragraphs, in a bodgy slow way.

For the moment, I've made a CharIterator that returns each coloured
character of a ColouredString one by one. That's nasty, but easy. I
think more ideally I'd want an iterator that returned contiguous
chunks of a ColouredString according to a filter function passed in
that classifies characters as wanting to be in the same chunk. But
that involves function parameters, so I can try that later.

Factor out truncation of a ColouredString

Username headers

EditorHeaderSeparator, which is really easy

SeparatorLine (with proper date formatting!)

More ColouredString stuff I needed

Start of the text module.

Oh wait I don't need to _implement_ Eq

Maybe the version with slices?

Basic version of split.

Returns a newly allocated ColouredString. Perhaps it would be nice to
be able to return a lighter-weight thing containing a pair of &str?

Successful frags iterator!

More, but still not finished

I'm not at all sure that counting by chars is what I really want, hmmm.

UNFINISHED: ColouredString class.

OK, now it doesn't.

Looks as if the only problem there was trying to link the document
root to itself.

Try walking the tree. It crashes, oops.

Abandon html2text and try html5ever.

I _think_ this gets me a tree structure containing the HTML DOM. Now I
have to do the same formatting and wrapping that I'm doing in the
Python version, but that really should just be a matter of conversion.

Now the scanners seem to be working!

First cut at transcribing the scanning regexes.

First cut at parsing HTML of a toot.

But it doesn't work right, because the CSS is ignored. I think that's
because html2text only processes CSS classes on <span> elements, not
on <a> where the Mastodon server puts them.

Now we can draw directly without ratatui widgets.

I didn't really want to have to structure my program around their
widget API, and now I don't have to.

Looks as if this is the best way to go beep!

Set up ratatui and demonstrate event handling.

I've had to put the event-reading in another thread, because I
couldn't see any way to tie extra fds into ratatui's poll loop. So
instead I'm going to have to make subthreads communicate to the main
loop via an interthread channel.

Update .gitignore.

Process raw stream data into UTF-8 lines.

Get rid of the rest of the unwraps.

Made auth file handling fallible.

There are no doubt many ways to do it better, but this is a start -
now it will at least print what went wrong.

Move auth file handling out into a module.

It ought to be fallible, though.

Try using xdg to get the config directory location.

Replace copy_to with direct use of the Read trait

First demo of a streaming API working.

Had to bodgily pull in the Python version's auth data for this, but
it's a start. I can sort that part out properly later.

Move the types out into a separate module.

Experimented with a reqwest Client.

OK, that's probably enough data modelling for now

Deserialise visibility, with compiler warnings

Got most of the dates, but what about last_status_at?

Fill in some more parts of the main structures

Self-reference to subthings via Box

Cope with some optional fields

Decode a sample Status as well as an Account

PoC of retrieving and unpacking a struct.

Begin setting up a Rust framework.

Fix the various 'user's posts' variations.

By generalising the True/False -> true/false mapping across all
booleans submitted as request parameters.

Support <pre> tag in post HTML.

Option to view a post by its numeric id.

More timelines.

These don't auto-update.

Graduations of mode to view a user's posts.

Now we can exclude blogs, and also exclude replies to other threads.

(Interestingly, the 'exclude replies' flag in the API only excludes
replies to _other_ accounts. So it keeps replies to _yourself_. One
effect of this is that if you post a multitoot thread, it all shows up
in this list. Of course the client could filter it too...)

Fix a few NoneType errors.

Change my mind about how to extend backwards.

I think pressing [0] at the top of the file is better than double-[B].
Firstly, it's fewer keystrokes to do on purpose; secondly, it's not a
key you would have been repeating already. Now I can hold down [B]
safely to page up through the existing text, _and_ if I want to keep
extending backwards I can do it more easily than before.

Fix out-of-bounds access in files shorter than the screen

Lists of followers, folllowees, favers and boosters.

Support <blockquote> in HTML.

Ahem, fix last minute breakage.

First cut at viewing a user's posts.

Change wording from 'Reply' to 'Send' for non-statuses.

You might be sending a message to the named user, but you're not
_replying_ to anything of theirs.

First cut at Examine User.

Currently you can only type in names to examine by hand.

Experimental ^K change of behaviour.

If you press ^K to delete to end of line and you're in mid-paragraph,
I think not a bad answer is to _insert_ a paragraph break, so that the
text on the next line doesn't unexpectedly wrap.

This is intuitively as close as possible to the behaviour in the
non-auto-wrapping 'me'. The only thing I don't like about it is that
pasting the text back in again with ^Y doesn't delete the line break,
but I haven't thought of a less astonishing answer to that yet.

Tests of Ctrl-K.

So I can refactor it.

Fix goof in IndentedParagraph.

HTML formatting: support <i>.

Same as <em>, of course.

Some more TODO comments.

Match reply visibility to the incoming message.

I had a conversation in 'unlisted' status with someone, and it was a
pain to keep setting this by hand.

Of course, it's only a default: you _can_ change the visibility in a
reply.

Post info: add list of mentioned users.

Because the post itself doesn't show their fully qualified usernames.