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

Previous Next

Full log

Message #23 received at 28631 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28631 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#28631: 25.3.50;
 Deactivate mark with Ctrl-g mess up the primary-selection
Date: Fri, 13 Oct 2017 09:48:15 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Thu, 12 Oct 2017 20:46:54 -0400
> Cc: 28631 <at> debbugs.gnu.org
> 
> --- i/lisp/simple.el
> +++ w/lisp/simple.el
> @@ -5336,7 +5336,9 @@ deactivate-mark
>  	    ;; deactivation should not clobber it (Bug#11772).
>  	    ((and (/= (region-beginning) (region-end))
>  		  (or (gui-backend-selection-owner-p 'PRIMARY)
> -		      (null (gui-backend-selection-exists-p 'PRIMARY))))
> +                      (null (gui-backend-selection-exists-p 'PRIMARY)))
> +                  ;; `winner-undo' shouldn't update the selection (Bug#28631).
> +                  (not (eq this-command 'winner-undo)))
>  	     (gui-set-selection 'PRIMARY
>                                  (funcall region-extract-function nil)))))
>      (when mark-active (force-mode-line-update)) ;Refresh toolbar (bug#16382).
> 
> Either way, I think it's okay to push emacs-26, but wait a bit in case
> someone else thinks otherwise.

Is there really no way to solve this in winner?  It seems like a
winner bug/misfeature, and I'm worried by the possible effect of this
patch on use cases that have nothing to do with the specific scenario
of this bug.  deactivate-mark is used a lot in places and ways we
cannot possibly predict.

So I think a solution for emacs-26 should be safer than that.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.