My understanding is that this is actually a CLI, command line interface, instead of a TUI client. But I have not tried it, so I cannot say what this implies.
As @zge said, this tool is a CLI, not a TUI. This way, it can be used directly from the terminal, from a Vim plugin, from a TUI/GUI, from a script etc.
I don’t think you’ll ever get rid of this discussion unless you actually show a little example in the README. Configuration is very prominent, but you do that once. What’s interesting is how you use it - if it’s not a TUI, what the screenshot suggests. (Looks just like mutt).
It is really interesting what you say. I wanted to keep the README as minimalist as possible (to move everything to the wiki), but it misses the points you mention. Thanks a lot for your feedback!
as a stickler for these things - a CLI is a common (if not the most) common kind of TUI. If you don’t think so, where do you draw the line (and since it’s a CLI you can’t, and if it’s a TUI, it will be with line-drawing characters ;-)).
A CLI is not a TUI. A CLI is a command-line interface: interaction is through typing commands from a shell. 1 line = 1 command = 1 action. A TUI is a text-based user interface: interaction is through commands but also events like keyboard, mouse etc inside an application. Both show result as text, but they are used differently!
Your ‘Command’ is still through textual input that has a UI layer that is far from ‘character stream’ in its construction.
How do you think your command-line ‘Shell’ (not to be confused with ‘Shell’ as used in the Amiga as that was graphical, or ‘Shell’ as in surface behaviour rules in wayland) communicated to the outside world? how does it manage to provide tab-completion, readline edit controls moving the cursor around, history, colouring, highlights …
Any interactive command-line you run into in the vt100 etc. sense will come through as a TUI. If you’d see a slice of of input and output to/from vim/mc/himalaya/mutt/aerc or whatever, versus your shell (as in bash, …), you’d see that they mechanically operate on the same principles with the same instructions and control.
Yes, at a low level, CLI and TUI are very similar. But it’s not the point here. A CLI does not serve the same purpose as a TUI. You don’t use them the same way, that’s why there are different ;)
Previous discussion: https://lobste.rs/s/hheh5v/cli_email_client_written_rust
Anyone used this and can give a run down of how it stacks up against alternatives such as mutt, aerc, etc.?
My understanding is that this is actually a CLI, command line interface, instead of a TUI client. But I have not tried it, so I cannot say what this implies.
As @zge said, this tool is a CLI, not a TUI. This way, it can be used directly from the terminal, from a Vim plugin, from a TUI/GUI, from a script etc.
I don’t think you’ll ever get rid of this discussion unless you actually show a little example in the README. Configuration is very prominent, but you do that once. What’s interesting is how you use it - if it’s not a TUI, what the screenshot suggests. (Looks just like mutt).
It is really interesting what you say. I wanted to keep the README as minimalist as possible (to move everything to the wiki), but it misses the points you mention. Thanks a lot for your feedback!
as a stickler for these things - a CLI is a common (if not the most) common kind of TUI. If you don’t think so, where do you draw the line (and since it’s a CLI you can’t, and if it’s a TUI, it will be with line-drawing characters ;-)).
A CLI is not a TUI. A CLI is a command-line interface: interaction is through typing commands from a shell. 1 line = 1 command = 1 action. A TUI is a text-based user interface: interaction is through commands but also events like keyboard, mouse etc inside an application. Both show result as text, but they are used differently!
Your ‘Command’ is still through textual input that has a UI layer that is far from ‘character stream’ in its construction.
How do you think your command-line ‘Shell’ (not to be confused with ‘Shell’ as used in the Amiga as that was graphical, or ‘Shell’ as in surface behaviour rules in wayland) communicated to the outside world? how does it manage to provide tab-completion, readline edit controls moving the cursor around, history, colouring, highlights …
Any interactive command-line you run into in the vt100 etc. sense will come through as a TUI. If you’d see a slice of of input and output to/from vim/mc/himalaya/mutt/aerc or whatever, versus your shell (as in bash, …), you’d see that they mechanically operate on the same principles with the same instructions and control.
Yes, at a low level, CLI and TUI are very similar. But it’s not the point here. A CLI does not serve the same purpose as a TUI. You don’t use them the same way, that’s why there are different ;)
+1 for the
imap-passwd-cmdtrick, I’m stealing it ;)