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!

diff --git a/TODO.md b/TODO.md
new file mode 100644 (file)
index 0000000..748723f
--- /dev/null
+++ b/TODO.md
@@ -0,0 +1,312 @@
+# Missing features
+
+## Verbose help
+
+The status lines at the bottom of the screen are all very well, but
+real Mono generally supports a `?` keystroke that expands each one
+into a full page of explanation.
+
+## Error handling in the UI
+
+Real Monochrome has an 'Error Log' at ESC Y V, containing records of
+errors that happened in relation to your particular connection, such
+as when you tried to read a file but a backend error happened on the
+server. We should have one of those, and use it to handle failure to
+retrieve things you were trying to read.
+
+This is already marked in the code with multiple FIXMEs:
+
+* the `result.expect` at the end of `new_activity_state`
+* the handler for the existing `LogicalAction::Error`, which currently
+  just beeps
+* the handler for the return value of `Client::process_stream_update`
+* the error in `PostMenu::post`, although if the error is recoverable
+  (e.g. by editing the text and retrying) then the Error Log is
+  overkill and we should redisplay the `PostMenu` with the message
+* errors in `get_user_to_examine` and `get_post_id_to_read`, although
+  again if it's just 'no such thing' then the Error Log is overkill.
+  Should only be for 'help, the server is totally confused'.
+
+Each of those should instead catch the error, make an Error Log
+record, and transfer you to the error-log viewer with a beep, just the
+way Mono did it.
+
+## Tracking what you've read
+
+When you restart Mastodonochrome and open a feed, it ought to put in
+view the first thing you haven't yet read in that feed. This means
+tracking what _is_ read during run time, and saving it to a file in
+the config directory.
+
+(Prerequisite: a means of atomically replacing that file with the new
+version each time you overwrite it, to prevent data loss. I think
+[`tempfile::NamedTempFile::persist`](https://docs.rs/tempfile/latest/tempfile/struct.NamedTempFile.html#method.persist) is probably the tool for that job.)
+
+Similarly, when the client automatically moves you into the Read
+Mentions field because a new mention has arrived, it should
+automatically jump the position to the first unread one.
+
+## Reading
+
+### Sensitive-content markers
+
+Currently we ignore whether a post is marked as sensitive: it doesn't
+show up at all in the UI.
+
+We should _at least_ display the sensitive-content tag, because it's
+not unheard of for people to use it as a post title, and write the
+rest of the toot in the assumption that you saw it, so that it might
+not even make sense without.
+
+Probably better to go all the way, and actually hide the post until
+told otherwise.
+
+### Polls
+
+If someone posts a toot containing a poll, we should show it, and
+offer an option to vote in it.
+
+An expired poll should show its results.
+
+## Posting
+
+### Posting a whole thread
+
+I want an editor keystroke that introduces a toot boundary marker.
+Then you could post a multi-toot thread by editing it all in one go,
+with a clear idea of where the boundaries would end up; each one would
+be highlighted if it was going to end up too long.
+
+At posting time, each one would be automatically marked as a reply to
+the previous one, and of course the starting toot would still be a
+reply to whatever the whole thread was responding to (if anything).
+
+I think the way to represent this internally is to use a control
+character in the editor buffer and handle it specially while drawing.
+
+### Adding media
+
+Definitely need some way to add media attachments to a toot. I think
+again there should be a control-character representation in the
+buffer, and things in the middle of it should be identified as 'not a
+character boundary' (using the existing system for that) so that it's
+treated as an atomic thing.
+
+This will need some kind of file selector UI. Not sure whether that
+would be better as a straight BottomLineEditor for a filename with
+added tab completion, or a full-on full-screen filesystem browser.
+Perhaps just the former until anyone has effort for the latter.
+
+The `Instance` record from the server lists its supported MIME types
+for media attachments. I think the
+[`magic`](https://docs.rs/magic/latest/magic/) Rust crate will
+identify the MIME type of a candidate file, and we could use that to
+check whether the file is acceptable.
+
+The media record in the editor will also need to include a space for
+alt text, which you should be able to edit as part of the main editor
+buffer. Inserting a media attachment should hint strongly that you
+should fill that in, e.g. by putting the cursor in the alt-text slot
+and also showing a red error marker for 'no alt text here yet'.
+
+### Posting polls
+
+You should be able to post polls, again via some kind of internal
+editor markup that inserts magic delimiter characters.
+
+## Editor improvements
+
+### Block cut and paste
+
+There should be _some_ method of cut/copy/pasting a block of text,
+beyond the existing ^K cut-to-end-of-line.
+
+Real Monochrome's UI for this is moderately horrible, and in
+particular, works at the granularity of lines rather than characters,
+which is not a good fit for this client's auto-wrapping reimagining of
+its editor. So I don't know whether to stick with the most Mono-like
+thing I can, or redesign more significantly.
+
+### Importing a file
+
+Real Mono, for those privileged users with a shell login, has a
+keystroke (F8) to read a disk file and insert it into the editor
+buffer. That might well be useful here too.
+
+## Better handling of updates and streaming
+
+Currently we have exactly one streaming subthread, handling your home
+timeline and notifications. But it's also possible to stream other
+things: the public timelines (local and global), and hashtags. So
+perhaps while you're viewing one of those timelines we should start a
+stream thread to keep it up to date?
+
+This would also require having a way to shut the stream down again.
+Public timelines move fast, and you wouldn't want that stream to keep
+running forever just because you glanced into the timeline once.
+Communicating back to the stream thread to interrupt it in mid-read is
+probably too painful, but streaming connections generally deliver a
+periodic heartbeat, so perhaps an easier approach is to make a 'please
+shut down now' atomic flag of some kind, stick it in an `Arc` so it
+can be shared with the main thread, and have the stream thread check
+it whenever it happens to wake up anyway.
+
+Other things can be updated but don't have a streaming API. For
+example, if you're viewing a particular user's posts, it would be nice
+to append to _that_ feed too if they happen to post something while
+you're watching. So another thing we could do is to run a regular
+timer tick which wakes us up and makes us poll whatever feed we're
+currently watching.
+
+If we're going to have that poll, it should probably be unconditional,
+_even_ if there's also a stream running. Then it acts as a fallback if
+the stream gets hung up somehow.
+
+If a stream connection actually terminates, we ought to at least
+notice and log it; perhaps try restarting it after a while; but leave
+a decent delay so as not to hammer the server, and in the meantime,
+rely on the fallback poll.
+
+## Menu marker for new things
+
+In real Monochrome, files that have new things to read are marked in
+the menu by a red +. Perhaps at least the home timeline could usefully
+be marked that way.
+
+## URLs in Post Info
+
+Most Mastodon posts repeat the target of a hyperlink in the visible
+text, so you can just copy-paste from your terminal into a browser.
+But occasional posts (perhaps federated from other styles of
+ActivityPub?) do the more webby thing of having the link text and link
+target independent. In that situation you want _some_ way of getting
+at the URLs.
+
+An obvious place to list this would be in the [I] post info page.
+
+(Actually doing this is probably fiddly, and involves trawling the
+`RcDom` structure returned from `html2text`'s first phase.)
+
+## More logs
+
+Our logs menus are underpopulated.
+
+We should have a log of recent HTTP transactions (`Client` is already
+in good shape to record one); probably in the form of a list of
+one-liners of the form (datestamp, method + URL, status response), and
+for each entry, the ability to expand it to look at all the details.
+
+ESC L should go to a summary page showing general health info; in
+particular, whether streaming subthread(s) are currently working. Then
+the second L keypress goes to the actual log files.
+
+## Options key from the Examine User screen
+
+When you examine a user, pressing O should take you to a page of
+options.
+
+### Client and account configuration: ESC Y O
+
+If the user is you, then this menu sets client configuration. For
+example, the default language for your posts (if you want to override
+the one we get from the system locale). Maybe also UI options in
+future if we add any.
+
+It should also let you set server-side options about your account,
+such as your display name, flags like `bot`, and info fields.
+
+### Following/blocking/etc: ESC E [user] O
+
+If the user you're examining _isn't_ you, then you should get a
+different options page which sets your relationship to that user:
+following, blocking, muting (or undoing any of those)
+
+Definitely also the various sub-options of following, such as whether
+to include boosts, and which languages to include.
+
+## Outlying protocol features
+
+### Scheduled posts
+
+You can ask the server to schedule a post to go out later. This could
+be slotted in as another option in the post-composer menu.
+
+### Locked accounts
+
+You can lock your account so that people can only follow you if you
+give permission. We should support that:
+
+* support marking your own account as locked via the ESC Y O options
+  menu
+* if someone then sends you a follow request, make it possible to
+  receive it and act on it
+* support sending follow requests to a locked account
+
+### Registering an account
+
+There's an [API
+method](https://docs.joinmastodon.org/methods/accounts/#create) to
+_create_ an account on Mastodon. Perhaps that means we could support
+directly registering via Mastodonochrome, without having to first use
+the web interface?
+
+(Whether or not this is useful in the live Fediverse, it would
+certainly streamline setting up a handful of test accounts on a clean
+dev instance in a VM, which is a common activity during development!)
+
+But I'm not sure. The docs for that method say you're required to
+provide a user token. But how did you get one without already logging
+in as an existing user? I don't quite understand what the flow is for
+this.
+
+### General search
+
+The [search API
+query](https://docs.joinmastodon.org/methods/search/#v2) lets you send
+an arbitrary search string to the server, and request accounts and/or
+hashtags and/or statuses that match it. Also you can restrict the
+search domain to only people you follow, or to only one account
+(presumably so you can look up 'that toot I know Chris made last year').
+
+### Rate limiting
+
+HTTP responses from the Mastodon server generally seem to carry a set
+of headers along the lines of
+
+    X-Ratelimit-Limit: 300
+    X-Ratelimit-Remaining: 300
+    X-Ratelimit-Reset: 2024-01-04T19:50:00.318188Z
+
+If we actually paid attention to those, we could check them in the
+centralised `execute_and_log_request` function, and if the 'remaining'
+looked dangerously low, set a flag that would make us wait a bit
+before submitting the request. Then we should be proof against getting
+blocked by the server for accidental misbehaviour.
+
+### Server information
+
+The [Instance
+record](https://docs.joinmastodon.org/entities/Instance/) from the
+server includes information we could usefully show in a page
+somewhere. Like the `description` field, and the list of rules.
+
+There's also an [announcements API
+query](https://docs.joinmastodon.org/methods/announcements/) for
+announcements from the instance. We should probably pay attention to
+that. On client startup, check it for unread ones, and display those
+in the style of real Monochrome's MOTD.
+
+## Archive support
+
+The Mastodon web UI lets you download an archive of all your own posts
+from the user settings menu, in the ActivityPub file format. This
+appears to be a zip file containing a handful of JSON files and all
+your media (including avatar image and also anything you attached to
+your posts).
+
+It would be nice to be able to use this client to browse that archive,
+using the same UI as for reading the live server (restricted as
+appropriate where data isn't available). Perhaps even use it _in
+conjunction_ with the live server, so that when your posts are in
+reply to other posts, you can retrieve the replied-to posts from the
+live server if you need to remember what they were about.