TODO updates, including a bug I just noticed.

diff --git a/TODO.md b/TODO.md
index bb2ceea369166cbf659ee83632e3b5a11690c8b9..afb395240ffdd4e97bdacc51ce1183e2a08ec2d7 100644 (file)
--- a/TODO.md
+++ b/TODO.md
@@ -4,6 +4,17 @@ When you favourite a post that you saw via a boost, the [F] doesn't
 appear. Presumably some confusion between the original status and the
 boosting status.
 
+If you're in the post-compose menu, press [ESC] to go to the utilities
+menu, then [RET] to return to where you were, the client panics
+because `TuiLogicalState::new_activity_state` was trying to go into
+the post-compose menu without the previous activity having passed it a
+`Post`, because the activity in question was the utilities menu which
+hasn't got one. I think probably I need to fix this by keeping draft
+posts in a `RefCell` in the `TuiLogicalState` rather than passing them
+as arguments. That would also make it easier to view suspended ones in
+a drafts menu, and to reuse the same mechanism for editing things
+other than posts, such as your account bio.
+
 # Missing features
 
 ## Verbose help
@@ -12,6 +23,17 @@ 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.
 
+## Line recall
+
+Single-line editors should retain history, and support [UP] and [DOWN]
+to page through it. In particular, that means if you try to examine a
+user and mistype their name, you can recall the failed attempt and
+edit it, rather than having to try again from scratch.
+
+Again, this will need some persistent inter-activity state in a
+`RefCell` in the `TuiLogicalState`. Also some UI thought about what
+history should be shared with what.
+
 ## Error handling in the UI
 
 Real Monochrome has an 'Error Log' at ESC Y V, containing records of
@@ -268,6 +290,18 @@ And it's harder for the user, because even after this reports success
 (with a user token for the app to keep) they still have to wait for a
 confirmation email and follow the link from it.
 
+Even so, it would be nice to do this. I'd like to do registration (and
+also ordinary login) by actually setting up a Tui, so that you get it
+in the same visual style as everything else, and we can format the
+server rules nicely and let the user page up and down them. But there
+are type-checking implications in the current code structure: `Tui`
+owns a `Client`, which unconditionally owns a set of login details. We
+could make `Client` instead own an `Option<AuthConfig>`, but then
+_everything_ in normal operation would have to either unwrap it or be
+prepared to throw a `ClientError`. The alternative is to make some
+part of `Tui` generic, and for login or registration, use a parameter
+type other than `Client`. Either is awkward.
+
 ### General search
 
 The [search API