On Fri, Mar 13, 2020 at 10:53 AM Tobias Bengfort <tobias.bengf...@posteo.de> wrote: > I am surely not the first to come up with this[1], but I think many X > tools could be replaced by TUIs running in st. Think about this quick > example (dmenu replacement):
I myself pondered the same thing some while ago, however I didn't proceed onto experimentation, mainly because I use `rofi` which (like `dmenu`) has some other advantages that `st` doesn't like for example window placement relative to currently active monitor, etc. However another disadvantage of `st` + `fzf` as a replacement for `dmenu` / `rofi` / etc. is perhaps performance. For example I've tested the following (`heredoc` is part of the `execline` suite, it is used as a `bash` replacement in your snippet, and I use it both for `dmenu` and `rofi` in order to keep the comparison fair): ```` time st heredoc 0 $'a\nb\nc\n' fzf time heredoc 0 $'a\nb\nc\n' dmenu -l 10 time heredoc 0 $'a\nb\nc\n' rofi -dmenu ```` And the following is the `user` and `sys` timing for these: * for `dmenu` around 20ms + 5ms; * for `rofi` around 35ms + 10ms; * for `st` + `fzf` around 50ms + 20ms; Although even `st` + `fzf` feels snappy enough, I did feel some lag compared to the other. > The interesting thing about this is that you replace all the complexity > of X (e.g. font rendering) with all the complexities of the terminal > (e.g. ANSI escape codes). I don't think this would be a major issue. In fact I think more simple applications might sprout that would reuse `st` as a "display server". > I believe there could be changes to st that would make this kind of > usage simpler, e.g. an option for full-width or to automatically attach > stdin/stdout to the command (fzf in this case). Yup. As mentioned earlier, `rofi` and `dmenu` have some advantages in the window placement area that are essential. However I believe this would quickly become out-of-scope from `st`... Ciprian.
