himalaya
himalaya copied to clipboard
soywod
Implement the TUI
I'm not a rust developer but I saw this: https://github.com/fdehau/tui-rs It's also based on crossterm but it looks like that it has already some "widgets" for the TUI.
Hello @soywod I'm interested in helping you with the TUI.
But I'm pretty new to rust. I've just finished the book yesterday and I played a little bit with tui-rs so my "code quality" sucks probably, but I'm ready to improve that. Do you have any suggestions where I could start (if it's fine for you) and which TUI-crate you'd like to use? I don't know how far I can get, but I'd like to give it a try at least.
First of all, thank you for wanting to contribute to the project!
I think tui-rs is a good choice. For the backend I would go with crossterm, but you are free to use whatever.
The only thing I would like to keep is the monorepo. I would like to keep all tools related to Himalaya in this repo (vim plugin, emacs pluging, UI, TUI, GUI etc). For now, Himalaya has only one Cargo.toml, I think some refactor is necessary to turn it into a monorepo with workspaces.
The only thing I would like to keep is the monorepo.
Yes please! That's a really good idea IMO, splitting up things only add unnecessary complexity!
I think some refactor is necessary to turn it into a monorepo with workspaces
Why? There's no need for that! Just add a subcommand for launching the tui! And, if you want, make the feature a compile time option.
No need for a workspace IMO!
I'd say that I'll create a subdirectory will all the TUI stuff. I'll call it probably tui.
Just add a subcommand for launching the tui!
I agree to that. Calling himalaya --tui for example.
Calling
himalaya --tuifor example.
Or even less to type: himalaya tui
Why? There's no need for that!
I was thinking to use directly Rust functions instead of using the JSON API. So I think it makes sense to have workspaces to manage those crates, what do you think @matthiasbeyer?
Why not have the GUI feature in the source of himalaya itself?
Because I'd like to separate it from the "backend" of himalaya, so we have a clear structure in the future as well. By the way, do you mean TUI instead of GUI? My idea was it to create a src/tui directory and put everything related to the TUi there.
Ah, yes to all points (GUI was caused by autocorrect on my phone, sorry)
@soywod so it's fine for you, if I (try) to implement it in a extra-directory: src/tui?
Yes! Take a look into the draft and scroll down to the last messages.
TL;DR
The PR-Draft isn't given up. It's just stopping at the moment because:
- I'm waiting for my new laptop (I don't want to develop on a USB-Stick anymore... neovim is even lagging in the TTY....)
- We'll improve the API code of himalaya because otherwise we'd need to refactor more and pretty often which could become annoying.
Then the TUI implementation can be continued!
In the mean time, I implemented my own TUI in bash. You need sed, sd, w3m and fzf. Add the following to your bashrc:
alias stripcolors="sed 's/\x1B\[[0-9;]\{1,\}[A-Za-z]//g'"
# $1=email ID
# $2=flags
hread() {
himalaya $2 read -t html $1 | w3m -T text/html
}
# $1=flags (ignore $1 in sd capture group)
hmenu() {
hread $(himalaya $1 | stripcolors | fzf | sd '^(\d{1,10})\s│.+' '$1') "$1"
}
Example usage:
$ himalaya
UID │FLAGS │SUBJECT │SENDER │DATE
6659 │ │Your Twitch Account - Successful Log-in │Twitch │<censored>
6658 │ │Your Twitch Login Verification Code │Twitch │<censored>
[ ... ]
$ hread 6659 # Open the email in w3m for easy viewing
$ himalaya -a otheraccount # Pass additional flags
UID │FLAGS │SUBJECT │SENDER │DATE
6659 │ │Your Twitch Account - Successful Log-in │Twitch │<censored>
6658 │ │Your Twitch Login Verification Code │Twitch │<censored>
[ ... ]
$ hread 6659 "-a otheraccount" # Pass additional flags
If you're too lazy to enter the email ID 6659 into a terminal, use hmenu:
$ hmenu # Lists all the emails in a TUI, select the email you want to view with arrow keys and enter
$ hmenu "-a otheraccount" # Pass additional flags
I also made my experimental TUI using skim and w3m
sk --ansi -c 'himalaya list -s 200' --preview "himalaya read {1} -t html | w3m -T text/html" --bind 'space:execute(himalaya reply {1}),esc:execute(himalaya delete {1}),ctrl-f:execute(himalaya forward {1})' --reverse --header-lines=2
Press space to reply
Press esc to delete
Press ctrl+f to forward a message
I also made my experimental TUI using skim and
w3msk --ansi -c 'himalaya list -s 200' --preview "himalaya read {1} -t html | w3m -T text/html" --bind 'space:execute(himalaya reply {1}),esc:execute(himalaya delete {1}),ctrl-f:execute(himalaya forward {1})' --reverse --header-lines=2Press
spaceto reply Pressescto delete Pressctrl+fto forward a message
Cool! Why not fzf?
@timsofteng definitely. There's no specific reason over fzf. Here is a new version now using fzf.
mail(){
export FZF_DEFAULT_COMMAND='himalaya list -s 200' &&
fzf --bind "space:execute(himalaya reply {1})+reload($FZF_DEFAULT_COMMAND),esc:execute-silent(himalaya delete {1})+reload($FZF_DEFAULT_COMMAND),ctrl-f:execute(himalaya forward {1})+reload($FZF_DEFAULT_COMMAND),ctrl-a:execute(himalaya attachments {1})" \
--preview 'himalaya read {1} -t html | w3m -T text/html' \
--header-lines=2\
--header 'Space: Reply, Esc: Delete, Ctrl-f: Foward, Ctrl-a: Attachments, Ctrl-c: Exit'\
--layout=reverse\
--ansi
}
I think would be great to implement some kind of cache Himalaya ( Now it's a bit slow cause every time we need to do an IMAP request)
Edit: Add reload
Hint
If anyone has more time and motivation (I don't mean it in a bad way) than me, then you can create your own fork and implement the TUI because at the moment I'm pretty much exhausted by my university and I'd like to complete my eduacational project first... and... sadly the code in my fork isn't up to date anymore...
I'm sorry about this and everyone who were believing in me doing this... ._.
Currently I can't give an exact date or time when I can get back to this and I also don't want you guys to wait for me although I haven't done that much in the last days/weeks for himalaya.
Don't worry @TornaxO7, this is an open source project were people help whenever they have time. No pressure. I personally have more free time these days, I will try to continue your work. Thank you anyway for your initiative!
What is the status of TUI ? Many people would be interested to use himalaya interactively, without vim.
What is the status of TUI ?
For now, the TUI feature is in pending state. I would like to finish other issues before taking back this one (like backends for example https://github.com/soywod/himalaya/issues/295).
Many people would be interested to use
himalayainteractively
To be honest, it is not the main aim of himalaya. The main purpose of this tool is to interact in a CLI way with your emails (console, script etc). I see the TUI feature as a bonus. I hope you understand.