From 6010327f0ad8773e9db397e9a3d942f8c1dabf6b Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Sat, 13 Jan 2024 13:34:46 +0000 Subject: [PATCH] TODO updates, including a bug I just noticed. --- TODO.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/TODO.md b/TODO.md index bb2ceea..afb3952 100644 --- 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`, 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 -- 2.30.2