bug#28631: 25.3.50; Deactivate mark with Ctrl-g mess up the primary-selection

[Noam Postavsky <npostavs@users.sourceforge.net>]

Tino Calancha <tino.calancha@gmail.com> writes:

> I am biten by this problem from time to time.  When winer-mode
> is enabled and i deactivate the mark with C-g, then i observe
> funny behaviour with `yank'.
>
> Usually i visit another buffer BUF-B to copy a string STR; then
> i do `winner-undo' to comeback to the initial buffer, BUF-A,  and `yank'
> STR.  Sometimes i found that `yank' insert a string different than STR.
> That's happen if i previously deactivated the mark in BUF-A with C-g.
>
> To reproduce the problem:
> emacs  -Q -eval '(winner-mode 1)' \
> -eval "(customize-set-variable 'select-enable-clipboard nil)" \
> -eval "(customize-set-variable 'select-enable-primary t)"
>
> < C-TAB M-f M-f ; `yank' would insert ";; This buffer"

That should be 'M-< C-SPC M-f M-f' I guess.

> C-x C-b C-x 0

C-x o, not C-x 0.

> C-x h ; mark whole buffer
> ;; `yank' would insert the content of *Buffer List*
> C-g
> RET ; `yank' would insert  ";; This buffer"
> C-c <left> ; winner-undo
> ;; `yank' would insert the content of *Buffer List*
>
> Note that the primary selection doesn't change if you visit
> *Buffer List* with C-x b RET.  That is, if you change above
> C-c <left>
> by:
> C-x b RET
>
> then, the `yank' will insert ";;This buffer".
>
> I don't see a good reason why visiting a buffer with `C-x b' or
> `winner-undo' makes a difference in the primary selection.

It's because winner-undo tries to restore marks.

(defun winner-active-region ()
  (declare (gv-setter (lambda (store) ...
                          `(if ,store (activate-mark) (deactivate-mark))))))
  (region-active-p))

...

;; Make sure point does not end up in the minibuffer and delete
;; windows displaying dead or boring buffers
;; (c.f. `winner-boring-buffers').  Return nil if all the windows
;; should be deleted.  Preserve correct points and marks.
(defun winner-set (conf)
  ...
      ;; Restore marks
      (save-current-buffer
        (cl-loop for buf in buffers
                 for entry = (cadr (assq buf winner-point-alist))
                 do (progn (set-buffer buf)
                           (set-mark (car entry))
                           (setf (winner-active-region) (cdr entry)))))
  ...


Lisp Backtrace:
"x-own-selection-internal" (0xffffb560)
0x1364810 PVEC_COMPILED
"apply" (0xffffbbe0)
"gui-backend-set-selection" (0xffffc110)
"gui-set-selection" (0xffffc628)
"deactivate-mark" (0xffffcb60)
"winner-set" (0xffffd100)
"winner-undo-this" (0xffffd600)
"winner-undo" (0xffffddb0)
"funcall-interactively" (0xffffdda8)
"call-interactively" (0xffffe010)
"command-execute" (0xffffe588)
(gdb) p selection_value
$10 = XIL(0x31a5f54)
(gdb) xpr
Lisp_String
$11 = (struct Lisp_String *) 0x31a5f50
". * *scratch*", ' ' <repeats 15 times>, "266 Lisp Interaction \n %* *Messages*", ' ' <repeats 14 times>, "133 Messages         \n"

> How about the following patch?
>
>     Set mark at point after keyboard-quit
>     
>     * lisp/simple.el (deactivate-mark): In transient-mark-mode
>     always set the mark at point after keyboard-quit (Bug#28631).

That seems quite disruptive.  Perhaps instead deactivate-mark could be
changed so that it would not update the selection on winner-undo?