From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Selection changes Date: Sat, 17 Jul 2010 04:50:32 +0100 Message-ID: <4C412888.9080805@harpegolden.net> References: <87ocea2ax1.fsf@stupidchicken.com> <4C40FCEC.9030404@harpegolden.net> <87pqym2a4r.fsf@catnip.gol.com> <4C411552.40003@harpegolden.net> <87eif2n7d7.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1279338676 21096 80.91.229.12 (17 Jul 2010 03:51:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 03:51:16 +0000 (UTC) Cc: Miles Bader , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 05:51:14 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZyQg-0004lN-5O for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 05:51:10 +0200 Original-Received: from localhost ([127.0.0.1]:45111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZyQf-00031d-JD for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 23:51:09 -0400 Original-Received: from [140.186.70.92] (port=59075 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZyQ9-0002jv-4M for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:50:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZyQ7-0007Mn-Kz for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:50:37 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:40247) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZyQ7-0007Mf-BW; Fri, 16 Jul 2010 23:50:35 -0400 Original-Received: from [87.198.55.208] (87-198-55-208.ptr.magnet.ie [87.198.55.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 2C24D683FF; Sat, 17 Jul 2010 04:50:32 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 In-Reply-To: <87eif2n7d7.fsf@stupidchicken.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127481 Archived-At: On 17/07/10 03:56, Chong Yidong wrote: > So, for the > moment, I went ahead and changed x-select-enable-primary to nil, as you > requested. > Thanks, sorry for the rant. It's 4:50am, time for bed... The bad "(not (eq (region-beginning) (region-end)))" check is still present in deactivate-mark (~simple.el line 3690) and should just be removed, I did [try to] explain the problem with it in a previous mail, that's a further source of some poor behaviour (perhaps counterintuitively, but that's lazy stuff for you) that might be related to some of your points below. > But I think select-active-regions needs further improvement. No doubt... > Perhaps > its default behavior should be as follows: for an active region created > using shift-selection or mouse dragging, Emacs supplies the region text > to primary. When such a region is deactivated, Emacs disowns primary > (as some other apps do, tho not Firefox). Hmm. I do rather prefer the freezing off of the region into a string selection (line just after the bad check above) when deactivating rather than completely disowning - I mean, once you disown, the text won't be made available for middle-click insertion anymore and you'll be seeing "No primary selection" warnings a lot more. Don't forget, the bad check mentioned above is negatively impacting behaviour in this specific area right now, if you remove the bad check line, the freezing off will work properly again. > For an active region created > simply with C-SPC, no special x-selection handling should be performed. > Well, not immediately owning primary on C-SPC /would/ stop most (all?) of the possible zero-length-region annoyances (unlike the "bad check") in their tracks, but it might be overkill to not own it at all if there's an (efficient) way to make emacs just defer taking ownership until the newly active region first becomes nonzero length. That way, visibly highlighted regions would still act the same regardless of wether they were mouse/keyboardA/keyboardB created.