Flow direction in performance GIF

[weilbith]

Hey,
sorry for opening an issue here. But this is not related to P10K itself, but I just saw it in its docs.
So how do you achieve the upwards flow direction in this GIF? I fail to find instructions how to manipulate the flow direction and get a fixed prompt. I don't want to have exactly the same setup, but pretty similar. Would be cool if you could simply point to me to some sources how to achieve that.
Thank your very much in advanced!

[romkatv]

Run this command to get cursor at the bottom of an empty screen:

clear; repeat $LINES print

Done :-) Now you have the "flow" from the gif.

Did I misunderstand the question?

[romkatv]

This gif is used here: https://github.com/romkatv/powerlevel10k#uncompromising-performance

Transient prompt is explain here: https://github.com/romkatv/powerlevel10k#transient-prompt. This section uses a similar "flow" (meaning that the cursor starts at the bottom of an empty screen rather than at the top).

[weilbith]

So I put this just somewhere in my .zshrc and it continuously works? 🤔 (I'm mobile atm, so can't test it right away).
How would I do it if I like to have it turned around? Means the prompt is always on top and the history goes down?

[romkatv]

So I put this just somewhere in my .zshrc and it continuously works?

I think you are confused. Try holding Enter for a while and then run echo hello followed by echo bye. Do you see what it does? Now look at the gif. It's the same thing. There is no magic, no difference.

Means the prompt is always on top and the history goes down?

How can you get history go down? Doesn't it always go up and disappear above the top boundary of the terminal window?

[weilbith]

Okay I totally misunderstood the GIF.

How can you get history go down? Doesn't it always go up and disappear above the top boundary of the terminal window?

Exactly. But it would be more healthy. Consider that it is likely that the terminal is full most of the time. So you always have to stare at the bottom of the screen. Usually you set up your monitor so that the top edge is at a horizontal line with your eyes. And most other applications put the important/interesting stuff at the top or are better distributed over the center of the screen and usually are adjustable (e.g. scrolling, bottom margin, ...). So after all each of them is more convenient to work with than the console where you always stare at the bottom all the time. Also it does not make sense to push the monitor up, since this would affect all other applications.
A couple of people in the internet seem to be interested in such feature as well. But apparently there is no solution yet.

Anyways this is not related to this "issue"/thread. I just thought this was a hint to an approach how to achieve that goal. Thank you very much for helping me so fast and kind. 🙏
Sorry that I annoyed with something like that. 🙈

[ghost]

FWIW, almostontop keeps the prompt on top of the screen, although the history still goes up. To change it to go down, my only guess would be to fork and change zsh's code, as I believe that this is built-in to zsh, so you likely couldn't change it with a plugin or anything like that.

[romkatv]

[...] the history still goes up

This is because in English (and most other languages) text flows left-to-right and top-to-bottom.

If you execute the command print -l 1 2 && print -l 3 4, the only sensible output is this:

1
2
3
4

If you execute print -l 1 2 followed by print -l 3 4, the only sensible way to present this sequence of events in the terminal is this:

% print -l 1 2
1
2
% print -l 3 4
3
4

This and only this presentation allows you to read history sequentially in the natural order of the English language: left-to-right and top-to-bottom.

The fact that prompt is displayed below the output of the last command is a good thing. The two most important pieces information are located close to each other, thus minimizing eye movement.

The only problem I see in the traditional shell UI is that the location of prompt is not constant. When you open a new terminal or clear the screen, prompt is at the top. With each command it moves closer and closer to the bottom. Once it reaches the bottom it stays there for awhile, until something (perhaps zsh completion menu) pushes it back up. This non-constant prompt position means you cannot set up your terminal window in such a way that it's always convenient to look at the most important information in it -- the prompt and the output of the last command.

This issue has been bothering me enough that I've configured my own shell to always have prompt at the bottom. When I open a new terminal, or clear the screen, prompt is at the bottom. Completion menu opens as an overlay window above the prompt line, so prompt doesn't get pushed up. I've positioned my terminal window(s) in such a way that looking at the bottom is most comfortable. Looking at the top can be straining but I only need to do that occasionally and never for a long period of time.

You can see how it works in this cast:

This looks similar to the transient prompt demo with one major difference: Prompt doesn't get pushed up on Ctrl+L, Tab or Ctrl+R (the latter is not shown in the cast).

[weilbith]

@romkatv wow that is pretty cool. Thanks for sharing it with us! 🙏
I must admit that I'm especially annoyed by the movements caused by completion. This is even more annoying with narrow panes in TMux. So how do you do the pop-up this looks amazing! And also your "stay at the bottom" is cool. While I still would like to try my approach (which isn't possible as it seems), I would like to give yours a try. Could you point us to the key parts of your setup or link the according plugins/options?

[romkatv]

I'm using this: https://github.com/romkatv/zsh4humans/tree/v5. Note that this is a bleeding edge unstable dev branch, so I cannot recommend that you use this code. The latest stable version (documented at https://github.com/romkatv/zsh4humans) doesn't have the "overlay" or "stay at bottom" features.

If you have docker installed, you can try it out without affecting your real zsh environment. See https://github.com/romkatv/zsh4humans/tree/v5#try-it-in-docker.

The code is at https://github.com/romkatv/zsh4humans/tree/v5. It's very complex.

[weilbith]

I hope that is not too unkind, but can't you point to more detailed parts? As I remember zsh4humans is a complete opinionated setup of zsh. But I just want to take a single (actually two) features out of it. I mean so I need to invest the time to research your setup there and find what I need.
Or is it so deeply nested inside and hard to identify/extract?

[romkatv]

I hope that is not too unkind, but can't you point to more detailed parts?

I would if I could.

As I remember zsh4humans is a complete opinionated setup of zsh.

It is a complete setup, yes. I'm not trying to convince you to switch. You've asked how my shell is configured and I've given an honest answer. You are welcome to copy over some parts of it or use the ideas.

Or is it so deeply nested inside and hard to identify/extract?

Yes. You can find some info in romkatv/zsh4humans#35 (comment) and all comments that follow it. Also here and the following comments: romkatv/zsh4humans#57 (comment). You can also look at commits in zsh4humans v5 after it was branched off from v4. The vast majority of them are for this feature. All commits in https://github.com/romkatv/tmux and https://github.com/romkatv/tmux-bin are also for this feature.

If you are already using tmux, you can do something much simpler to achieve a similar effect. See https://github.com/Aloxaf/fzf-tab/wiki/Configuration#fzf-command and https://github.com/Aloxaf/fzf-tab/blob/master/lib/ftb-tmux-popup. Most of the complexity in my code stems from the fact that I don't want to use tmux. I like native terminal scrollback and tabs.

[weilbith]

Cool thanks for all these hints. I'll try to follow them and see what I can achieve.
Yes, I'm using TMux already and I'm excited to finally us is new pop-up feature.
But your links to fzf related project confuse me: is this pop-up only working in combination with fzf? Or does it also work for the default completion menu of zsh? Because I'm using zsh-autocomplete and this has a high priority to me.
Anyway, I'll figure that our soon. Looking forward to dig into the code this evening.

[romkatv]

is this pop-up only working in combination with fzf?

tmux 3.3 is adding a new command called popup. If you have it installed, see man tmux. This command is not specific to fzf or to zsh. More generally, there is nothing in tmux that's specific to fzf or to zsh.

I've linked to fzf-tab to show an example of code that puts zsh completion candidates in a tmux popup.

[weilbith]

Yes, exactly. My thoughts were different, but you answered my question anyway. Thanks.

Would be cool do develop a plugin that is doing it in more general manner. So kinda split it: one that does the fzf stuff independent of the floating feature and then a second one that does the pop-up. Let's see what is possible.

[romkatv]

Would be cool do develop a plugin that is doing it in more general manner. So kinda split it: one that does the fzf stuff independent of the floating feature and then a second one that does the pop-up. Let's see what is possible.

Don't these two parts already exist? The first is fzf-tab (allows using fzf instead of menu in zsh completions) and the second is tmux popup (allows executing any command in a small tty that's painted as a popup in the parent tty).

Or did you have something else in mind?

Going back a bit:

While I still would like to try my approach (which isn't possible as it seems) [...]

Can you elaborate on your approach?

FWIW, I've experimented with an extension of my current setup that keeps prompt at the bottom visible at all times as if the terminal window was split in two, with the bottom (small) part always showing prompt, and the top (larger) part showing output of commands and command history. My experiments have shown that this is doable.

[weilbith]

Or did you have something else in mind?

A plugin that brings zsh its completion menu to a pop-up. Since I don't trigger the menu manually, but zsh-autocomplete does so, I'm not sure if this must be done there (I don't hope so) or this could be a more general approach for the completion menu.

Can you elaborate on your approach?

So I try to follow your example and do it visually:

$ # active prompt at top, history below empty as usual

$ # the '>' identifies an history command, plain lines are just command output in the history
> echo foo
foo

$ # we are still on top, the history reads bottom to top
> echo bar
bar
> echo foo
foo

FWIW, I've experimented with an extension of my current setup that keeps prompt at the bottom visible at all times as if the terminal window was split in two, with the bottom (small) part always showing prompt, and the top (larger) part showing output of commands and command history. My experiments have shown that this is doable.

Interesting approach. Would love to see how this looks like, especially in combination with the completion pop-up.

[romkatv]

Or did you have something else in mind?

A plugin that brings zsh its completion menu to a pop-up.

This might be possible but I'm not sure.

Since I don't trigger the menu manually, but zsh-autocomplete does so, I'm not sure if this must be done there or this could be a more general approach for the completion menu.

Do you have some specific ideas for the more general thing?

Can you elaborate on your approach?

So I try to follow your example and do it visually:

Thanks, I think I understand.

In one of my previous comments I mentioned that this is not a good UX because you cannot read history linearly.

Compare regular history, which you can read linearly from left-to-right and top-to-bottom:

> ls -1
foo
bar
baz
> cat foo
hello
world
and
goodbye
> rm foo

$ █

And here's the same history in your setup:

$ █

> rm foo
> cat foo
hello
world
and
goodbye
> ls -1
foo
bar
baz

In order to read this history you need to read from ls -l down, then move your eyes up to cat foo and read down, then again move eyes up and read down, etc.

Another downside of this approach is that it puts prompt far away from the bottom of the last command's output. Here's what I mean. Suppose I run just one command -- make -- and it fails. Normally it would look like this:

> make
gcc a.c -o a.o
gcc b.c -o b.o
gcc c.c -o c.o
gcc d.c -o d.o
gcc e.c -o e.o
gcc f.c -o f.o
gcc g.c -o g.o
error: g.c:12: syntax error

$ █

I can see the error close to prompt. This is true even if make has produced so much output that it doesn't fit on the screen.

Here's how the same output would look with prompt on top:

$ █

> make
gcc a.c -o a.o
gcc b.c -o b.o
gcc c.c -o c.o
gcc d.c -o d.o
gcc e.c -o e.o
gcc f.c -o f.o
gcc g.c -o g.o
error: g.c:12: syntax error

The error is far away from the point to which the user is looking (the prompt). If there was a lot of output, the error may not even be visible on the screen.

Even if you had complete control over the terminal and shell code, "prompt on top" doesn't seem like a good idea.

Would love to see how this looks like [...] in combination with the completion pop-up.

Completions look exactly the same as in the demo I've posted earlier.

More generally, everything looks exactly the same when zle is active. The different is only when zle is not active. In other words, when a command is running.

Here's how the terminal looks like when running a command in a normal shell:

> ls
foo
bar
baz
> sleep 42
█

Note that there is no current prompt.

And here's how it looks in my experimental shell, in which prompt is always visible:

> ls
foo
bar
baz
> sleep 42
█

$

This works better with a ruler above prompt because it makes it clear that the window is split into two panes and that the top pane is used by commands and the bottom pane is used by prompt:

> ls
foo
bar
baz
> sleep 42
█
-----------------------------
$

If the command outputs something, the window above the prompt scrolls but prompt stays frozen. This is similar to tmux status bar.

[weilbith]

This might be possible but I'm not sure.

I have way too less knowledge about the internals of Zsh. And if even someone like you who is really into the details don't know, I'm afraid its not possible at all.
I mean it looks like a quite complex problem. But I don't know how much Zsh provides already to make this possible. To me this are major steps to take. The first is to allow that the completion menu content can get forwarded to an external command. This is responsible to open a pop-up if there is non yet open and display/update the displayed content there. Second would be then to enter this window, allow the same navigation as for the completion menu (with all its options) and trigger the completion based on the selection.

Do you have some specific ideas for the more general thing?

Well, I'm not sure how your question is meant. So let me phrase what the goal is. Floating windows are for me always (NeoVim, i3, ...) the chance to keep the current layout clean and open/show something temporally without disturbing the more stable underlying structure. That said I would wish that the completion menu in Zsh does not affect the current prompt location, nor the whole history as it is displayed without completion. So for example when you have a terminal fully filled with history content and your prompt is at the very bottom, the completion menu would push the prompt and the history upwards. I would rather have it like in an text editor with completion functionality. There I get a hovering window on top of the text without affecting the editors buffer at all.

In one of my previous comments I mentioned that this is not a good UX because you cannot read history linearly.

Thank you very much for your good argumentation. I think you have a really good point, especially with your long arguments. For some reason I was more in the thinking of short/clear structured commands like ls or cat.
So I guess your approach with the line at the bottom is a nice approach I like to test myself. Let's see how I can achieve this.

[romkatv]

Good luck. Please post an update if you implement something you like.

[weilbith]

Sorry to abuse this issue, but I have no communication channel to contact him else. Please unsubscribe it getting annoyed and possible. Maybe we can switch to Gitter chat if there is some interest for further discussions.

@marlonrichert do you have some knowledge/ideas to share how to achieve the completion pop-up feature of this issue? (it started as a sub-thread here)

[marlonrichert]

@weilbith Sorry, no idea. I don't use Tmux. 🙂

[weilbith]

That's sad. ^^
But that doesn't matter too much. Any knowledge about Zsh it's completion menu that would allow to print and control it somewhere "else" than below the prompt?

[marlonrichert]

You can have a look at how fzf-tab does it: It monkey patches compadd to collect the completions, then displays them in a Tmux popup.

[romkatv]

I don't think this answer's @weilbith's question. You cannot just put zsh completion menu in a tmux popup the same way fzf-tab does it with fzf.

[marlonrichert]

You cannot just put zsh completion menu in a tmux popup

No, you cannot put the completion menu there, but you can still list the actual completions there, using some other tech, such as fzf’s menu.

[weilbith]

Well I still want to you use your autocomplete plugin. That is a must for me. The feature discussed here would be amazing if possible as described. But not at the costs/trade off.

[ghost]

It feels like this is getting off-topic. This was a question about a gif in a repo about a zsh theme about how if a piece of zsh code could provide a feature. Now were talking about tmux popup tab completion, which sounds cool, but is off topic. If you two could get on maybe Gitter like how @weilbith suggestied, that might be nice. I'm still interested, don't get me wrong, but this isn't what Github issues were designed for, so I think switching wouldn't be an awful idea. If you would prefer talking on this, thats fine, just a suggestion, but it feels that this getting off-topic isn't what issues are for.

[romkatv]

Serendipitous discussions have sparked many an improvement. I don't mind exploration of ideas in this issue. Anyone who's bothered is free to unsubscribe.

[ghost]

Ok. Like I said, just a suggestion. And by the way, dang that was fast!

[marlonrichert]

Well I still want to you use your autocomplete plugin. That is a must for me. The feature discussed here would be amazing if possible as described. But not at the costs/trade off.

@weilbith Feel free to experiment and build something. It's all open source, after all. 🙂