Another TODO I thought of.

Checkpoint the LDB to disk every few minutes.

That should do a decent job of defending against data loss from
panics, SIGTERM, machine reboots, etc.

When thrown into Read Mentions, show the new mention.

This adds an 'is_interrupt' flag to every change of activity; the only
activity constructor that uses it is mentions(), which uses it to vary
the policy about file positioning. When you enter Read Mentions on
your own initiative, you get the same position you were at before, but
when _thrown_ into it, you go to the new message.

In order to still show the new message when you're _already_ in your
mentions, we remove ReadMentions from the list of activities that
don't cause a reload of ReadMentions.

And reload the LDB on startup!

Finally, you can restart the client and have it drop you at your
previous position.

Save an "ldb" file in the config directory.

This is updated whenever we exit a File. I think that's a reasonable
balance between updating it on every single press of Space when paging
through the file (excessive disk churn), and waiting until the whole
client exits (excessive risk of forgetting to save it at all).

Perhaps an even better idea would be to schedule a timer to checkpoint
the LDB every few minutes if it had changed.

Persist the latest read item in the Tui.

Now it's used to set the initial position when File is constructed,
but there's still no actual effect, because the _position_ from the
last File instance on that feed still takes precedence, and we never
save anything into the Tui without one of those.

Track the latest read item within File's lifetime.

Nothing actually uses it yet.

Make FileContents store the item ids.

This allows it to also search for the index of a specific item.

Append \n when we write out a JSON file.

I just happened to notice that serde_json::to_string_pretty makes the
result pretty in every way except this one.

Fix clipping of initial file positions.

It's not enough to just modify the item index - we also have to reset
the line number.

Write configuration files atomically.

This is generally good practice, and clears away a prerequisite for
constantly updating an LDB.

Apply many uncontroversial style fixes from Clippy.

I ran 'cargo clippy fix', picked out the changes I didn't disagree
with, and reformatted a few overlong lines that resulted. It's a
combination of redundant clones and borrows, what Clippy considers to
be the antipattern of assert_eq!(boolean, true), and failure to use
the full vocabulary of standard methods like Option::is_none,
Result::is_ok, and the various and_then() or map() etc combinators.

Clippy fix: borrow the HashMap Entry we want to insert into.

I hadn't known about this method of HashMap at all: you can test
whether a key exists, in such a way that you also get a reference to
the slot you'd want to insert it into if it didn't. Then you don't
need the two hash lookups you would with the more obvious approach of
separately testing for contains_key and then maybe inserting.

Clippy fix: use write_all to beep.

Clippy complains that I used stdout().write(), and although I checked
the error code, I didn't also check whether it had written the full
buffer or only part of it.

But it didn't notice that the buffer was one byte long!

Clippy fix: rename Config::default().

Calling it that, Clippy complains that it looks too much like the
method of the Default trait, and suggests I either impl Default or
rename the method. For the moment, I'll rename the method; I don't
know that I have a good use for impl Default right now.

Fix that horrible loop in the streaming subthread.

Clippy complained about it at fatal-error level because it never loops
more than once. I only wrote that loop so I could break it in multiple
places with different return values.

But I've had a better idea for how to write the fiddly bit, thanks to
remembering that Peekable is a thing. This is nicer.

Editor: fix handling of abutting scan matches.

My example test of '#hashtag@mention' _shouldn't_ have highlighted the
mention, because the word character before the @ disqualifies it. But
I was doing the matching on a slice of the string, instead of giving
get_span the whole string and telling it where to start from.

That in turn was because I hadn't bothered to give get_span that
argument. But it's really easy to add! Now done.

Fix inconsistent colour of visibility keywords.

In DetailedStatusDisplay I still had "unlisted" as red, whereas I'd
changed my mind elsewhere.

The easiest fix is to use an actual VisibilityLine object, removing
one place I have to make all these things agree.

Support listing the URLs in a post.

I didn't have to trawl RcDom after all (as my TODO item suggested).
All I had to do was to put a mutable reference to a Vec<String> into
OurDecorator, and then that could push URLs on to the vector.

Or rather: firstly I had to do that using a &RefCell<Vec<String>>,
because the same Vec<String> reference had to be passed to the
separate decorator instance spawned for sub-blocks. Secondly that
meant I had to bake a lifetime into the type of OurDecorator (since
the call site must know that the reference to the RefCell went away
when the config object is dropped).

Also, I wanted to exclude the URLs that come from mentions and
hashtags, which meant tracking whether a colour annotation had been
applied to anything inside the link - whether it was already live at
the call to decorate_link_start or was turned on immediately
afterwards.

Split media URLs at w-1 chars, not w.

This makes no real difference, but now they match the URLs in the text
of posts. In the Python version both split at w, but now that I'm
delegating HTML processing to html2text, that splits overlong words at
the same width it wraps sensible lines to. So I have to either have
them inconsistent or change the media one.

w-1 is more 'Mono' anyway, let's be honest :-)

Fix last-column glitch in post composition.

Make all the tests compile again (ahem).

Flag readonly mode on the main menu.

Then I get a reminder of whether I can safely compose embarrassingly
nonsensical test toots, or whether I'm supposed to be being coherent :-)

Ceremonially delete the Python prototype!

We've reached feature parity, although I haven't been running the Rust
version live for more than a few hours so far, so there's still a
possibility of finding a bug the old version lacked.

But it's now actually awkward to have it in the same directory - the
two clients look similar enough that I can accidentally run
'./mastodonochrome' in place of './target/debug/mastodonochrome'
during testing, and then be puzzled when it doesn't behave _quite_ the
same.

So, if I need it in an emergency, I can always recover it from the git
log.

Remove an obsolete FIXME comment.

Primed extensibility indicators have been working for _days_.

Support highlighting the user name in a UserListEntry.

So you can look at a list of followers/favers/boosters and go to
Examine User from there.

More robust handling of fatal errors in sync_channel.

They were being squelched with a triple-FIXME comment, probably from
very early in development. Now it seems clear that we just propagate
them up to an 'abort the whole Tui' error, because if that goes wrong
then surely there's a disaster too weird to recover from.

Trivial indentation fix.

Add a proper TODO list.

My previous jottings were kept outside source control and not very
organised. This is a version I wouldn't be embarrased about showing to
an outsider!

Fix rendering glitch when ExtensibleIndicator vanishes.

We'd end up drawing three fewer lines of the top of the revised file
than would have fitted on the screen.

Add feature to show posts by the user you're examining.

Get the default language from the locale.

Turns out Rust has a handy crate for that.

Show visibility of posts with an extra header.

Also, changed my mind: 'unlisted' doesn't deserve to be alarming red.
Boring grey is enough.

Examine User: compact way of displaying fields.

This is much simpler than my previous idea of trying to modify the
HTML DOM to insert the heading at the start of the first paragraph!

Editor: keystrokes to go to top/bottom of buffer.

I almost forgot about those until I caught myself doing them in real
Mono today.

Editor: scroll to keep the cursor in view.

List modes that shouldn't throw you into mentions.

Highlight media of a status as well as text.

If the status has _only_ media, this will be important!

Show what user you're logged in as.

Useful when testing two dummy accounts on a dev server, but might come
in useful for real people maintaining more than one config directory
as well.

Fetch the two main feeds on startup.

Mostly, this fixes missing message beeps. But it also means the UI
won't pause annoyingly the first time I go to one of those feeds.

Implement searching within files.

I think that's now all the functionality from the Python prototype,
and we're ready to switch over!

Remove leftover diagnostics.

Save and restore file positions when changing activity.

Now you go back to where you last were in the file.

Store an actual FileType in File.

That way it can remember what feed the file is about, so as to save
the file position later.

Make new_activity_state a method of TuiLogicalState.

I got away without it having to be for a long time, but now it's going
to need to fetch file positions.

Fill in some fixed initial file positions.

Examine User and Post Info should start at the top, not the bottom,
now that we have the ability to do that easily.

And when you view the thread of a post, it makes sense to me to focus
_that post_ to start with!

Add an initial_pos to the File constructor.

Rework FilePosition to cache the last known width.

This way, it doesn't have to eagerly throw away its 'fine' position:
it can keep it until it's next called on, and then reuse it if the
new render width happens to match.

I think it's also simpler than the previous approach!

Fix extending user-list feeds.

In lists of followers, favers, boosters etc, the ids you have to pass
in the 'max_id' or 'since_id' URL query parameters are not the same as
the account ids you get back. That's not surprising, now I think about
it, since the chronological order in which users did things has
nothing to do with any intrinsic ordering on the users themselves.

For status feeds, they seemed to match, so I got away without having
to pay attention to the Link: headers in the HTTP responses. But now I
realise I do have to worry about that after all. Happily, there's a
handy Rust crate that saves me having to do the work of parsing that
complicated header type!

CLI option to log HTTP transactions to a file.

This allows me to actually see what's going on when the client
misbehaves.

Create a log entry for every HTTP transaction.

These are built into a struct and passed to a 'consume' method which
currently does nothing with them.

In the immediate short term, I want to add a --debug option which
writes them to a log file on disk, so I can look at a misbehaving
session and see what went wrong.

In the longer term, I think I might also want to keep a rolling buffer
of these log entries, and make it accessible through the Logs Menu.

Fold the send() into Client::api_request.

One fewer line of faff at every call site. Plus, now I can centralise
logging usefully.

Implement the various user lists.

Lists of users who followed or boosted a given post, or who a given
user follows or is followed by.

But something goes wrong when you try to extend these feeds. I'll
debug that in a moment ... but first, let's write some debugging
framework.

Implement replying to posts.

This involves a new Post constructor that fills in in_reply_to,
propagates visibility, and populates the post text with appropriate
@mentions; and a new pair of activities (these ones Util rather than
non-Util) to pass the reply back and forth between the composer and
the post-compose menu.

Move some code into an InReplyToLine::from_id constructor.

That will make it easier to reuse later.

Implement viewing the thread of a selected post.

Just as in the Python version, I provide an extra convenience method
which calls the API service twice, once to find the post's ultimate
top-level ancestor, and then again on that post to show the full
thread (maximal connected component) that it's a part of, not just its
own particular line.

Generalise SingletonSource to hold a whole vector.

The previous new() constructor is now a singleton(), so it can still
work for its current purpose.

Implement favouriting and boosting posts.

For these uses of selection, we have to support different keystrokes
to fave and unfave, which means we also need to know which keystroke
is valid when. So I've had to plumb the Client through to all of the
methods that move the selection, because those methods need to
retrieve the newly pointed-to status and cache whether it's already
faved/boosted. Otherwise draw(), which can't mutate things, can't
find that out to display the right status line.

Implement selecting things in File.

This makes the [E] and [I] keystrokes begin working in general, to
examine a selected user and to view the full info for a selected
status.

Factor out feed extension code into a method of File.

Mostly just because it's large and cumbersome and it's nice to keep
the key-handling match cases short.

Actually implement the highlighting methods!

Everything up to here just added API. Now I'm actually providing
non-default implementations so that TextFragments that need to
highlight can be highlighted.

Store ids in all the TextFragments that will need them.

The method of finding out _what_ thing was highlighted has to return
it by its string id. So anything that will have to highlight a
contained object will also need a way to return its id, so they all
have to store those ids.

Add highlighting methods to the TextFragment trait.

I've chosen to have three rather than two classes of thing you can
highlight, by separately indicating whether a text fragment contains
highlightable 'statuses' or 'whole statuses'. The distinction is that
a 'whole status' means you can see all the text, whereas a 'status'
just means you can somehow identify which post it is. I'll use that to
arrange that replying, favouriting and boosting only apply to whole
statuses (too easy to make a mistake otherwise), whereas any 'get
more info' commands apply to any old status.

(In particular, this way, you can see a one-line summary of a status,
press [I] to look at the whole thing, and _then_ fave/boost/reply.)

Tidy up: make Option and Vec pass through TextFragment.

Now if you have an Option<TextFragment>, or a Vec<TextFragment> (or
even, heaven help you, an Option<Vec> or a Vec<Option<Vec>> etc), you
can just call .render() on the whole thing without having to manually
loop over it. I'm starting to like this feature of Rust!

When caching a status, cache its reblog too.

That's another whole status, which we should be able to look up.

Reclassify status info as a utility activity.

I meant it to be that in the first place - that's why I entered
InfoStatus in the utilities enum. But then I forgot it was there and
made a separate entry for it.

When you're invoking status info from within a file, I think it makes
more sense as a utility, the way I first had it.

Support saving login details. We can now log in!

Move TopLevelError up to the root of the crate.

If that's not a candidate for putting at the top level then I don't
know what is.

Implement the login procedure, without saving.

Currently, the JSON-serialised AuthConfig is written to stdout, just
to prove during development that it works. Next step is to save it to
where it ought to live.

Actually post something!

Post-compose menu, up to but not including posting.

Give MenuKeypressLine a width reset option.

Then when I change menu items on the fly they won't always remember
the largest width the menu has ever had.

Move prompt into SingleLineEditor.

It was a mistake to put it in the wrapping BottomLineEditorOverlay,
because I'm going to want to put single-line editors elsewhere on the
screen with the same kind of prompt.

Update html2text to 0.10.1.

Chris has released a version containing my pull request that supports
the <del> tag, which I encountered in a toot last month.

Editor: implement cut to end of line.

Fix handling of newlines in is_char_boundary.

Newlines have width 0, so we were mis-classifying them as a combining
character, causing the point just before one to be considered not a
character boundary!

Editor: support beginning/end of line.

Editor: support page-up and page-down.

Not very useful just yet while we're not able to scroll to keep the
cursor in view, but even so, it's nice to be able to get to the bottom
quickly!

Editor: implement Up and Down keystrokes.

Editor: make the cursor position persist.

Then we'll still have it available to refer to when processing
keystrokes.

Fix an edge case of watching a nearly empty feed.

This just came up when testing against a dev instance, which starts
off with 0 posts anywhere, of course.

Develop an explicit HTTP redirection policy.

The Mastodon dev system runs its streaming API on a different port of
its VM. So you need to be able to follow an HTTP redirect from
http://mastodon.local to http://mastodon.local:4000 and still pass the
same auth token to that server.

But in general, one should not keep authentication configuration when
traversing a cross-site redirection! reqwest's automated redirect
following won't do it at all, and rightly so.

So I've written a custom redirection policy which allows _same_-host
redirection (just in case something turns out to need it), and doesn't
follow cross-site redirection (which would in general be useless
anyway because of this auth issue). And when setting up the streaming
API in particular, we catch the unfollowed redirection, vet it very
carefully (against the official streaming API location which the
instance happily advertises in its configuration record), and if we're
satisfied, make a fresh request to the target URL which _does_ pass
the same authentication.

As a result, now we can do streaming to the Mastodon dev instance,
which the Python version of this client _never_ managed!

Make AuthError into a subcase of ClientError.

Now tui.rs doesn't have to handle it directly, and our client setup
can return the more general ClientError.

Fix movement by words in the editor buffer.

I apparently only half-finished writing is_word_boundary: it tested
that the _next_ character wasn't a space, but not that the previous
one was.

Start of a full-screen editor for composing toots.

You can't actually post anything. And none of the keystrokes special
to the composing editor is implemented yet (ok, except [^O][Q] to quit
the editor). But you can at least start typing text into the buffer,
and it gets wrapped, colourised, and checked for being too long.

Make our regex scanner into a lazy_static.

That way we only construct it once per runtime, not once per Editor we
instantiate. I've just realised that that must be what's making some
of my half-written editor unit tests slow.

Decentralise version component of API URLs.

I thought it was /api/v1/whatever, but I've just realised that it's
actually /api/v2/instance in particular. _That's_ why I keep seeing
"uri" from some servers and "domain" from others: if I requested the
up-to-date version of the record, it would agree on "domain".

Fix test failure introduced by format_date.

I didn't read carefully enough the code I was replacing with a
function call. It had an extra space at the end of the date format
string.

Support retrieving the Instance object.

Not much of it is decoded at the moment, but we'll need a few pieces
of configuration to inform the post composer about important things
like how to tell when it's hit its length limit.

Fill in percentage in file status lines.

I was putting that off because I had a half-formed clever idea about
trying to do linear regression on the posts we _have_ formatted to the
current width, and using it to estimate the likely line height of the
ones we haven't. But then I decided that was either the perfect being
the enemy of the good, or a silly idea that was bound to explode in an
edge case, or both, and so I've done something simple instead.

The _main_ purpose is that '100%' means 'nothing more to read' and
anything less means there is. As long as we get that much right, we're
in reasonably good shape.

Elide 'foo: foo' in struct literals where possible.

Another thing I only just realised: although in general you're
supposed to explicitly say the name of each field you're initialising,
there's a special case where you can leave it out if the name of the
local variable you're initialising it _to_ is exactly the same.
Presumably on the grounds that that still doesn't allow much
confusion, and is terser.

Remove lots of commas after braced match arms.

I only just noticed from reading someone else's Rust code that they
aren't syntactically necessary!

Stop using ~ around struck-out text.

Apparently html2text is completely happy to render strikeout via
U+0336 COMBINING LONG STROKE OVERLAY, and needs no support from the
terminal escape-sequence system at all. So I don't need an artificial
indication that it happened.

Support reading hashtag feeds.

No trouble at all given the existing infrastructure.

Fill in the rest of View Post Info.

Remove some assorted dbg! I don't need any more.

Start of View Post Info.

Currently it just shows the post in the ordinary way, without all the
extra detail. But it's plumbed through the menus, which is a start.

Filled in account flags.

I think that's Examine User all done now!

Leave out the double-check of the account name.

Turns out it's case-insensitive, bah.

Show account relationships.