Wrap poll_options into a general display-style trait.

Fix panic when extending an empty feed.

If a file contains nothing but a header and an extensible indicator,
and you press [0] to extend, and that attempt to fetch more items
fails, then the extensible indicator vanishes, and is removed from the
file's list of items. So the 2-line header moves forward one index
slot, into the place where the 3-line indicator was. But on any but
the tiniest screen, your current position was surely on the last line
of the indicator - so now it's out of range of the item now in that
position.

To fix this, I've added a new position fixup function, which is called
whenever we fear our line position might be outside the bounds of the
item it's in. This is called after try_extend, where the problem
actually showed up; it's also called on resize(), in case a file is
newly constructed but one of the statuses in it has been updated from
the server since we last visited.

More ColouredString streamlining.

By making Paragraph::add() take a general impl ColouredStringCommon,
we can get rid of a lot of no-longer-necessary &.

General TODO updates.

Some more details, links etc, plus a bug I just noticed in
favouriting.

Get rid of ColouredStringSlice::to_owned() completely.

It's superseded by the impl of From for ColouredString, which means
now if you want to turn a ColouredStringSlice into an owned string,
you can either say ColouredString::from(slice) or slice.into() at your
option. And I haven't found any cases where I had to use the more
verbose of the two.

Remove most uses of ColouredString::slice().

The new flexibility means we don't have to use an explicit method call
to turn a ColouredString into a ColouredStringSlice before passing it
to ColouredString::push_str().

Also, in tui.rs, ratatui_set_string demonstrates that functions
outside the coloured_string module can also be given the flexibility
to take either an owned ColouredString or a slice, by taking an
argument 'impl ColouredStringCommon'.

However, in FileStatusLineFinal::render_highlighted(), where I pass
ColouredStringSlices to a closure, I _couldn't_ do that - closures are
apparently more restricted than ordinary functions in that way. So
that's the one place where I still had to explicitly call .slice().

Restructure ColouredString via a common trait.

Now ColouredString and ColouredStringSlice both implement the trait
ColouredStringCommon, and as many methods as possible are provided by
that trait, depending only on the unimplemented trait methods to get
the text and colours and &str.

This reduces the amount of code, and also makes points of use more
flexible, because I can implement the common trait not just for both
the actual types, but also references to them.

The only disappointment is that I wasn't able to also fold the four
identical impls of std::ops::Add into one via a single
doubly-quantified impl. But instead I got to deploy my first
macro_rules!, so that's something.

In the next commits I'll clean up now-unnecessary boilerplate at call
sites.

Fix duplication of items in feeds.

When we request any part of the contents of a feed from the server, it
provides us with followup links we can use to extend the same feed
further into the past or future. But if we're extending it further
into the past than we had, we shouldn't save the future link we get
back, because it's not as good as the future link we already had. And
vice versa.

The effect of this bug was that after extending a feed into the past,
the next extension into the future would start from the past
fragment's future extension and re-retrieve all the items we already
had. And we wouldn't notice, and would store a second copy of all
their ids in our list.

Support showing content warnings.

We still don't hide the rest of the post, but this is a start, because
sometimes the poster expects that you've at least _seen_ the warning
text. (For example I saw a post today in which the content warning was
the question part of a joke, and the post body was the punchline.)

Add support for polls in other users' posts.

That is, we can't post them ourselves yet, but we can see them when
other users post them, and vote in them.

Check for new messages on startup.

And beep the user into their mentions feed if there are any, just like
Mono does when you log in.

Clean up huge piece of duplicated logic in Tui.

Adding the refresh key to it was more than I could bear.

^L to refresh the screen.

In case of corruption. An obvious case of corruption is extraneous
output to the same tty (from an unrelated background process, or from
a rogue dbg! in this program itself). Another one I've been seeing
recently is a mysterious corruption relating to some Unicode
characters that only shows up in tmux on one system. But regardless, I
want to get on with my session after anything like that happens.

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".