Skip to content
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

get Window ID in same tab with only num #4165

Closed
xiangpeng2008 opened this issue Oct 29, 2021 · 51 comments
Closed

get Window ID in same tab with only num #4165

xiangpeng2008 opened this issue Oct 29, 2021 · 51 comments

Comments

@xiangpeng2008
Copy link

xiangpeng2008 commented Oct 29, 2021

Is your feature request related to a problem? Please describe.

https://github.com/jpalardy/vim-slime uses kitty @ send-text to send text from vim to other windows by providing "window id". But I can't find an easy way to get "window id": I could focus on wanted window and do echo $KITTY_WINDOW_ID and then focus back, but this is very manually and it becomes infeasible when there's running job on wanted window that I can't launch this bash command.

But num id is relatively easy to get: by pressing shortcut of "focus_visible_window", the number showing on each window is num+1

I can't use directly kitty @ send-text --match num, because num doesn't persist when window is moved, e.g. after swap_with_window.

Describe the solution you'd like
It would be helpful to have something like
kitty @ get-match --match <MATCH> [window id|title|cmdline|pid|env|cwd|columns|lines]

by providing window specific info to get other info like window id|title|cmdline|pid|env|cwd|columns|lines.

for example providing num to get window id.

@kovidgoyal
Copy link
Owner

kitty @ ls

provides you with all needed information to identify windows.

@xiangpeng2008
Copy link
Author

kitty @ ls

provides you with all needed information to identify windows.

but I didn't find num in kitty@ls

@kovidgoyal
Copy link
Owner

num is not a property of windows, it is used purely for visual window
selection. kitty @ ls will show you all window titles, pick your window
using that.

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 29, 2021

the problem is with 2 new white windows, say left and right, I can't tell which one in kitty@ls is the left one, and which is the right one.

"active_window_history": [
          11,
          10,
          12
        ],

I see we have above list from kitty@ls, it would also work if it could print a list of window id by order of num, which I could use to infer window id by its position in this list.

Could we have list of window id by order of num ?

@xiangpeng2008
Copy link
Author

@kovidgoyal actually what did you do in this commit to solve this issue and how to use this new commit ? I looked at your commit but didn't find it.

@kovidgoyal
Copy link
Owner

kitty @ select-window

@page-down
Copy link
Contributor

But I can't find an easy way to get "window id"
It would be helpful to have something like .. by providing window specific info to get other info .. for example providing num to get window id ..

$ kitty @ select-window --help
... Prints out the id of the selected window. ...

send-text-to-selected-window.sh

#!/bin/sh
set -eu
echo "Select the window that you want to send text to. (Timeout in 10s)"
KITTY_WINDOW_ID=$(kitty @ select-window --self --response-timeout=10)
kitty @ send-text -m window_id:${KITTY_WINDOW_ID} "text-to-send"

@xiangpeng2008
Copy link
Author

wonderful !

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 31, 2021

kitty @ select-window

This is a super cool design to just show the number on each window, and print corresponding window ID after my press on number key.

For example, kitty @ select-window shows

Screenshot 2021-10-31 at 11 23 37 AM

and after pressing 2, it outputs 4 which is the corresponding number of window id

Actually this is all I need.

Just for information, is it expected that if I do kitty @ select-window -m window_id:4 it still pop up number on each window to let me select ?
Screenshot 2021-10-31 at 11 27 01 AM

It should print directly 4, right.

@kovidgoyal
Copy link
Owner

-m is for matching tabs not windows. It will perform the select in the specified ta instead of the active tab.

@xiangpeng2008
Copy link
Author

-m is for matching tabs not windows. It will perform the select in the specified ta instead of the active tab.

I see, understood. This makes sense.

It seems there's a very small bug here, to produce:

  1. kitty @ select-window --response-timeout=3
  2. Do nothing and wait for 3 secs. The number showing on the windows will still be there, and it prints out Timed out after 3.0 seconds waiting for response form kitty
  3. Then do kitty @ select-window --response-timeout=5 again, the number on window won't pop anymore. And select-window stops working.

@page-down
Copy link
Contributor

What about adding timeout: float = 0 parameter to visual_window_select_action? Would add_timer work?

@kovidgoyal
Copy link
Owner

Should be fixed now.

@page-down
Copy link
Contributor

Should be fixed now.

# Tab 1
sleep 2 && kitty @ select-window --self --response-timeout=3

# switch to Tab 2
kitty @ select-window --self --response-timeout=3

After seconds, the visual window select on Tab 2 cannot be canceled.

@kovidgoyal
Copy link
Owner

576abec

@page-down
Copy link
Contributor

576abec

Still the same steps as before.
Although the visual window select on Tab 2 is cancelled, it cannot be cancelled after switching to Tab 1.

In addition to this issue:
I wonder if only the timeout of the corresponding tab should be canceled, and the other tabs that have not reached the timeout time should not be canceled and can continue to be selected.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Oct 31, 2021 via email

@page-down
Copy link
Contributor

Doesnt repro for me. How are your switching to tab 1? any click or key
press will cancel the existing visual select.

Use the mouse to switch tabs. Below is the screen recording.

There is another scenario:
If there are several select-window coming at any time in an uncertain order, it is not clear which task the selection is for.

  • task 1: preparing text... select-window
  • task 2: preparing text... select-window

If only one visual selection is available, then all previous ones will be cancelled. However, it is not known in the kitty interface which one is the last one. Especially when the command is sent from remote.

With --response-time=0, would it be better to block while the previous one is still being selected and then wait for it to finish before making the next selection? Also need to be able to let the user define the text e.g. --title and display it to distinguish between tasks.

@kovidgoyal
Copy link
Owner

Why would there be multiple selects coming in at the same time? Instead of complicating things, the answer is simply "dont do that".

Are you sure you are running from current master? because I cannot repro. If you create a select in tab 1 while there is an existing select in tab 2, the existing slect in tab 2 is canceled and the one in tab 1 is active. I just made a commit to ensure the tab with the select is made visible, that should make it clearer.

@page-down
Copy link
Contributor

576abec

Still the same steps as before.

Doesnt repro for me.

Are you sure you are running from current master? because I cannot repro.

Oh, I was testing the latest master branch at the time. 576abec I thought that's what you were referring to.

The latest master is currently working fine.

Why would there be multiple selects coming in at the same time? Instead of complicating things, the answer is simply "dont do that".

For within the same program, I can certainly send them one by one, after getting one result.

However, it is worth noting that remote-control can be initiated asynchronously by different programs. While the user is making a decision, for example, if another process is doing select-window, or if the user presses Ctrl+Shift+F7, can the other process get the select-window available status and initiate select-window as an atomic request (requesting a locked resource, then initiating it)? To ensure that other processes that are still waiting do not conflict.

What if the user is still deciding and is suddenly interrupted by another program?

Sorry, I didn't mean to complicate things, just something that immediately came to my mind when trying this feature. Thanks for your thoughtful explanation.

All of this is intended to make remote control more accessible in a truly "controlled" situation.

@kovidgoyal
Copy link
Owner

select-window is a user initiated action. Programs should only run it in
response to a user interaction. If you have programs that fire it off at
any time, that would cause lots of other problems, for example, you
could be typing something and a program could initiate it, which means
you either perform some unwanted action or lose a keystroke. Any such
programs need to be modified to behave responsibly.

@page-down
Copy link
Contributor

... If you have programs that fire it off at any time, that would cause lots of other problems, ... Any such programs need to be modified to behave responsibly.

Thanks, I totally understand. select-window is no different from commands such as send-text.

It cannot, and does not deserve a locked (waiting for user selection) state. As soon as select-window is launched, all previous ones will be cancelled and the new ones will be executed correctly.

So the last question is, is --title worth it? I can also spend some time if you think it's feasible, it doesn't seem too difficult.

@kovidgoyal
Copy link
Owner

It's already implemented

@xiangpeng2008
Copy link
Author

I still get similar issue

to reproduce:

  1. kitty @ select-window --response-timeout=3
  2. do nothing and wait 3 secs, I get Timed out after 3.0 seconds waiting for response form kitty, and numbers are still there
  3. again kitty @ select-window --response-timeout=3 , nothing pops up at first. But after 3 secs, numbers pop, I get Timed out after 3.0 seconds waiting for response form kitty in the same time.

My branch is newest
Screenshot 2021-10-31 at 2 19 02 PM

@page-down
Copy link
Contributor

Oh, for this feature, I forgot to mention that there is a typo that might be worth correcting.

'form' -> 'from'

The help document is corrected to be consistent with other commands (no spaces at the beginning), extra spaces are removed between lines, and no two spaces appear after merging lines.

diff --git a/kitty/rc/select_window.py b/kitty/rc/select_window.py
index a78d1896..5c3c1f50 100644
--- a/kitty/rc/select_window.py
+++ b/kitty/rc/select_window.py
@@ -24,7 +24,7 @@ class SelectWindow(RemoteCommand):
 
     short_desc = 'Visually select a window in the specified tab'
     desc = (
-        ' Prints out the id of the selected window. Other commands '
+        'Prints out the id of the selected window. Other commands'
         ' can then be chained to make use of it.'
     )
     options_spec = MATCH_TAB_OPTION + '\n\n' + '''\
diff --git a/kitty/remote_control.py b/kitty/remote_control.py
index 3f60a2d6..cd4e3c81 100644
--- a/kitty/remote_control.py
+++ b/kitty/remote_control.py
@@ -233,7 +233,7 @@ def main(args: List[str]) -> None:
         send.pop('payload', None)
         send['cancel_async'] = True
         do_io(global_opts.to, send, True, 10)
-        raise SystemExit(f'Timed out after {response_timeout} seconds waiting for response form kitty')
+        raise SystemExit(f'Timed out after {response_timeout} seconds waiting for response from kitty')
     if no_response:
         return
     if not response.get('ok'):

I still get similar issue

I can't reproduce this.

@xiangpeng2008
Copy link
Author

@page-down boss how did you record the screen ?

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 31, 2021

It's strange, I could always reproduce this issue.

Besides, there's a slightly more severe issue, to produce:

  1. kitty @ send-text --match id:'2' --stdin type echo 1, then we see echo 1 on window 2, so far so good
  2. Ctrl-D
  3. kitty @ send-text --match id:'2' --stdin type echo 2, nothing happened on window 2
  4. Ctrl-D
  5. kitty @ send-text --match id:'2' --stdin type echo 3, then the previously missing echo 2 appears on window 2, instead of echo 3

now

@kovidgoyal
Copy link
Owner

That does not repro for me either.

@page-down
Copy link
Contributor

how did you record the screen ?

https://github.com/justinfrankel/licecap

macOS & Windows only. GPL v2. Check the website for the release version.

I suggest focusing on the topic.

Besides, there's a slightly more severe issue

Under normal circumstances, nothing will be output with kitty @ send-text --stdin when the keyboard is pressed (left window 1). Since all the input has been captured by kitty.

You need to check the environment yourself, e.g. TERMINFO. Clear all files, codes, binaries, kitty configurations, shell configurations, etc. Starting over is a good option. I don't have any idea about your situation for now.

@xiangpeng2008
Copy link
Author

That does not repro for me either.

it's so strange, when I roll back to an earlier commit 13b900fa and rebuild, I won't have the kitty @ send-text --match id:'2' --stdin lag problem. But with newest commit, I have.

@xiangpeng2008
Copy link
Author

how did you record the screen ?

https://github.com/justinfrankel/licecap

macOS & Windows only. GPL v2. Check the website for the release version.

thanks @page-down

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 31, 2021

Besides, there's a slightly more severe issue

Under normal circumstances, nothing will be output with kitty @ send-text --stdin when the keyboard is pressed (left window 1). Since all the input has been captured by kitty.

And with earlier commit 13b900fa, which doesn't have lag problem, I still have output on left part, it just shows the input I typed.
earlierWorking

while with newest commit, I have that problem
now

@kovidgoyal
Copy link
Owner

That will take care of your problem: 4ffcbc8

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 31, 2021

Thanks Kovid, the kitty @ send-text --match id:'2' --stdin works like a charm now. And focus_visible_window now only shows number on non-activate windows :

  • upside is
    1. focus_visible_window works perfectly now with up to 11 windows, while before it was 10 ;)

Screenshot 2021-10-31 at 8 24 00 PM

    1. it switches directly to another without pressing number key when there are only 2 windows
  • downside is
    1. the number on windows doesn't persist anymore, I think I should get used to it

Just another small issue, kitty @ select-window doesn't work as expected.

select_window

@page-down
Copy link
Contributor

Just another small issue, kitty @ select-window doesn't work as expected.

Are you talking about not hiding the current window when using the remote control command? However this should be fine, as this gives the option to select this window itself.

downside is
the number on windows doesn't persist anymore

I like the original way of handling it, with numbers representing slot numbers, so that it is static and doesn't change with different activated windows.

When the number of windows remains the same, slot is static, you don't need to look at the numbers carefully each time you switch, just press the position number directly. This is a more efficient way of keyboard operation.

@kovidgoyal
Copy link
Owner

It's a tradeoff, you get one more window or you get static numbers. And note that if you already know the number you can just press ctrl+shift+number to switch to that window, no need for visual select at all.

And witht hre mote control if you dont want the active window to be selectable, add --exclude-active

@xiangpeng2008
Copy link
Author

Just another small issue, kitty @ select-window doesn't work as expected.

Are you talking about not hiding the current window when using the remote control command? However this should be fine, as this gives the option to select this window itself.

I mean kitty @ select-window doesn't work as it did nothing except outputting immediately Timed out after 60.0 seconds waiting for response from kitty

@xiangpeng2008
Copy link
Author

xiangpeng2008 commented Oct 31, 2021

It's a tradeoff, you get one more window or you get static numbers. And note that if you already know the number you can just press ctrl+shift+number to switch to that window, no need for visual select at all.

Here the number should be the static number ? Then it's not evident to know their numbers if focus_visible_window doesn't show static numbers ( need to add 1 for some of them).

Would be wonderful if it's configurable to show static number or not, if it doesn't need much change of code.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Oct 31, 2021 via email

@page-down
Copy link
Contributor

Would be wonderful if it's configurable to show static number or not, if it doesn't need much change of code.

You need to be careful when adding more options, regardless of how much code there is. Because it means introducing another possibility, another thing that needs to be tested and maintained.

I think when it gets to 10 more windows, the extra one is no longer relevant. If you really want more, you need other options.

This feature may seem redundant, but it's just a different way to achieve the same goal, giving the user the option to have visual feedback.

When I switched once in the current layout and learned the NUM of the corresponding position, I knew to jump directly by pressing ctrl+shift+NUM in the future. The current way does not give the user such a direct hint.

Guiding users to use more direct keyboard operations is also one way to improve the efficiency of operation.

I think it is better to use static numbers, in the same order as ctrl+shift+NUMBER, to stay in a consistent, predictable way.

@xiangpeng2008
Copy link
Author

Genius
We put alphabet after 10+ th windows, and static number is used
kitty @ select-window doesn't pop window number problem is also fixed.

Just it's slightly weird that numbers looks like to be cut a bit on the right side
Screenshot 2021-11-03 at 2 53 06 PM

Screenshot 2021-11-03 at 2 50 54 PM

@kovidgoyal
Copy link
Owner

should be fixed with: 3776077

@page-down
Copy link
Contributor

I found that the character were stretched in the y-axis direction, with a noticeable jaggedness. Normally it should be scaled equally. Can be reproduced on Linux and macOS.

macOS:

Linux:

Also the default UI font is currently used here, can I use the mono font set in the configuration? I must say I really don't feel any better about the default os window title font, so I'd rather use the user-configured mono font to keep the interface rendering as consistent as possible. Although in principle the GUI part should use UI fonts.

@kovidgoyal
Copy link
Owner

no, i'm afraid its going to be the default UI font. As for the vertical stretching its probably just a bug in the GL co-ord calculation, I will look at that sometime i have a spare moment

@page-down
Copy link
Contributor

Thanks. Now the numbers and characters are normal and look much better .

I found a new problem, executing select-window in the kitty shell does not return a value, it keeps getting stuck and eventually times out.

It seems that asynchronous responses require corresponding handling.

@kovidgoyal
Copy link
Owner

Should be fine now.

@page-down
Copy link
Contributor

I found some issues.

(1) Executing select-window --response-timeout N in the kitty shell gives an error.

TimeoutError: Timed out while waiting to read command response. Make sure you are running this command from within the kitty terminal.

(2) After initiating select-window (ctrl+shift+f7) and canceling it directly, the title cannot be restored.
Although clear_global_state() in boss.py is called, the title is still not restored. state.c set_os_window_title_from_window -> if (w->title && w->title != os_window->window_title) Does not appear to be in effect.

(3) After launching kitty @ select-window and closing the corresponding tab with remote control close-tab, select-window is still waiting for a reply. If you click on the current window with the mouse while the tab is already closed, you will receive a closed window id.

(4) After initiating select-window, clicking on any area in an other os window will also receive window id.

@kovidgoyal
Copy link
Owner

all these should be fine now.

@page-down
Copy link
Contributor

page-down commented Nov 7, 2021

all these should be fine now.

Thank you.

(3) After launching kitty @ select-window and closing the corresponding tab with remote control close-tab, select-window is still waiting for a reply. ...

For a tab that has initiated a window visual selection, when the tab is closed by remote control, the os window title remains Choose window and the selection is not cancelled. select-window is also still waiting for a response.

Failed to send resize signal to child with id: 2 (children count: 3) (add queue: 0)
Failed to send resize signal to child with id: 1 (children count: 3) (add queue: 0)

@kovidgoyal
Copy link
Owner

Yes there are ay number of remote control based actions that can mess up select-window, for example, changing the layout. The answer is simply dont do that.

@page-down
Copy link
Contributor

It might be worthwhile to find another time to deal with it afterwards, for the sake of enhanced robustness.

The close-tab caller may not know the status to determine whether the command should be issued or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants