Remove some pubs from html.rs.

Just spotted that those aren't really needed.

Use feed updates to lengthen the home timeline.

Untested as yet, but this _should_ replicate the behaviour from the
Python version where you're reading your home timeline and a new post
quietly appears below what you can currently see.

Fix help message.

Begin setting up the streaming subthread system.

This gives Client two new methods. The first starts a subthread
listening to a stream, given a lambda function that you pass into the
subthread to handle the response. The second runs in the context of
the main thread, and the idea is that you give that same response
straight back to the client.

The owner of a Client object is responsible for doing the plumbing in
between, to arrange that a response passed to the lambda in the
subthread is transferred back to the main thread and given to
process_stream_update.

The implementation of that plumbing in Tui sends the data back to the
main thread over a clone of the sync_channel we already had, so that
it's received in the same event loop as terminal input.

So far, nothing is done with the updates.

Also not done: it would be nice to be able to ask a subthread to
terminate, if it's not needed any more. That way if the user tries to
read one of the fast-moving public timelines, we can dismiss its
update thread as soon as they're not looking at that file any more.

Add a couple more primary timelines.

Ability to extend the feed backwards in time.

Haven't yet tested the part where extension runs out, though. That
will be easier when we get some more kinds of feed, so I've left a
FIXME comment in there.

Remove an unnecessary drop.

I had imagined that explicitly dropping a reference would terminate a
borrow. But firstly, rustc 1.74 says it does nothing at all, and
secondly, therefore I infer that this particular borrow wasn't in the
way in any case.

Migrate back to html2text.

I gave up on using it previously because it lacked some important
features - in particular, it didn't support CSS on <a> elements, which
is necessary for identifying hashtags and mentions in Mastodon's
output HTML.

In 0.9.2 that feature is present, so I can try again! Also, 0.9.2 has
the neat ability to save the RenderTree that's an intermediate product
of the pipeline, just before we depend on the width. So we can keep
that after parsing a toot, and then only re-run the necessary back end
of the pipeline to re-render at a different width.

The amount of code is extremely reduced.

Use ratatui's Color::Gray instead of Color::White.

The former is the ESC[37m colour. The latter seems like the natural
name to my way of thinking, but it means tell the terminal you're
_really serious_ about wanting proper #ffffff.

Go to top and bottom of file.

I think this is all the basic 'paging around' actions done!

Add a file header!

Clip position at the top of the file.

Scrolling downward, too.

Scrolling upward mostly works.

Doesn't clip at the top of the file yet, but this is a start!

More or less principled file-position tracking.

We still can't actually _scroll_ through the file, because I haven't
made any actual keystrokes work yet. But we begin displaying it at the
bottom, and do something sensible on resizing.

Notify ActivityState mutably when it gets resized.

This should enable it to prepare anything it needs for the next
redraw.

Pass client through to handle_keypress.

Forgot to break overlong logical lines.

Now URLs show up in a way that you can actually paste into a browser.

Fix paragraph wrap width.

We were wrapping to the full screen width, instead of Monochrome's
traditional w-1.

Basically correct-looking display of toots \o/

Now we display the separator line of each toot. Progress!

URL in statuses is optional.

Reblogs don't have one: you can't view the reblogging status in the
web UI, only the reblogged one.

Now we try to actually fetch a feed.

It doesn't work! JSON parsing error.

Prepare to pass a Client through to activity constructors.

Temporarily squelch some warnings.

I _know_ all those things are unused - I haven't finished writing the
program yet. Shut up about them until I'm done!

Allow error reporting as a PhysicalAction.

Could easily come in useful!

Make a Client and put it in the Tui.

This involved souping up the error handling so that we can absorb
errors from various different sources during Tui construction.

Untested code to fetch feeds of items.

Readonly mode for the client.

This was very useful when I was testing the editor last time round,
and surely it'll be just as useful this time.

Forgot to make sure ESC G worked!

It _worked_ in the Python version, but I apparently left it out of the
visible menu options. But here they're more tightly tied together, so
leaving it out of the visible options made it not work at all.

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.