Allow terminal input pane to be pinned to top (vs bottom) + ergonomics

donaldguy commented 3 years ago

Problem: Ergonomics

I quite like warp's innovation of splitting/stickying the input / current prompt separate from the scrollback buffer – allowing thus a command to be assembled from info one may need to be scrolled back to without losing sight of it

The current implementation has a nice analogy to the interface of e.g. slack, and is probably (though not definitely) the correct default. ( It also is correct almost certainly for use cases of Warp on the ~Jupyter model, though then editable cells will I guess end up wherever as one scrolls)

It is, however, worse ergonomically, at least for a full screen-height terminal. As is stands I am often turning my neck down, and it would be preferable to keep my eye line toward the top of the screeen when writing commands

borrowing/modifying diagram from https://www.gvsu.edu/officeergonomics/computer-monitor-8.htm to somewhat belabor/exaggerate the point:

monitor_angle

(this bothers me enough that using other terminals I somewhat compulsively run clear (or ^L) even when it would likely be useful to keep output on the screen for other reasons)

Solution: Be more like a modern browser omnibar

Continue the logic (I presume you followed) in assigning ⌘L to Focus terminal Input, and (offer the toggleable UX option of) treat(ing) the input buffer as more akin to the URL bar in a browser:

Mockup

➕ Advantages

In addition to the ergonomics, this offers the advantages of:

you can grow down instead of growing up; when adding multi-line inputs or showing options for history & completions, you cover longest-ago rather than most-recent output, which – absent scrolling – seems preferable.

The history pop-up is thus more familiar UX resembling, again, like a web browser– though it will follow that you need to swap the recency semantics of ↓ and ↑ compared to shell defaults.
warp generally presenting more familiarly like other terminals when freshly opened / empty:

but of course if you include keyboard shortcuts et al as currently it will still be easily differentiable / distinct
this pinning possibly lends itself more naturally to splits – as going by the existing tab design (as well as traditional window chroming), metadata / title is gonna be at the top, and is useful to keep that in close proximity to the command line if people are switching back and forth

For a horizontal split you could also conceivably pin top split's input to top and bottom split's input to bottom – which might create a better visual separation (?, it might just be confusing though)

➖ The New Problem / Opportunity

Obviously, if you do this, you lose the nice current natural transition to a yellow-border-cell for a long-running command and scroll-up to next prompt when command is done.

Unless you went all-in on reversing the history direction (on the block level; which honestly wouldn't be crazy - imo, but would certainly take some getting use do), you also have lost a natural way to hide the prompt while the last command is running

My answer to this problem is: don't hide it.

Either:

leave it in place at the top as a frozen (set of) commands akin to the current input portion of an I/O cell

this offers the advantage of leaving it visible even if/after the command has output more than a single screen of text

(and indeed you can leave it in place over a curses/TUI style app, conveniently offering thus a what was the invoking command line - and/or the current one you can refetch it if the program is allowed to change it (like /proc/n/cmdline), or you could tree-it-down like the iterm status bar:

) AND/OR (or being do 1, but 2 on explicit focus - again kinda like how browsers do current vs being-type URL)
leave an interactive buffer in place there, allowing people to potentially formulate their next command while their previous potentially-long-running command is still going. There is really no harm, nor likely much additional work (other than being prepared to update prompt when its ready?), in doing this until such as time as the command is actually submitted for exec. At that point I see at least three options for how to treat it:
1. Just refuse with a warning bell, symbol, or other indication that you can draft-but-not-submit while another command is running (the first time a user does this its probably worth an alert modal explaining in more detail)
2. (offer to) run it in a new tab (or split / pane once those are implemented). If you wanted to go extra on this, you could try to (or secretly have already, for every command? - one always left over ) clone(d/ forked) the underlying shell and thus bring along all the relevant environment variables, working directory, etc. But in most cases, I think spawning a new shell off dotfiles would likely be good enough
3. Leaning harder on the browser behavior analog, doing this could SIGINT (escalating to SIGKILL, or not) the running process and start the new one soon as the prompt is seen

Either of these things could, of course, also be done (and I think would be useful) with the current bottom-stuck input pane, but again - I think they make more UX sense with the outside context people have from using a web browser (other than, you know, qutebrowser, etc users where the bottom one makes equal sense).

There is still gonna be some awkwardness to output scrolling up from the bottom for a command run at the top, but

I think the yellow-border for running, red-border for failures is clean enough to make it make sense—though it may behoove one to add also a (transient) green (or warp-cyan) type for (only last) successfully run command
or you could switch up behavior so that a command on start gets a clear full-height buffer below with output beginning at the top and grows down til scroll, potentially compacting (re-introducing most recent previous scrollback) when done if it never fills the screen
or as I parenthetically said above, I don't think it would be unreasonable (though ~bold) to fully swap up the history direction (on a block/execution level, presumably leave it as is in output of commands) so that new commands' blocks are inserted on top (initially as a single line, growing down until scroll) with older commands falling off the bottom and being scrolled down to to (also with a swap of ⌘↑ and ⌘↓ vs the present)

With this design (with menus unfurling down rather than up as a rule) it might also make sense to unify the terminal input and command palate (possibly, like vscode having, an initial > indirect into pallete commands, since it hardly makes since imo to redirect stdin before a command) but ¯\(ツ)/¯

hariso commented 2 years ago

To me, it's also a matter of habit.; ) It would make it much easier for me to switch from another terminal if I could have the input at the top.

filipemonteiroth commented 2 years ago

any word from the authors whether this will be implemented or not?

zhaogang92 commented 2 years ago

Any update on this?

marcelloromani commented 2 years ago

I like having the ability to occasionally CTRL+L to clear the terminal and start from the top

The fact that I'm always forced to type at the bottom is quite annoying to be honest, and currently one reason for me to stop using Warp.

I know habits are hard to break (had I applied the same mentality to PC vs Mac I would not be typing on a Mac right now), so I'm open to "well, challenge your habits!" response - totally fair - but for now it's annoying to not have the ability to type on top.

duarteocarmo commented 2 years ago

For me it's an ergonomic issue. I downloaded the app, noticed there was no way of controlling if the prompt was on top or bottom, and instantly uninstalled.

orshemtov commented 2 years ago

I'm relying on this feature to continue using Warp

ghandic commented 2 years ago

Likewise +1

clo4 commented 2 years ago

Reversing the direction of blocks would actually be really unique. It's basically impossible to do with any other terminal, but is at least possible in warp because it already has the concept of blocks.

Controls would be inverted - use down to select the previous block instead of up, etc.

jaredh159 commented 2 years ago

this is bugging me a lot too. i like to clear my terminal and then be typing from the top, not the bottom. might be a deal breaker for me.

alemorm commented 2 years ago

I agree with all of the comments, I've been enjoying Warp so far but this issue is a make or break for me. No technology is worth having neck issues over...

diocletiann commented 2 years ago

This is especially frustrating because it's such an easy fix. The input box has already been separated, you just have to move it to the top of the window. Showing the buffer top to bottom with blocks would be even better but just moving the input box would be a huge improvement.

jfeeny commented 2 years ago

+1 for having the option to have the input prompt at the top of the window and reversing the block history. huge ergonomic benefits, and I think perhaps also a more natural way of reading command output from the beginning rather than needing to scroll up.

gauravtatke commented 2 years ago

+1. Difficult to look at bottom to type anything

imizao commented 2 years ago

+1. Also, I make a suggestion that the user can customize the input window height.

gurleensethi commented 2 years ago

Switching back to my previous terminal, this issue is a deal breaker. Please comment on this issue once the feature is added.

effinsky commented 2 years ago

do add the feature, please :) makes for a real bad impression not to have it. otherwise, a sweet thing you got there. impossible to work with for me at the moment, though with the input at the bottom.

syuraj commented 2 years ago

I am surprised that they didn't think of it in the first place. 🤔🤔

michlimlim commented 2 years ago

Hey all, eng from the warp team here. Thank you for your feedback. I hear you that this feature would help a lot with ergonomics and fit within your current muscle memory. We are currently experimenting with what a pinned-to-top experience could look like. We will let you know how the decision goes.

aribouius commented 2 years ago

+1.

diocletiann commented 2 years ago

Hey all, eng from the warp team here. Thank you for your feedback. I hear you that this feature would help a lot with ergonomics and fit within your current muscle memory. We are currently experimenting with what a pinned-to-top experience could look like. We will let you know how the decision goes.

Thanks! I hope you find a way to release this option because it would instantly convert your app from borderline unusable to best in class, from an ergonomics standpoint.

nguyenquangtin commented 2 years ago

Yes, this is really helpful in ergonomics points.

navin22 commented 2 years ago

+1 It will be very helpful

adimixx commented 2 years ago

+1 would love to keep using warp, hoping that this solution will be implemented

Daksh14 commented 2 years ago

+1

elviskahoro commented 2 years ago

Hey everyone,

We know it's an issue especially ergonomically. It would require a very large engineering lift and would likely create a class of unforeseen consequences / bugs, so the we're punting it for now, it wouldn't happen within the next quarter. Will circle back though once there's more major updates.

eyayaw commented 2 years ago

Just installed and the first thing I did was try to drag the input box up to the top, then tried reset, and go to the settings looking for an option to toggle off. Now I know it's warp's design choice. Please add this feature. Thanks.

donaldguy commented 2 years ago

An unhelpful/prohibitively-expensive "workaround": I bought one of these https://www.lg.com/us/monitors/lg-28mq780-b and if warp is on the top half of the screen, the input box is probs about where I want it 😅

sanjaytime commented 2 years ago

+1 , need this as an option.

AlessandroVol23 commented 2 years ago

+1 I need that as well :D

smushy129 commented 2 years ago

this is the one thing that is preventing me from replacing my terminal

brunobely commented 2 years ago

I also face this problem, but I'm not sure I like the proposed solution. I think it would be an interesting solution, to be clear, but I would also love to have Warp behave like other terminal applications: start at the top, and move down the screen as command blocks take up space.

toaol commented 2 years ago

+1, it could be optional, that's the only thing I'm not happy so far.

praveenpuglia commented 2 years ago

After waiting for a really long time to see this coming up and struggling with the current layout, I am sadly giving up on Warp and going back to iTerm. I look forward to see Warp provide this as an option sometime in the future and not abandon the request.

javivi02 commented 2 years ago

Also hoping that it can be invested, until then I stay with iTerm. A shame because I really like the idea and the interface is very fluid

pscott31 commented 2 years ago

+1 from me this would be great, especially on a tiling window manager I always have to open up some dummy window underneath to prevent me craning my neck to look at the bottom of the screen when I'm typing

anton-ivlev-bz commented 2 years ago

+1 from me also. This is the only thing preventing me from using Warp.

Cerya commented 2 years ago

+1 Add this option please..

mb8z commented 2 years ago

That's the only thing stopping me from giving it a proper try

vrohlfs commented 2 years ago

+1 on this

tiennguyenskedulo commented 2 years ago

+1

stellarsquall commented 2 years ago

+1

When presenting (especially virtually) it is inconvenient to have the cursor at the bottom of the screen, where OS toolbars and issues with screen resolution can obscure the prompt. Having the option to move it to the top would make this my default

filipemonteiroth commented 2 years ago

+1

I moved back to iTerm2 because of that. I really haven't met any developer that uses a terminal that the command prompt is fixed to the bottom.

marcelloromani commented 2 years ago

Alacritty is a good one I've stumbled upon.

On Wed, Oct 5, 2022 at 7:07 PM Filipe Monteiro @.***> wrote:

+1

I moved back to iTerm2 because of that. I really haven't met any developer that uses a terminal that the command prompt is fixed to the bottom.

— Reply to this email directly, view it on GitHub https://github.com/warpdotdev/Warp/issues/22#issuecomment-1268768166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB35MDNFKQGZCIJSQV64AKDWBW7XXANCNFSM5ASPIBHQ . You are receiving this because you commented.Message ID: @.***>

azeemhassni commented 2 years ago

+1

canhtran commented 2 years ago

+1

BingshuiDa commented 2 years ago

+1

codrutzu commented 2 years ago

+1

Loved the first interaction with it, but for me specifically it just doesn't work with the prompt at bottom since a small part of the bottom of my monitor is overlapped by a part of the laptop's pane. Definitely coming back after this is implemented.

RajKamal2013 commented 2 years ago

+1

CoffiDev commented 2 years ago

+1 I feel better knowing that I am not the only one thinking "this is the thing preventing me from migrating to warp".

As a NTH I would love this feature that @SeparateRecords mentioned

Reversing the direction of blocks would actually be really unique. It's basically impossible to do with any other terminal, but is at least possible in warp because it already has the concept of blocks. Controls would be inverted - use down to select the previous block instead of up, etc.

MatthewCushing commented 2 years ago

I love the terminal but I use my terminal standalone on my LG Dual Up monitor (a portrait view type monitor). Having the prompt and all new blocks at the bottom is too much of an annoyance =/. The top of my monitor is almost level with my second monitor (ultra wide on a stand) while the bottom of the monitor forces me to look down. I'd much rather it be closer to eye level by allowing us to move the prompt and recent blocks top to bottom instead of bottom to top.

warpdotdev / Warp