theJayTea
[feature-request] configuration option to bind selected text copy to somthing other than `Ctrl+c` based on focused application
Since some applications like terminal, emacs or other similar editors do not use Ctrl+c to copy text, maybe we can create a config file with Application and copy keybinding.
We can then match configured application name to active window title to simulate application based copy keybinding.
Let me know if you need help to create this feature.
The idea is not bad, actually. I fear it will require a bit of code refactoring, but I could be done.
For Linux systems ideally it could access the second clipboard buffer (the one that gets filled while simply selecting some text and pasting it with the press of the middle mouse button or the scroll-wheel), so that we can bypass emulating ctrl+c completely since the buffer has been already filled by the user when selecting the text.
I think it is a better idea to access the clipboard rather than simulating Ctrl+c.
I would suggest user to copy the desired text [with application specific copy key-binding] and trigger Writing-tools. Writing-tools will access the top most clipboard entry and parses it to AI tools.
I think this approach would be cleaner and more adaptable across linux desktop environments.
https://code.activestate.com/recipes/576887-shared-clipboard/
this is cross platform too - https://github.com/asweigart/pyperclip
Pyperclip is the library already in use for this app.
Changing the default behavior by removing the ctrl+c/v emulation would not only be a major change but also make the app way less intuitive. For example, "chat mode" works exactly because there is no selected text, if we were to pick the top-most clipboard element we would completely lose this feature.
Yes, completely agree.
What about having 2 functions and 2 keybindings. One keybinding is configured to read from the clipboard. One keybinding opens writing tools in chat mode.
C+` - chat mode
C+~ - that is Ctrl+Shift+` - copies from clipboard and gives AI options.
This approach might be easier to manage. Thoughts?
Hey everyone! Sorry I wasn't able to research about this and reply earlier.
As @momokrono suggested, on Linux under X11, we should be able to access the second clipboard buffer directly, allowing Writing Tools to work on any selected text—even in editors like emacs & the terminal. Chat mode could still work too, since when you invoke Writing Tools without any text selected, the second clipboard buffer should be blank.
However, Wayland doesn't have a secondary selected text clipboard buffer, and by refactoring the code with the above implementation for Linux, we're essentially solidifying a lack of support for Wayland in the future.
For context, currently, Writing Tools only works on Wayland if you:
In the future, we could look into implementing KDE's global shortcuts API so things work smoothly on Wayland with KDE.
So I don't think it would be wise to refactor with some Xorg-specific functionality at the moment...
Let me know what you think!
Kind regards, Jesai
