Support for docked windows in the various layouts at each edge

[trygveaa]

I'm working on a kitten for incremental search in the backlog using the marks feature, but I've run into some issues.

Currently I'm starting the kitten with new_window @ kitty +kitten search.py, but I haven't found a way to specify the size of the window. I can resize it afterwards, but that looks bad and pushes the text in the original window upwards more than necessary. Additionally, it's not possible to resize it to less than 6 lines (I would like it as a single line).

Here it what it looks like:

Another issue is that if I have multiple windows in kitty, the resize command will resize those too.

Additionally, it would be nice if the kitten could get the instance for the window it was started from (and possibly the other windows in the tab). Currently, I have to run kitty @ ls to find the windows in the same tab. Then I have to run all the marker and scroll commands via the remote protocol because I don't have the window instance available like you have if you run a kitten in the same window. Or is there some other way to do this that I haven't found?

This is the script I have so far: https://github.com/trygveaa/kitty-kitten-search/blob/master/search.py

[kovidgoyal]

kitty's layout system does not really support fixed size windows, and in more complex layouts such as the grid layout or the new splits layout there is no way to have this at all.

In order to implement it one would need a "docks" system for the layouts where you can have windows "docked" at the edges. Similar to how it is done in tiling window managers. This is a fair bit of work, since all layouts would have to modified for it, but should not be too hard.

I'm not sure what you mean by the "window it was started from"? The window that was active before you run the kitten in a new window? Hw are you running the kitten, via launch?

Also taking a step back, is the reason you want to do this, rather than using scrollback_pager because scrollback_pager does not allow live searching of the output? Of course it could just be because it's cool :)

[trygveaa]

In order to implement it one would need a "docks" system for the layouts where you can have windows "docked" at the edges. Similar to how it is done in tiling window managers.

Right, yes, this seems like a good solution.

I'm not sure what you mean by the "window it was started from"? The window that was active before you run the kitten in a new window? Hw are you running the kitten, via launch?

Yes, the window that was active before I ran the kitten. I have mapped a key to new_window @ kitty +kitten search.py, so I'm running the kitten by pressing that key. Not sure if this is the best way, or if I could do it another way?

Also taking a step back, is the reason you want to do this, rather than using scrollback_pager because scrollback_pager does not allow live searching of the output? Of course it could just be because it's cool :)

There are multiple reasons:

• Live incremental search
• Typing less characters. In less you have to press /, then the search term, then enter. And you have to do this each time you want to change the search.
• Being able to use the hints kitten after searching for some text. This is not possible when using scrollback_pager.
• Scrolling to the last match automatically if it's out of view. With less you have to press N after searching if the search term is outside of the current view. I haven't implemented this in the kitten yet, but it's a goal.
• Continuous search of live output is also a nice feature you get with this kitten.

[kovidgoyal]

So the way to do this would be to use launch rather than new_window

https://sw.kovidgoyal.net/kitty/launch.html

this is the new unified command for all kinds of child process creations. You can see its implementation in launch.py

I have just implemented support for passing the id of the active window in it.

On Sun, Feb 23, 2020 at 05:24:11AM -0800, Trygve Aaberge wrote:

In order to implement it one would need a "docks" system for the layouts where you can have windows "docked" at the edges. Similar to how it is done in tiling window managers.

Right, yes, this seems like a good solution.

I'm not sure what you mean by the "window it was started from"? The window that was active before you run the kitten in a new window? Hw are you running the kitten, via launch?

Yes, the window that was active before I ran the kitten. I have mapped a key to new_window @ kitty +kitten search.py, so I'm running the kitten by pressing that key.

Also taking a step back, is the reason you want to do this, rather than using scrollback_pager because scrollback_pager does not allow live searching of the output? Of course it could just be because it's cool :)

There are multiple reasons:

• Live incremental search
• Typing less characters. In less you have to press /, then the search term, then enter. And you have to do this each time you want to change the search.
• Being able to use the hints kitten after searching for some text. This is not possible when using scrollback_pager.
• Scrolling to the last match automatically if it's out of view. With less you have to press N after searching if the search term is outside of the current view. I haven't implemented this in the kitten yet, but it's a goal.
• Continuous search of live output is also a nice you get with this.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kovidgoyal/kitty/issues/2391#issuecomment-590068445

--

---

Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

---

[trygveaa]

Thanks!

Btw, you wrote @kitty_active_window_id and @kitty-active-window-id in the documentation and @active-kitty-window-id in the code.

[trygveaa]

@kovidgoyal: Do you think the docked windows should be for each of the inner windows, at the edges of each inner window. Or do you think it should be for the whole tab, at the edges of the tab/os window?

I started implementing docking to the edges of the tab, but then I realized that might not work well with the stack layout. One issue with it is that when moving to the next/previous window one would only be able to move to the docked window from the neighboring normal windows in the list of windows. Another potential issue is that the search kitten would probably need to change which window it searches in when one changes window.

The first issue could be solved by adding a new shortcut for switching between the docked windows and the normal windows, and let next/previous window only switch between windows of the same type.

For my search kitten, I think it would make sense to have docked windows for each of the inner windows if it only searches in that window, and to have docked windows for the whole tab if it searches in all the windows.

[kovidgoyal]

Well there are several things to think about:

1. There can potentially be multiple docked windows per edge

2. Docked windows should not be resizable and probably should not be moveable

3. Do we want per window/per tab docked windows or both? I would incline towards having both. The launch command can take a --dock-type argument which can take choices: tab-bottom-edge, window-bottom-edge, tab-top-edge, etc.

4. What happens when a user tries to open an overlay window over a docked one? For example unicode_input or hints?

5. How do we navigate between docked windows and normal windows using the keyboard??

6. If they are per window docks what happens in stack layout when changing windows? Do the per window docks get hidden too?

7. Do the move to neighbor operations work over docked windows? I incline towards yes

8. With per window docks there should probably be a shortcut to easily switch between window and its associated dock. Maybe kitty_mod+tab

9. Do the switch to window by number shortcuts work for docked windows??

On Wed, Feb 26, 2020 at 02:13:10PM -0800, Trygve Aaberge wrote:

@kovidgoyal: Do you think the docked windows should be for each of the inner windows, at the edges of each inner window. Or do you think it should be for the whole tab, at the edges of the tab/os window?

I started implementing docking to the edges of the tab, but then I realized that might not work well with the stack layout. One issue with it is that when moving to the next/previous window one would only be able to move to the docked window from the neighboring normal windows in the list of windows. Another potential issue is that the search kitten would probably need to change which window it searches in when one changes window.

The first issue could be solved by adding a new shortcut for switching between the docked windows and the normal windows, and let next/previous window only switch between windows of the same type.

For my search kitten, I think it would make sense to have docked windows for each of the inner windows if it only searches in that window, and to have docked windows for the whole tab if it searches in all the windows.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/kovidgoyal/kitty/issues/2391#issuecomment-591671333

--

---

Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

---

[trygveaa]

1. There can potentially be multiple docked windows per edge

Yes, I agree.

2. Docked windows should not be resizable and probably should not be moveable

I agree that they should have a fixed size and not change when new windows are opened or the os window is resized, but shouldn't the user be allowed to resize them and change the order of the docked windows?

3. Do we want per window/per tab docked windows or both? I would incline towards having both. The launch command can take a --dock-type argument which can take choices: tab-bottom-edge, window-bottom-edge, tab-top-edge, etc.

Yeah, both would be the best solution, it's just more work.

4. What happens when a user tries to open an overlay window over a docked one? For example unicode_input or hints?

Not sure. If it's docked to a window, maybe we can open the overlay over both the window and the docked windows. If it's docked to the tab, I'm not sure. Maybe open it over the whole tab?

5. How do we navigate between docked windows and normal windows using the keyboard??

I guess either they are included in the normal next/previous window list, or one can switch between the normal window and the docked with a specific key.

6. If they are per window docks what happens in stack layout when changing windows? Do the per window docks get hidden too?

Yes, I think the per window docks should be hidden and the per tab docks should remain when switching between windows in the stack layout.

7. Do the move to neighbor operations work over docked windows? I incline towards yes

I see four possibilities here when those operations are triggered from a docked window:

• They move between windows of both types
• They move between the docked windows in the same window
• They move between all the docked windows.
• They ignore the docked windows and moves to the next normal window when triggered from a docked window.

Which did you mean?

8. With per window docks there should probably be a shortcut to easily switch between window and its associated dock. Maybe kitty_mod+tab

Sounds good. If there are multiple docked windows, I guess it should switch to the one that were last active?

9. Do the switch to window by number shortcuts work for docked windows??

Probably not? I'm not sure.

[kovidgoyal]

On Thu, Feb 27, 2020 at 08:15:01AM -0800, Trygve Aaberge wrote:

2. Docked windows should not be resizable and probably should not be moveable

I agree that they should have a fixed size and not change when new windows are opened or the os window is resized, but shouldn't the user be allowed to resize them and change the order of the docked windows?

I think that's unnecessary complication, docks are typically used to display fixed information. There is no need for them to be resizable. You could potentially make them moveable, but then you have to deal with not just re-ordering but also changing edges/moving from per tab to per window, etc. Simpler to just have them fixed.

4. What happens when a user tries to open an overlay window over a docked one? For example unicode_input or hints?

Not sure. If it's docked to a window, maybe we can open the overlay over both the window and the docked windows. If it's docked to the tab, I'm not sure. Maybe open it over the whole tab?

This will require some experimentation, I dont know what is feasible off the top of my head. In the docked to window case, using the window is obv fine. In the docked to tab case, it might actually be better to open overlay windows as new normal windows.

5. How do we navigate between docked windows and normal windows using the keyboard??

I guess either they are included in the normal next/previous window list, or one can switch between the normal window and the docked with a specific key.

There is also the use case of a statusbar type dock window which should not be able to receive focus and be excluded from navigation.

7. Do the move to neighbor operations work over docked windows? I incline towards yes

I see four possibilities here when those operations are triggered from a docked window:

• They move between windows of both types
• They move between the docked windows in the same window
• They move between all the docked windows.
• They ignore the docked windows and moves to the next normal window when triggered from a docked window.

Which did you mean?

If we allow dock windows to be re-orderable then between dock windows and possibly changing edges. Otherwise no-ops.

8. With per window docks there should probably be a shortcut to easily switch between window and its associated dock. Maybe kitty_mod+tab

Sounds good. If there are multiple docked windows, I guess it should switch to the one that were last active?

Yes, last active would be most useful I think.

9. Do the switch to window by number shortcuts work for docked windows??

Probably not? I'm not sure.

Not a strong preference here, we'll see.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/kovidgoyal/kitty/issues/2391#issuecomment-592043606

--

---

Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

---

[gregflynn]

Sorry for the necrobump here but I wanted to throw out a (possibly stupid) idea in this vein. This thread and the other dupe threads try to solve the "tmux status bar" feature request using kitty windows of a fixed size and fixed location within the window layout, which causes extra complexity in the layout code to account for these new fixed windows.

Would it be better/easier to implement this feature the same way visually we have the tab bar? For instance in a simple example, if i have the tab bar set to the top, and the space it would use if set to the bottom could render the status-line.

Some definite caveats I'll throw out:

• Assumes/requires everyone's status-line to be a single line, less flexible than the window layout approach but do we need that flexibility?
• What if i want both on top or bottom? we could punt on supporting this until someone asked but feels a little dirty, could 50/50 split the bar in that case or something else

[kovidgoyal]

Personally I'd rather fix this properly and with full flexibility, one and for all. Using an additional tab-bar might work ok for statusbar like displays but there are more use cases than that, and I dont want to end up building multiple solutions for it.