I presume you are using middle click paste not `ctrl-c` `ctrl-v`?

Then see also #2629

Both #3310 and #2629 refer to the same Scintilla bug which has been partly fixed from what that discussion there says, but won't be further improved unless someone contributes the change.

I am not sure if the fix made it into the last update of Scintilla into Geany, and the person who last contributed a newer update unilaterally decided that they are so much more important than everyone else that they un-contributed (closed the PR and deleted the branch so nobody could use it) when nobody on the project had the time to review test and merge it in their personal time frame. [end gripe]

Geany 1.38-1 in Ubuntu 22.10 seems to totally ignore the primary Wayland selection in KDE 5.25.5, as in https://github.com/geany/geany/issues/2629. Selecting text in Geany does not affect the Wayland primary selection. Middle mouse paste pastes the Wayland secondary selection, which should be pasted by paste commands like Ctrl-V, not middle mouse paste.

Geany certainly does use the secondary selection. I can copy in Geany and see that output from `wl-paste`. However, it can only be pasted into some apps. Maybe the problem is the format that Geany claims the data is in. Running `wl-paste -l` to "Instead of pasting, list the offered types." I see this after copying in Geany: ``` UTF8_STRING STRING SAVE_TARGETS ``` However, other apps also show MIME types. Maybe some apps refuse to paste if they don't find a recognized MIME type there? Text copied in Konsole: ``` text/plain text/html text/plain;charset=utf-8 ``` Copied from Klipper clipboard history: ``` text/plain text/plain;charset=utf-8 ``` Copied from Chrome 108.0.5359.71: ``` STRING UTF8_STRING text/plain text/plain;charset=utf-8 text/plain;charset=utf-8 TEXT ```

Other possibly related problems are that copied data does not appear in KDE Klipper clipboard history, and that it is lost after Geany is closed. Then I guess Klipper puts the last thing from its history back into the clipboard.

@dreamlayers nice analysis, probably right

AFAICT Scintilla only offers the X11 atoms [here](https://github.com/geany/geany/blob/96342f3eb94dc6d49a05a65c9d73becca9009aa0...), but it will also accept the mime atoms [here](https://github.com/geany/geany/blob/96342f3eb94dc6d49a05a65c9d73becca9009aa0...).

AFAIK no current core contributors are using Geany on Wayland, but maybe someone who is can try simply adding the mime types to the list in the first link above and see what happens. (I'm not a Scintilla/Wayland expert so no guarantees ;-)

I have also suggested [elsewhere](https://github.com/geany/geany-osx/issues/40) that Scintilla GTK should handle rectangular selections the same way it does on Windows (define its own target type) so maybe `ScintillaGTK.cxx` needs a bit of a general wash and brush up to handle modern systems. Just needs "somebody" to do it.

@nyamatongwe yeah, the GTK patch is a better fix since apps can't tell if they are running under X11 or Wayland so they can't adjust the offered targets. The only problem is its going to be a while before a GTK version with the patch makes it to distros since it was only committed a month ago.

Although IIUC its not a problem if both sets of targets are advertised, the receiving app should simply ignore ones it doesn't want/understand.

@cristicc are you sure you are running pure Wayland, not xwayland? `COMPOUND_TEXT` and `TEXT` are not Mime type targets that Wayland apps expect, they are X11 targets, so if the `text/plain` or `text/plain;charset=utf-8` are there thats what a compliant Wayland app should accept.

It seems to indicate that Alacritty is running under xwayland or its confused.

Did some more tests: copying from Geany to Kitty or Chromium address bar exposes the same issue, so a miss-behavior on Alacritty's side is unlikely. Again, `xlsclients` doesn't show any of those running applications, hence XWayland shouldn't be part of the problem.

I thought I should add that my Alacritty configuration references tmux. Just in case that has anything to do with why my testing results are different:

**From Alacritty configuration:**

``` shell: program: /usr/bin/zsh args: - -l - -c - "tmux" ```

GTK is most likely converting both UTF8_STRING and text/plain;charset=utf-8 to TARGET_UTF8_STRING before calling back into Scintilla thus causing the same action for either request.

I'm not sure it is, lets see what they say to my query [here](https://gitlab.gnome.org/GNOME/gtk/-/commit/0c1ea9221976b838101d2593754b6588...)

Without documentation of the correct way to implement clipboard types, I see lots of potential for causing new problems. Compatibility seems to be getting worse with updates to applications, toolkits, and window systems.

Couldn't agree more.

Maybe different target lists should be provided on X, Wayland, Win32 and macOS.

Can Scintilla tell if its X or Wayland, thats a runtime check IIUC?

If the Geany project tries the patch out on your supported platforms and are happy with it then it can go in.

Ok, but the patch [here](https://gitlab.gnome.org/GNOME/gtk/-/issues/5397) is for an issue in Scite.

Can Scintilla tell if its X or Wayland, thats a runtime check IIUC?

Wayland was (is?) optional at both build-time and run-time so Scintilla tests at run-time but only runs that code if there was build support: ~~~c++ #if defined(GDK_WINDOWING_WAYLAND) GdkDisplay *pdisplay = gdk_display_get_default(); if (GDK_IS_WAYLAND_DISPLAY(pdisplay)) { // ... } #endif ~~~

Ok, but the patch [here](https://gitlab.gnome.org/GNOME/gtk/-/issues/5397) is for an issue in Scite.

The commonly used versions of SciTE run directly on Win32 and macOS APIs which allows richer platform integration like supporting the `MSDEVColumnSelect` clipboard format on Win32 or dragging 'ghost' text on macOS. Therefore, SciTE for GTK's behaviour on Win32 or macOS isn't very important and I don't test it. It may work and I'll accept patches but its not mainstream.

For Geany, running on Win32 or macOS means running through GTK and its wrapping of platform APIs so there is much more scope for problems to occur in Geany with these changes.

See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5300, hopefully now the right atom (small integer) will be provided.

While the patch may be good, there are two target values involved here which I was trying to separate. There is a target atom and a target enumeration. The target atom is in a global atom table to allow interop and the target enumeration is local to the client code and is not an atom. The target enumeration goes into the `info` field of the `GtkTargetEntry` struct which is defined as:

An application-assigned integer ID which will get passed as a parameter to e.g the GtkWidget::selection-get signal. It allows the application to identify the target type without extensive string compares.

https://docs.gtk.org/gtk3/struct.TargetEntry.html

Echoing here that with Geany 1.38 as distributed with Fedora 36, cut and paste from geany is now completely broken. Pasting a selection with the middle button from geany has been broken for ages, but now CTRL-C and CTRL-V do not work from geany to other apps either any more.

This breaks geany as a normal editor. I liked it for its configurability and light-weight appearance, but it looks like I have to resort to gedit now -- at the moment every time I find I need to paste something from an editor window (which happens a lot!) I need to reopen the file in gedit. I really hope this can be fixed soon, because I would rather not go through the chores of changing my default editor.

Geany copy/pasting is also broken in Debian testing at the moment geany 1.38-1+b1 (built with on 2022-09-18 with GTK 3.24.34, GLib 2.73.3)

The least annoying workaround seems to be: drag & drop code to the notes panel and copy it from there.


@cristicc thanks for letting us know it works, now just to wait for it to percolate to non-bleeding edge distros.

Closed #3345 as completed.

@nbruin Just tested the copy/paste through middle mouse button from alacritty to geany and it seems to work just fine.

@nbruin Right, that scenario doesn't work, and I also don't remember it ever working, that's why I didn't bother checking again in the first place.

@elextr @cristicc @nbruin

I was reading through the thread and decided to test the "Click to Paste from Geany to Alacritty" in Gnome. I can confirm:

(1) Paste from Geany to Alacritty:

(a) With the Middle Mouse does not work when using formatted text on a web page.

(b) With the Middle Mouse does work when using unformated text (e.g. the Firefox address bar).

(c) Paste from Geany to Alacritty with the (CTRL-SHIFT-V) does work.

(2) Paste from Geany to Gnome Console with the middle Mouse does not work.

(a) With the Middle Mouse does not work when using formatted text on a web page.

(b) With the Middle Mouse does work when using unformated text (e.g. the Firefox address bar).

(c) Paste from Geany to Gnome Console with the (CTRL-SHIFT-V) does work.

Based on @elextr feedback, perhaps a separate bug should be created for the Middle Mouse Button. This was not something I accounted for as I don't use the middle mouse button.

@rsramkis please supply the version of GTK you used for this and confirm all applications are using Wayland, not XWayland.

IIUC (1) (a) (b) (2) (a) (b) have nothing to do with Geany, somebody else's problem :-) but they seem to indicate that middle click doesn't work for any applications, so should be reported to GTK if you are using latest (3.24.36)

I can confirm like above I am still using gtk3 1:3.24.36.1 

What is the best way in Arch Linux to confirm Geany is only using Wayand. In my case everything is working except the middle mouse button. I don't consider this a Geany issue.