Derive YourOptionsMenuContents rendering with derive-adhoc

We needed a couple of traits for this.  And a context structure or it
just gets silly.

Reorder YourOptionsMenuContents

Now it's in the same order as the actual displayed menu.

Derive YourOptionsMenuContents::fix_widths with derive-adhoc

optiuons: Break out YourOptionsMenuContents

Much textual churn, but no functional change.

Fix sense of a matches! test.

Commit 009510029ba6cb7 translated it from a 4-line 'match self' with
the wrong branch corresponding to true.

Merge Ian's fixes to satisfy and/or silence Clippy.

The net effect of this branch is that 'cargo clippy' has no remaining
complaints.

Suppress unknown lints

Regularise Paragraph::add and introduce Paragraph::push

Merge Ian's ColouredString improvements.

Implement a visible 'busy' indicator.

This is implemented by giving Client a reference to the TuiOutput,
which it can call to notify that a network operation has started. So
whenever any keystroke results in network activity, we immediately
update the screen to indicate that something is happening that takes
time, reducing the risk that the user will believe their keystroke was
ignored.

The Client's reference is wrapped in a new 'TuiBusyIndicator' struct,
in case we need to change the notification mechanism. (For example, if
this business ever starts to sprawl across multiple threads, it might
be more convenient to make TuiBusyIndicator contain the sending end of
a sync_channel, so that the display thread would receive the busy
indication from wherever it was sent.)

All client activity goes via the just-moved execute_and_log_request
method, so that's the only place I need to insert a call to set_busy.
So this causes no extra boilerplate per Client method.

Make execute_and_log_request a method of Client.

All the calls to it happen inside methods of Client, so there's no
reason this is difficult. The only reason it was a separate function
in the first place was so that the old version of login.rs could use
it, which did login outside the full TUI via a separate network
interaction module. But now all the functions of that module have been
moved into Client, execute_and_log_request is fine as it is.

It also doesn't need to be pub any more.

Move terminal output into a sub-struct.

The sub-struct is held in an Rc<RefCell> by Tui, which will allow me
to make other copies of the Rc and use them to give preliminary
display updates.

impl TextFragmentOneLine for CentredInfoLine.

This always draws exactly one line, and I'm about to want to use it in
a context that expects that and doesn't want to worry about unpacking
a returned vector.

coloured_string: Make ColouredString common blanket impl for &

This also avoids repeating the (trivial) field accessor bodies.

coloured_string: Simplify a macro

We can use a non-elided anonymous lifetime here, which makes the macro
a lot simpler.

Apply deferred rustfmt churn

Locally suppress a lint, with a TODO

I don't want to do this renaming now.

Derive Default and use it instead of open-coding in new

Add Default impls (prompted by clippy)

Reduce String consing in reply userid

Not sure if this is worthwile.  You may want to suppress the lint
clippy::format_collect instead.

Introduce a type alias

This type is repeated.  clippy complains about it too.

clippy: Suppress a lot of lints

Remove some otiose lifetimes

clippy complains about this (but we're going to suppress the lint, and
maybe we want to keep them sometimes).

Replace from_str_radix with FromStr/parse

Change !...is_some to is_none

Remove some unnecessary .to_string

Use unwrap_or_default

Use matches!

Remove redundant license-file from Cargo.toml.

Now I see the warning pointing out that it's not necessary to have
that _as well_ as the license = "MIT". Seems odd to me, because
there's still more detail in the full file (copyright holders, dates),
but whatever.

Add README and metadata.

So I can publish to crates.io, reserving the name and allowing
installation of the binary via 'cargo install mastodonochrome'.

Only display _nonzero_ follow-request counts.

Ahem. Of course I initially tested this in the difficult case, and
forgot to check the easy one :-)

Remove an unnecessary to_string().

Another useful piece of Clippy advice from Ian.

Fix character counting in masked passwords.

Thanks to Ian for picking this out of Clippy's huge output dump: when
counting the things in a str that EditorCore would regard as
characters, we were using 'map' rather than 'filter' to pick out
things with positive terminal width, which had no effect on the
following .count(). So a Unicode combining character would display an
extra * in the masked password when _not_ editing it, compared to when
editing it.

Tidy up a few rustfmt divergences.

One of them misaligns Ian's list of test cases (sorry), but it does
have the advantage that I can M-x rust-format-buffer any time I've
made a mess, and not have to think too hard about tidying it up.

Show pending follow requests on the Main Menu.

Now you can find out _that_ you have pending requests, in order to go
through the procedure of accepting or rejecting them.

I'm not 100% sure this is the best thing for all users of locked
accounts, so I've left in a TODO item for 'maybe there should be a
method of proactively notifying you of incoming requests'. But this
completes the initial implementation of _something_ that's usable.

Implement responding to follow requests.

If a user has requested to follow you, you get an extra menu item in
the options menu for that user, where you can accept or reject the
request, or leave it unresponded-to for another time.

To make this optional menu item less painful to implement, I made the
MenuKeypressLineGeneral trait also apply to Option<T> for any inner T
that also implements it. So I can do all the routine admin like
ensure_widths without writing three annoying 'if let Some(...)'.

(But that doesn't let me get_value() on an optional CyclingMenuLine -
that would be silly! For retrieving the value, or cycling the line,
you still need to check if it's actually there.)

Support listing your follow requesters.

We don't yet have a method of approving or denying the request.

Change FileType::CAN_LIST into a method.

Now it can return extra information determined at run time.

Improve OtherUserOptionsMenu's handling of follow requests.

Now, when the target account is locked, the 'Follow this user' menu
option is reworded as 'Request to follow this user'.

Fix display of pending follow requests.

I had misunderstood the Mastodon docs' description of
Relationship::requested, which said "Do you have a pending follow
request for this user?". It turns out that means _you_ have requested
to follow _them_, not the other way round.

The other way round is also represented in this record, as the
'requested_by' field (mirroring followed and followed_by). Apparently
it's been in the server code for over a year, but accidentally left
out of the documentation until last month.

Fix keystrokes in options menus.

The status line advertised [RET] as a way to get out of the menu, but
handle_keypress() only supported [Q]. Now it supports [RET] too.

Also, [SPACE] is the keypress to submit changes to user-related
options, but the status line forgot to mention it at all! Now it does.

login.rs: factor out ready_to_register().

Spotted this obvious duplication in passing, while looking for
something else.

Tolerate hidden number of followers in Account

This can be -1.  Display `(hidden)` when it's not available.

Merge Ian's Client refactoring.

TODO: add 'please wait' display update idea.

Ian suggested this, but I'd noticed it too, and just hadn't got round
to either fixing it or (much easier) writing it down.

client: Instrudoce api_request_ok and api_request_raw

This avoids open-coded (and easy-to-forget) error handling at each
call site.

Presently, the only caller of api_request_raw is api_request_success,
because the sites that want anything else are open-coding
execute_and_log_request etc.

client: Better handling of JSON deser failures

If the returned JSON doesn't match the schema implied by our struct,
we now print (a normalised form of) the JSON as part of our error.

If the input isn't JSON at all, we don't include the malformed JSON
text.  It might be hazardous.

client: Introduce api_request_parse and use it in 14 places

Update h2 in lockfile

Addresses RUSTSEC-2024-0003.  (May not be relevant, but we should
update out of tidiness.)

    $ nailing-cargo -o audit
    nailing-cargo: out-of-tree, git, building in: `/home/ian/Rustup/Mastodonochrome/Build/mastodonochrome'
    nailing-cargo: using really to run as user `rustcargo'
    nailing-cargo: *WARNING* cwd is not in Cargo.nail thbough it has Cargo.toml!
    nailing-cargo: nailed (0 manifests, 0 packages)
    nailing-cargo: invoking: cargo audit
Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
  Loaded 595 security advisories (from /home/rustcargo/.cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (257 crate dependencies)
    Crate:     h2
    Version:   0.3.22
    Title:     Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)
    Date:      2024-01-17
    ID:        RUSTSEC-2024-0003
    URL:       https://rustsec.org/advisories/RUSTSEC-2024-0003
    Solution:  Upgrade to ^0.3.24 OR >=0.4.2
    Dependency tree:
    h2 0.3.22
    ├── reqwest 0.11.23
    │   └── mastodonochrome 0.1.0
    └── hyper 0.14.28
├── reqwest 0.11.23
└── hyper-tls 0.5.0
    └── reqwest 0.11.23

    error: 1 vulnerability found!

Commit Cargo.lock.

Ian tells me this is supposed to be part of the repository, which I
had not at all understood - I'd assumed it was a local cache. Added,
and un-gitignored.

Add a README and licence document.

I was going to delay publishing this repo until I'd polished off the
most important parts of TODO.md, but someone asked me for access, so
I'll change the schedule.

But one thing we _do_ need before publishing is a licence file, so
let's get round to adding that.

Remove lib.rs.

I'm a bit concerned that with a main.rs and a lib.rs, this package
might accidentally have made both a binary and a library crate,
which (as and when I publish it) might cause people to try to use the
library as if it had a stable and committed API.

In fact all the library modules in this source base are considered
internal to the application, and the interfaces between them are
intended to vary however this application finds convenient. So I
shouldn't accidentally imply otherwise.

Move TopLevelError out into its own source file.

Now lib.rs is just a list of declarations of other modules, which
seems cleaner.

Fix Markdown syntax in TODO.md.

Bullet points don't work unless you separate them from the preceding
paragraph with a blank line.

Make [ESC][Y][V] go to the Error Log.

I put that keypath in the file title, so I shouldn't have forgotten to
make it actually work!

Nicer handling of 'not found' in bottom-line prompts.

This was another remaining error-handling todo, now tada.

Report posting errors in a way that allows retries.

Having written that into TODO.md in the previous commit, let's
immediately polish it off, because I already know how to do it - the
login workflow has exactly that kind of error report already.

Implement a proper TUI Error Log.

At last! Now, most errors received from the server will go into a log
that doesn't interrupt and terminate the TUI, and you can at least try
to recover from them and do something else instead.

There's undoubtedly still work to be done in making the errors more
useful, but this is a start. I've left some thoughts in TODO.md.

Store a log of errors in the Client.

Each entry is a ClientError and a datestamp. But errors generated in
the client don't _automatically_ get added to this log: they get
passed back to the caller of an individual Client method, the same as
they always have. That way the caller can decide whether the error is
one it can handle in some other way, and only if all else fails, call
client.add_to_error_log().

The next plan is for every client.add_to_error_log() to be followed by
throwing the TUI into the Error Log file.

Give File an infallible constructor.

This is useful for data sources whose init() method doesn't actually
need to do anything, because it allows the function constructing one
to statically know that no error will be raised, and not have to write
an ugly unwrap().

Add a text::ErrorLogEntry type to format errors.

This works towards implementing the TUI Error Log instead of panicking
or terminating with a deliberate error message.

Turn FileType::get_from_client into an &self method.

This enables the FileType object itself to store information about
where its data comes from, instead of _necessarily_ being constrained
to get it from the client.

Therefore, I've also renamed it, so that the method name doesn't imply
that the data always lives in the client.

This also means that every call to FileContents::update_items() must
pass through the FileType from its owning File, but that's no trouble.

Move some ColouredString methods to the right file.

Just found these lying around in text.rs, apparently because they were
useful for Paragraph. They should go with the rest of the
ColouredString methods! In particular, is_space() ought to go in the
trait shared between ColouredString{,Slice}, so that there only needs
to be one of it.

Reorganise the ClientError enum.

Now it has lots more cases, which should make it easier to format each
one nicely into an entry for a TUI-displayed error log.

Other changes:

 - when we keep the error message from the JSON error document, we
   _also_ keep the HTTP status code

 - lots of from_request calls were missing (possibly in the stuff I
   moved in here from the old separate login.rs). Reinstated.

Jump to new mentions even if we're already in mentions.

I noticed this because of the bug fixed in the previous commit - I
_wasn't_ already in my mentions feed, and got thrown into it by an
incoming message, but the file position didn't update.

If the ReadMentions activity state had been properly GCed and
recreated, it would have jumped automatically to the new message. But
it _ought_ to be doing that even if I were in Read Mentions already,
which is a rarer occurrence. So the previous bug gave me the
opportunity to spot and fix this one too, before it hit for real!

Stop activity states loitering in initial_util.

In order to respond to Alt+E by putting a prompt at the bottom of the
current activity (rather than the naïve approach of breaking the
keypress into ESC + E, switching to the utilities menu in response to
the ESC, and then putting the prompt at the bottom of that much less
helpful screen), we remember an activity from the start of the overall
keypress, in the 'initial_util' field of ActivityStack.

But then we _leave_ it there, and don't clean it up - which means it's
returned by ActivityStack::iter(), and hence inhibits garbage
collection of the associated activity state. So a thing could linger
in there for ages despite not actually being on the stack.

Use Mastodon's JSON error-documents.

When a Mastodon API request returns an HTTP error status, it generally
also delivers a JSON error-document containing a string. This is a
much better error message than the plain HTTP code, because often it
goes into more useful detail. For example, if you have an auth failure
because you haven't confirmed the email address on your new account
yet, the HTTP error code can't tell you anything about email address
confirmation, but the error-document will. So we'll use those messages
in preference, if they're available.

Discriminate error types in login.

ClientError and ConfigError should be handled differently. The former
suggests you did something wrong in account setup, and you might be
able to recover by doing it again properly (e.g. not misspelling the
server hostname), so we print the error in the TUI and let the user
try again. But the latter probably means you have to sort out your
local account setup (e.g. XDG dirs aren't working, or %APPDATA% isn't
set), and that's more like the kind of fatal error where you quit the
client and fix it externally.

So I've made a new LoginError enum to act as the union of those two
types and also indicate which you have. ConfigError is now passed
back to terminate the TUI completely.

This also means I'm no longer abusing TopLevelError for the union
error type returned by e.g. confirm_registration_fallible. That was
bad in its own way because it prefixed 'mastodonochrome: error:' to
the error description as if it were reporting on the terminal.

Move saving of auth file into auth.rs.

Makes more sense there, right next to AuthConfig::load. And we were
doing it twice, so it needs to move _somewhere_ central.

Change the message for AuthError::Nonexistent.

"Not logged in" used to be correct, when we didn't support account
registration. But now the auth file can _exist_ while still being
logged in. So we should be more precise in the translation of this
error code: it really means <cfgdir>/auth is absent in an ENOENT sort
of way.

However, we shouldn't normally _see_ that message: it's one of the few
error cases that we detect programmatically and divert into a handler
for (to wit, the login flow).

Another run of 'cargo fmt'.

Sooner or later I'm going to have to start automating this. Otherwise
there will be too many random formatting changes mixed in to every
other patch I make.

Change my mind again about composing.

Composition activities should stack above reading files, but below
things to which you might pop out to get more information (such as
checking the username of someone to @mention). So I've given them an
Activity category of their own, which has at most one occupant (like
UtilityActivity) but is separate and just below Utility.

I'm still not sure this is right, but I think it's better than before.
I'll try using it for a while and see.

Rethink utility status of some activities.

ComposeToplevel and ComposeReply are very similar in this environment,
so I think it's wrong that one should be a utility activity and the
other not. The current status mimics real Monochrome, with
ComposeToplevel and ComposeReply corresponding to adding to a file and
sending a message to a user respectively; but in real Mono, those two
activities are much more different from each other than they are here,
so I don't think the same rule should apply.

Conversely, I'm promoting ThreadFile to a _non_-utility activity, on
the basis that all activities involving viewing a file of actual toots
ought to have the same status, or else it's confusing. In particular,
it's annoying to try to examine a user seen in someone's thread, and
then find you can't easily come back to the place you were at in the
thread itself.

Prettify username and email in account registration.

The username is now shown with its domain suffix, but doesn't make you
type that suffix. And the email is validated for basic syntax.

Keep persistent ActivityStates for everything on the stack.

This fixes the cases where temporarily going to another full-screen
activity failed to restore the in-progress state of the previous one.
In particular, nipping out to the utilities menu from composing a
post, and reading the server rules during account registration.

It's a shame; I'd have preferred to be deleting and recreating state
objects all the time, to ensure they had a well-defined amount of
internal state. But this needed less organisation. Perhaps I can come
back and do it better another time.

Fix failure to update fave/boost flags on boosts.

When you faved/unfaved or boosted/unboosted a status that you yourself
saw via a boost, the actual operation was happening successfully, and
the updated version of the _boosted_ status was going into our
Client's cache - but re-retrieving the _boost itself_ didn't include
the updated copy of the contained original post.

Rerun 'cargo fmt'.

Support registering a new account via this client.

This is provided as a second workflow on the TUI login page. You get
to enter a username, email address and password, and register your
account. You still have to respond to an email sent by the
server (just as much as logging in, it needs to know that you're
really the owner of that email address); this can be done by clicking
the link in the message, or pasting it into the login workflow,
whichever you think is easiest.

Clicking the link has weird effects if you set a redirect_uri of
"urn:ietf:wg:oauth:2.0:oob": the Mastodon web server actually tries to
redirect your browser to that URI, which causes at least Firefox to
prompt for an application to open it in, which is thoroughly confusing
and looks more like an error message than the indication of success it
actually is. So instead I've made it redirect to a page on my web
site, which is still a bit odd, but less odd than that.

Generalise EditableMenuLine's data update.

This allows the Data parameter type to bake in extra information which
is not affected by the editor providing it with new text. The idea is
to allow one password editor field to know about the password in the
other field, so as to display differently if they don't match.

Add SingleLineEditor feature to mask passwords.

The implementor of an EditableMenuLineData trait can now set the trait
constant SECRET to indicate that the editor should display the text
as ******* while editing. However, the trait is responsible for doing
the same masking itself when displaying the data in non-editing
mode.

(This division of labour is necessary so that display() can also apply
other display features, such as complaining that you haven't given a
password at all yet, or that they don't match. display() is the only
thing that can know _which_ of its output needs masking.)

Activity to view the instance rules.

This isn't used by anything yet, but it will be, when I implement
account registration directly from the client.

Align [^X] in menus left instead of right.

That way the actual letter lines up under other letters.

Rewrite the login step as part of the TUI.

Now it's reasonably user-friendly, and once you've logged in, you can
transition straight to actually using the client.

Also, this menu is a good place to put a 'register as new user'
alternative option.

Conditionalise a lot of the utilities menu

Add centring as an option to Paragraph.

Make MainMenu explicit at the top of the activity stack.

This will allow me to replace it with a different top-level activity
when we're in TUI login mode.

Refactor login so that Client does it all.

This sets up to allow login to happen within a Tui context, and also,
transfer seamlessly into a logged-in session once you've finished it.

Stop centrally prepending /api to URLs.

If I move the login logic into client.rs, then we'll need a few URLs
that start with /oauth instead of /api.

Make everything in AuthConfig optional.

Remove unneeded Auth::fqaccount() method.

I never ended up using it, preferring Client::our_account_fq().

Run through rustfmt.

If this is a widespread standard, I might as well start getting used
to it.

More TODO updates.

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.