search

cdown / clipmenu

Clipboard management using dmenu
MIT License
1.14k stars 91 forks source link

Copy/paste from file manager is not done properly #102

Closed artebin closed 4 years ago

artebin commented 5 years ago

I have a problem with clipmenud when I copy/paste a file from a file manager. The clipmenud cache is updated when I copy (i.e. <ctrl>c), and I can see the update in clipmenu, but nothing happens in the file manager when I want to paste i.e. <ctrl>v (the paste action is also disabled in the contextual menu of the file manager). It is like the file manager cannot see the content of the clipboard. If I type 2 times <ctrl>c, then the file can be pasted in the file manager with <ctrl>v. I suppose this is somehow related to issue https://github.com/cdown/clipmenu/issues/34

I have the problem with Thunar and Caja, but everything seems fine with PCManFM.

If I understand well then I can use CM_OWN_CLIPBOARD=0 but then we don't have clipboard preservation after termination of the application from where the copy has been done. Is it correct?

GladOSkar commented 5 years ago

I have the same problem in nautilus. Never got around to investigating it.

artebin commented 5 years ago

This is due to the lines 219 to 233. I do not understand yet the why clipmenud needs to take ownership of the clipboard, see the comment below from clipmenud line 221:

# Take ownership of the clipboard, in case the original application
# is unable to serve the clipboard request (due to being suspended,
# etc).
#
# Primary is excluded from the change of ownership as applications
# sometimes act up if clipboard focus is taken away from them --
# for example, urxvt will unhilight text, which is undesirable.
#
# We can't colocate this with the above copying code because
# https://github.com/cdown/clipmenu/issues/34 requires knowing if
# we would skip first.

As a quickfix we can just comment 219 to 233.

memeplex commented 5 years ago

Same here using nemo. I've reported it as a bug in nemo before realizing this is a problem with clipmenud.

cdown commented 5 years ago

It's interesting that this cropped up again after the fix for #34. I'll take a look.

cdown commented 5 years ago

It looks like, as opposed to PCManFM, Thunar and others copy the verbatim file path as well:

Data before stripping: /home/cdown/lastbiosx
Data after stripping: /home/cdown/lastbios
New clipboard entry on clipboard selection: "/home/cdown/lastbios"
Writing /home/cdown/lastbios to /run/user/1000/clipmenu.5.cdown//3966658712 21
Writing 1562708801448121274 /home/cdown/lastbios to /run/user/1000/clipmenu.5.cdown//line_cache_clipboard

I suppose they did this so you could paste in the terminal or something? No idea how we're going to detect this though.

cdown commented 5 years ago

I think this might not be possible with xsel, since it doesn't have any equivalent to xclip -t. To fix this, we might have to move to xclip

eugene-su commented 5 years ago

I have the mentioned problem with spacefm.

eugene-su commented 5 years ago

Every time to make copy in spacefm I must press ctrl+c twice.

eugene-su commented 4 years ago

Patch 3c411c7 fully solved the issue. Thank you, @cdown, a lot!

cassiohg commented 4 years ago

I checked in nautilus and there is no issue but I use mainly thunar and I still have to double ctrl-c.

cdown commented 4 years ago

This should be fixed in 6.0.0 -- please poke me if it is not. Thank you for the report!