You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #60, #42. ad should figure out what tool to use for clipboard management dynamically. Ideally this should involve as little conditional compilation as possible for the sake of maintainability. A proof of concept can be taken from neovim which is implemented in vimscript.
We could probably implement something similar by adding a field to DefaultSystem that stores which tool to use. We'd then detect which is appropriate in DefaultSystem::new() or similar.
I think there are two related questions we at least think before we start reworking things:
Most editors (including nvim, I think) are their own clipboard backends unless they are compiled as the GUI variant. As a GUI, you are basically guaranteed a working clipboard. In all other cases, the editor's internal clipboard is “just” synced with the system clipboard. This means that it is okay if no suitable tool is found to sync the clipboard. With ad's current approach, the editor is more or less unusable in such a situation (which isn't uncommon, think sshing into some server). I guess this depends on long term plans as well, i.e. will the TUI interface stick around forever?
Wayland and X11 have a primary “clipboard” which stores the most recent selection in any program. Some users may expect this to work and it is sometimes necessary when interacting with programs that only use/support the primary selection.
The text was updated successfully, but these errors were encountered:
See #60, #42.
ad
should figure out what tool to use for clipboard management dynamically. Ideally this should involve as little conditional compilation as possible for the sake of maintainability. A proof of concept can be taken from neovim which is implemented in vimscript.We could probably implement something similar by adding a field to
DefaultSystem
that stores which tool to use. We'd then detect which is appropriate inDefaultSystem::new()
or similar.I think there are two related questions we at least think before we start reworking things:
ad
's current approach, the editor is more or less unusable in such a situation (which isn't uncommon, thinkssh
ing into some server). I guess this depends on long term plans as well, i.e. will the TUI interface stick around forever?The text was updated successfully, but these errors were encountered: