Fix title of user_posts files.

Ahem. Copy-paste error from another constructor function!

Update to the latest html2text.

Chris just announced it. This time I don't know of any feature I'm
desperately missing, but bug fixes are always helpful.

TODO updates, including a bug I just noticed.

When replying to a post, propagate its spoiler warning.

I forgot this yesterday in discussions of a maths problem, and posted
an answer in cleartext. Happily, it wasn't a very hard problem. But it
would have been better if the default had been to repeat the spoiler
text from the parent post; I could always change it manually, but if I
don't want to think very hard, this would more likely be right.

Honour server-side defaults when composing a new post.

Now after you set your default language, visibility and sensitivity in
[ESC][Y][O] (or indeed via any other client authenticated to the same
account), they will be used by the posting UI.

Ability to set most of your own options.

For the moment, I've left out the account bio and the extra info
fields, because those both require UI extensions we don't have yet.
Added to TODO.

Client request to update your account details.

Retrieve extra details about your own account.

Turns out that the API data model has two related types: 'Account',
which you can retrieve for anyone, and 'CredentialAccount' which
contains an extra sub-object full of settings you can only set (or
see) for your own account.

In another language I could make those distinct actual data types,
one a subclass of the other adding the extra field. Here, it's easier
to just fudge it a bit, pretending that all Account objects
_optionally_ have the 'source' subobject, and when called on to
retrieve our own record, always doing it via the API call that
provides the extra.

This also introduces a bit of a wrinkle about caching the result - we
_do_ also receive copies of our own Account record in other
contexts (e.g. as the author of a status we posted that reappears in a
feed), and so we have to ensure we don't use those to overwrite our
cached record to delete the source. This is ugly, but I prefer it to
the other option, which is to maintain a _separate_ cache of our own
account record with the extra data, and have to worry about which
version of the rest of it is up to date.

Post menu: separate 'sensitive' from 'spoiler text'.

Alas, it _is_ possible to tag a post as sensitive but not provide any
spoiler text. I don't think I should make it actually impossible
through the UI of this client, so here's a change to permit it.

But I'm discouraging it as much as possible, by focusing into the
content-warning editor as soon as you mark a post as sensitive. That
way, if you really want an absence of warning, you have to
deliberately refuse to type one and press Return.

Initial user-options menus.

The one for your own options is currently unimplemented (but it had to
_exist_, because both options menus are launched via the same UI
action, and only the target user id distinguishes the two).

But the one for other users supports following and its suboptions,
blocking, and muting.

Similarly reusable menu line for cycling between options.

More reusable concept of an editable menu line.

This refactors a lot of the code from posting.rs into a type that does
all the work of being switchable between a menu line and a single-line
editor.

No functional change (I hope), but it should make it easier to reuse
in other similar options menus.

Revise menu width handling via a new trait.

get_widths has become check_widths, which subsumes the processing done
at every call site, and will be easier to extend to the next thing I
have in mind.

Also, the three width-aligning methods for menu lines are now part of
the MenuKeypressLineGeneral trait. That only has one implementing type
right now, but another one will be along shortly.

Add a trait TextFragmentOneLine.

This is a slight refinement of ordinary TextFragment, to be
implemented by types that render to exactly one line of text always,
as opposed to being able to render to 0 or to more than one. The idea
is that if a type implements this trait, then the compiler can _know_
there's one line of text coming out of its render method, instead of
having to call .iter().exactly_one().unwrap() and think hard about
whether I'm risking a runtime failure.

I could implement this trait for a lot more things in text.rs, but for
the moment, I'm only bothering to put it on the one that I need it for
right now.

Fix toot length tracking with nontrivial Unicode.

Somehow I totally forgot to distinguish chars from bytes in
Composer::make_regions(), _and_ forgot to test it. So I had a crash
this morning when editing a toot containing Unicode put the 500-byte
mark midway through a UTF-8 character.

That's wrong for _two_ reasons - firstly, no endpoint in the regions
array ought to be anywhere other than a character boundary, and
secondly, the 500 _byte_ boundary has nothing to do with the toot
length limit in the first place! The 500 _character_ boundary would
have been more to the point.

Support unfolding and refolding of sensitive toots.

There's a new highlight type for this, so that it can apply to
InReplyTo lines as well as statuses themselves.

The set of unfolded sensitive statuses needs to be shared between lots
of views of the data, so I've put it in the TuiLogicalState, under a
RefCell so that ActivityStates can all borrow it easily, not just to
look up in but also to modify.

Ability to display sensitive toots folded up.

Not currently used: all our current DisplayStyleGetters
unconditionally return true from their unfolded method.

This has to apply to the quoted line of a toot in Re: lines, as well
as the full display of the post contents.

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!