Feedback on navigation

[mrusme]

I received excellent feedback on the navigation through replies on Superhighway84 (thanks for that!) and understood that these would be some great improvements (to be extended):

• Use Tab for switching between lists
• Use Ctrl-Left/-Right for switching between lists
• Use single keys over Ctrl+Key combinations for easier navigation
• Add ? key shortcut to display navigation help

Feel free to add to this list. I will start implementing a few things soon.

[aaroncommand]

Perhaps the best way to implement this would be via options that override the defaults in the config file -- as something like the hotkey for switching between lists seems like a user preference.

[apatheticposture]

Unsure if this counts as navigation but it sort of does: Messages which have been read should ideally be color-coded to show that, if possible.

Also, as to scrolling to the top (newest messages):

If I page up all the way, it will stop at the newest message, but if I arrow-up it loops back around to the oldest message.

The page-up option where it stops is good but I am unsure about looping back around to the oldest if you arrow-up all the way. A few times I've done this and lost track of where I was. A Ctrl-key combination for newest and oldest might be a better option, and just lock arrow-up or page-up to stop at the newest message without looping around.

[derricw]

Also, as to scrolling to the top (newest messages):

I find that most terminal apps use g to go "home" to the top of the list, so that's what I would suggest.

[derricw]

Soon, there will be so many groups that it will be tedious navigating them with j and k. I would suggest some way to filter them, or a way to specify one with fuzzy matching (something like fzf could be useful for that).

[Jonty]

The arrow-looping is extremely annoying, I would really prefer it to stop at the top or bottom.

[mrusme]

@Jonty check out v0.0.6, it's been removed. :)

[mrusme]

Read/unread is coming along nicely. However, I believe it is useful to have a "mark all as read" shortcut. I would follow mutt here, however, by default it uses Ctrl+R and ESC+r to mark a current thread/subthread as read, which conflicts with Ctrl+R for refresh.

Hence I believe before implementing more shortcuts, the input handling needs to be refactored in order to allow the user to configure custom shortcuts. With the way tview works, I found it incredibly cumbersome to think of a way to map a config file to the actual input handler. If anyone has experience with something like this built with tview I'd be interested to know how a decent implementation could look like.