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

Not copying to buffer when using clipse from a hotkey (in floating term) #45

Open
Lethaquell opened this issue May 14, 2024 · 16 comments
Open
Labels
bug Something isn't working

Comments

@Lethaquell
Copy link

Lethaquell commented May 14, 2024

Hello! I'm using Archcraft with bspwm.

I'm running listening from bspwmrc config as exec clipse -listen &
Then I have a sxhkdrc config for my keybinds, I've configured clipse to open in floating alacritty terminal as:

ctrl + super + v
  bspterm --float -e clipse

bspterm is basically an Alacritty term executing from bash script for managing float/fullscreen behavior:

image

The problem is:

  1. I'm copying stuff from browser/term -- it's getting to clipse history
  2. I'm opening clipse in floating mode using my keybind -- it opens and I can see history
  3. I'm pressing enter to copy any entry from clipse -- I can't paste it, buffer is empty
  4. But If I'll open clipse just im my regular term and do the same (copy any entry) everything is OK and I can paste things from buffer

Am I doing something wrong?

Quick UPD:

  • I've tried to open clipse as alacritty -e clipse and got the same (p3) behavior. I'll try to research furthermore
  • I've also figured out that as long as alacritty term is open -- I can paste (use buffer) entries from clipse. But just when I close the term -- buffer is gone
  • So for example I can use bspterm --float -e clipse keep and get anything from buffer that I want, sadly, right to the moment I close the term window. I'll stick to this "solution" for now
  • Also, all these 3 things true when I use alacritty. xfce4-terminal works just fine.
@savedra1
Copy link
Owner

Hey @Lethaquell 👋 thanks for raising this.

This is a new one! Which system clipboard utility are you using here? eg wl-clipboard, xsel, xclip etc. It's possible you're using something that only keeps clipboard history within a certain context. It may be worth testing this with something like:

alacritty -e wl-copy test
alacritty -e sh -c 'echo test | wl-copy' 

The recommended dependencies for this are wl-clipboard for wayland and xclip for xorg.

Could be worth checking what happens when you run the following also:

alacritty -e clipse -c test
alacritty -e sh -c 'echo test | clipse -c'

You could also try amending your script to add a short sleep after clipse has executed, or try -e sh -c clipse to see if that makes a difference.

I might look into adding an arg that will output what's been copied to allow a piping command like alacritty -e sh -c 'clipse -out | clipse -c' if that is found to be an issue with the system environment (Archcraft), though hopefully it's more simple than that.

@Lethaquell
Copy link
Author

Lethaquell commented May 15, 2024

Hello @savedra1! Thanks for reaching me back, appreciate it.

I'm using xclip cause bspwm works on xorg. I also have wl-clipboard installed, but for other WM's on Wayland. xsel isn't installed.

I've tried some tests eg:

alacritty -e sh -c "echo test | xclip -selection clipboard"
alacritty -e sh -c 'echo test | clipse -c'
alacritty -e clipse -c test

I've also tried to add sleep before executing clipse itself, but for now nothing is working for me.

To be clear, when I'm executing echo test | xclip -selection clipboard from xfce4-terminal it works just fine even after closing the terminal itself.

If there is anything I can also try -- I'll be grateful for any advises. I'll also investigate on problem furthermore on my spare time.

P.S. I might be entirely wrong, but can it be somehow related with OSC52 functionality/compatibility within alacritty?

@savedra1
Copy link
Owner

@Lethaquell I see 🤔

You could be on to something there with osc52, found this in the Alacritty docs:

This section documents the [terminal] table of the configuration file.

osc52 = "Disabled" | "OnlyCopy" | "OnlyPaste" | "CopyPaste"

Controls the ability to write to the system clipboard with the OSC 52 escape sequence. While this escape sequence is useful to copy contents from the remote server, allowing any application to read from the clipboard can be easily abused while not providing significant benefits over explicitly pasting text.

Default: "OnlyCopy"

you could try setting this to CopyPaste in the [terminal] section of your config?

@Lethaquell
Copy link
Author

@savedra1 it's on CopyPaste right now, I've tested these particular settings yesterday. Also tried Disabled and CopyPaste. I can confirm that my bspterm uses this config, not any other.

@savedra1
Copy link
Owner

Thanks for letting me know @Lethaquell

Seems like the connection to the X clipboard server is terminating along with the terminal session when alacritty is used. I'm wondering if there's a way to get this to persist to the main session clipboard by attaching an extra command to what you're currently using.

The copy mechanism used by clipse for X environments is xclip -in -selection clipboard but it's posible the -in arg is restricting it to the current terminal sesison Maybe something like this could help:

alacritty -e clipse | clipboard_contents=$(xclip -selection clipboard -o) && echo '$clipboard_contents' | xclip -selection clipboard

OR

alacritty -e "clipse; clipboard_contents=$(xclip -selection clipboard -o) && echo '$clipboard_contents' | xclip -selection clipboard"

Not sure if that will help though as I'm unable to test an X environment atm.

@savedra1
Copy link
Owner

Hi @Lethaquell,

Just wondering if you managed to make any progress here?

Thanks

@Lethaquell
Copy link
Author

Hi @Lethaquell,

Just wondering if you managed to make any progress here?

Thanks

Sup @savedra1

Actually, not really. For the time being and in cause of lacking free time I've stopped trying to fix this.

In my spare time I'm trying to migrate to Wayland. Maybe it'll somehow help and I'll return to this issue

@savedra1
Copy link
Owner

@Lethaquell Wayland will deffo help I think due to a recent update with clipse that uses wl-clipboard directly for the event listener. Let me know if that ends up sorting the issue for you 😄

@jasper-clarke
Copy link

@savedra1
I haven't been a part of this issue but its awesome to see your dedication to helping out with peoples issues.
I just wanted to pop in as I am having the same issue while using kitty as my terminal on Xorg.

When I do clipse from within an existing terminal, select something and it closes, i do CTRL + SHIFT + V and it pastes whatever I have picked which is amazing.

But when I execute kitty -e clipse, select my item it can't be pasted in any other window.

I tried the below command as mentioned in this issue and another but it just makes me paste $clipboard_contents everytime.

kitty --class clipboard -e clipse | clipboard_contents=$(xclip -selection clipboard -o) && echo $clipboard_contents | xclip -selection clipboard

@savedra1
Copy link
Owner

Hi @jasper-at-windswept thanks for reaching out!

Looking at the command I think I can suggest something else to try. As the clipse selection wouldn't actually send anything to the stdin to be piped there, you could try something like this instead:

kitty --class clipboard -e clipse && xclip -selection clipboard -o | xclip -selection clipboard

This should hopefully 're-copy' the selection to the primary selection keyboard after clipse terminates.

I need to figure out a convenient way to test clipse in an Xorg environment as I still can't test this myself for the time being. Hopefully that helps put you in the right direction though!

@jasper-clarke
Copy link

Thanks for getting back to me @savedra1
I tried your command but it did not work unfortunatley.
I did get this output though specifically when I selected a item from the list.

Error: target STRING not avaliable

@jasper-clarke
Copy link

jasper-clarke commented Aug 28, 2024

@savedra1
This may be an issue with Xclip possibly.
astrand/xclip#38

Edit*
I think this is still a problem with clipse.
From some testing I found that running clipse in an already open terminal and selecting an item successfully copied it to the system clipboard and running xclip -selection clipboard -o afterwards (not chained into one command), proved it was in the clipboard and opening a new terminal or any app and pasting worked.

However it seems that specifically when clipse is run in a new terminal instantly with a command like kitty -e clipse it fails to set the system clipboard but instead sets the clipboard to an empty or improperly formatted/corrupted string yielding the ouput of Error: target STRING not found from xclip -selection clipboard -o.

@jasper-clarke
Copy link

More notes,
Running clipse -c hey and then xclip -selection clipboard -o works perfectly.
Running kitty -e clipse -c hey and then xclip -selection clipboard -o fails with Error: target STRING not found

@savedra1
Copy link
Owner

Thank you @jasper-at-windswept!

I won't throw out anymore suggestions until I'm able to test this properly but lmk in the meantime if you come across a fix 😄

@jasper-clarke
Copy link

jasper-clarke commented Sep 4, 2024

No good news unfortunatley but I have found out this is most likely not an issue with clipse.
After much more testing I have found even a command like this does not work and returns the error about the string not being found when checking in another terminal.
These issues may still be a relevant problem and the cause behind this.
https://wiki.ubuntu.com/ClipboardPersistence
astrand/xclip#38

kitty -e sh -c 'echo heyo | xclip -selection clipboard; xclip -selection clipboard -o; sleep 1'

@savedra1
Copy link
Owner

savedra1 commented Sep 7, 2024

Thank you for the update @jasper-at-windswept that's a good find and definitely related to this issue.

Will have a think about how to proceed here with X environments/Ubuntu. Will likely need to implement some dependency other than Xclip that can track the changes better.

@savedra1 savedra1 added the bug Something isn't working label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants