bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

After upgrade to latest development version at:

      05fe0faed4: "make clean" etc. problem now fixed on Solaris.

I found out that using (x-clipboard-yank) when `select-enable-
clipboard` is set to t randomly pastes stuff that is not in system
clipboard. I don't know exact commit that broke it, am in process of
bisecting right now. Latest one working that I found so far is
7055104358ad51b8c49e120851ee5d4d3c909e6d.


# Steps to reproduce

1. Create /tmp/.emacs file with the following content:

    (setq select-enable-clipboard nil
          inhibit-startup-screen t)

    (defun clipboard-yank-test ()
      (interactive)
      (let ((select-enable-clipboard t))
        (x-clipboard-yank)))

    (global-set-key "\C-y" 'clipboard-yank-test)
2. Launch `HOME=/tmp/ emacs`
3. Outside Emacs copy a word "test"
4. In Emacs ensure that `C-y` pastes word "test"
5. In Emacs, delete a different word in the *scratch* buffer, e.g. a
"create"
6. In Emacs, press C-y to paste current clipboard content

## Expected

A word "test" will be inserted as this is the one that is in the system
clipboard.

Note: the word "create" didn't replace content in the clipboard,
because global value of select-enable-clipboard is nil. So it still has
"test", and the C-y was expected to paste "test" as well due to
`select-enable-clipboard` being temporarily set to `t` in clipboard-
yank-test.

## Actual

The word you deleted in *scratch* buffer will be inserted instead of
"test".

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

The problem is bisected to commit:

	16174d796f86fe Avoid extraneous selection querying if we own the selection

CCing the commit author.

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> After upgrade to latest development version at:
>
>       05fe0faed4: "make clean" etc. problem now fixed on Solaris.
>
> I found out that using (x-clipboard-yank) when `select-enable-
> clipboard` is set to t randomly pastes stuff that is not in system
> clipboard. I don't know exact commit that broke it, am in process of
> bisecting right now. Latest one working that I found so far is
> 7055104358ad51b8c49e120851ee5d4d3c909e6d.

Should be fixed now.  Thanks.

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

> Should be fixed now.  Thanks.

Thanks, I confirm that updating to latest master at commit fb0d95984b
fixes the problem

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

>> Should be fixed now.  Thanks.
>
> Thanks, I confirm that updating to latest master at commit fb0d95984b
> fixes the problem

I'm closing this bug then, thanks.

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Constantine Kharlamov]

[-- Attachment #1: Type: text/html, Size: 977 bytes --]

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Constantine Kharlamov <hi-angel@yandex.ru> writes:

> Omg, I am afraid it has now become worse. If previously it was
> possible to consistently reproduce the problem, then now it starts
> happening after some time of usage.  I.e. initially it works well, no
> problem, but then the bug returns and I can't edit stuff and still to
> be able to paste from my clipboard.

I guess something else is asserting ownership of `CLIPBOARD' after a
while, which makes this fail.

To debug this issue, do "M-x trace-function RET x-own-selection-internal
RET", and tell me what you were doing immediately prior to this showing
up:

  1 -> (x-own-selection-internal CLIPBOARD

You might want to turn off `select-active-regions' as well.  Otherwise,
the trace buffer will fill up very quickly.

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

[-- Attachment #1: Type: text/html, Size: 1916 bytes --]

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> When I trace the `x-own-selection-internal` and reproduce the bug by
> first pressing M-d to delete a word and then C-y to insert whatever is
> in clipboard, nothing appears in *trace-output* buffer. Something does
> appear when I select a text, however specifically upon deleting a
> word, then getting inserted the wrong content (i.e. the one from
> kill-ring instead of the one in clipboard) nothing appears.

I don't understand what you said here.  I suggest you turn off
`select-active-regions' before trying to get a trace.

Once a trace appears (and the bug presumably re-appears), please tell me
what you were doing.

> For the safe case I want to emphasize again that this new exhibition
> of a problem is not specific to `x-clipboard-yank` but is reproducible
> with `clipboard-yank` too.

I heard you the first time, but it would be more productive to solve the
problem with `x-clipboard-yank' first.

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

[-- Attachment #1: Type: text/html, Size: 1873 bytes --]

bug#56273: [REGRESSION] (x-clipboard-yank) pastes from kill-ring when `select-enable-clipboard` is t

[Konstantin Kharlamov]

> I found the reproducer! I will create a new report shortly and send a
link here

Done, the new report #56325
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56325