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:
(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:
➕ 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:
- 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)
- (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/
fork
ed) 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
- 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 ¯\(ツ)/¯