-
-
Notifications
You must be signed in to change notification settings - Fork 770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for popup window #270
Comments
This feels similar to the existing overlay functionality that powers the launcher menu, tab navigator and copy mode functionality. It probably wouldn't be that difficult to provide an overlay that can spawn a program; likely a lot easier than the full on split feature. |
Bumping this up a bit as I find myself wanting this feature. I'm happy to try to take this on as a learning experience if I can be pushed in the right direction. |
I'd love to see a PR for this... I was eyeing this issue the other day; with the recent changes in the renderer it's now feasible to produce inset overlays similar to what is pictured in the OP, and have them layer over the top of the normal set of panes. Previously, we could only literally render the precise model from the mux into statically allocated quads; we can now dynamically allocate those as needed. I think all of the difficult parts of this issue are nailing down the precise semantics of how the popup fits into the mux model. The tmux implementation seems to do something very special with the popup in terms of how it is modeled so there is precedent for something to be awkward(!). The At a high level what I think is needed is:
The hard parts:
The tmux issue seemed to have some support for arbitrary/static text in the popup, but it looked like that got simplified away later in the issue. I'm generally in favor of running a command in the popup, but not so much for arbitrary/static text showing up there. Defining how the mouse interacts with the popup is another tricky-ish area: right now there's a lot of math coupled between the renderer and mouse, but ab8c8dc introduces a way to de-couple that and make it a bit easier to route the mouse to the right place. You could punt on that for an MVP if you don't allow for an inset popup and instead make it fill the window space, then all the math would be unchanged and you'd simply route the events to the popup rather than the active pane/overlay that they currently use. Defining how the keys work with the popup is also important: it sounded like tmux had some special rules for that. There should probably a key assignment that explicitly kills a popup so that there is a sane way to get out of it, but otherwise, it should pretty easy to simply route key presses to the popup pane; the key handling logic already does this sort of thing for the active pane/overlay, so it should be a fairly contained change. |
Super helpful and gives me a good starting point to give something a go. I'll try to start on something after hours later this week. I'll more than likely open up a DRAFT WIP PR sooner than later to see if I'm totally missing the mark. I think for first approach we keep things as simple as possible:
|
The following article mentions an interesting use case for tmux popups. I never got around to trying it, but had it bookmarked for later. https://blog.meain.io/2020/tmux-flating-scratch-terminal/ Killing a popup shouldn't be the only way to close a popup, there are cases where we need to hide it temporarily. It would be nice if you could expose actions for creating/hiding/opening/killing popup, that can be assigned to custom key bindings. |
I also love the idea of having popups and probably a way to control positioning etc. I just came across https://fig.io/ which could take this to the next level ;-) |
Was there a reason the PR in #1059 was abandoned? This is such a useful feature |
This really the only thing making me hesitate to drop tmux for wezterm's multiplexer 🤔 |
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm interested in working on this. @malkomalko did you ever consider picking this back up, and would it be fine if I used your prior work as a starting point? |
@happenslol I'd be happy to help create a PR for this with you if you'd like to work together over a weekend or something |
Sounds cool, I would like that! What's your preferred method of communication? Let's pick this up somewhere else so we don't spam the thread here :-) |
If you have Matrix, you can message me at |
I tried starting from the PR that was closed but it seems like a lot of it doesn't apply anymore. |
Hi @wez is there any way to fund/sponsor this feat request? |
@protiumx yeah, if you take a look at my GH sponsors page at the one-time amounts: https://github.com/sponsors/wez?frequency=one-time&sponsor=wez |
It looks like #5576 is pretty close now? |
tmux recently add
popup
support. Would be great if wezterm has similar support.https://blog.meain.io/2020/tmux-flating-scratch-terminal/
Useful when you need to create temporary scratch window such as for fuzzy search, git status and so on. Partially aligns with split window feature request #157.
Might be having something like neovim's multigrid would make it easier to implement. https://neovim.io/doc/user/ui.html#ui-multigrid
The text was updated successfully, but these errors were encountered: