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: Improving X selection? Date: Sun, 3 Feb 2008 18:29:09 +0000 Message-ID: <8e24944a0802031029y35ec3b94k38834a5148152303@mail.gmail.com> References: <8e24944a0710161629r1ec1afadj60352dc92c264217@mail.gmail.com> <8e24944a0801281152w733c977akda93089a52701219@mail.gmail.com> <8e24944a0801281659sa5a9115rf4533184413a8b20@mail.gmail.com> <8e24944a0802011115h77423fd1p2eae15a1e46bca1a@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1202063380 16644 80.91.229.12 (3 Feb 2008 18:29:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Feb 2008 18:29:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 03 19:30:01 2008 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.50) id 1JLjbD-0001OA-NA for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 19:29:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLjal-00040x-Mx for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 13:29:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JLjac-0003sj-AT for emacs-devel@gnu.org; Sun, 03 Feb 2008 13:29:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JLjab-0003qv-78 for emacs-devel@gnu.org; Sun, 03 Feb 2008 13:29:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLjaa-0003qa-IT for emacs-devel@gnu.org; Sun, 03 Feb 2008 13:29:12 -0500 Original-Received: from hs-out-0708.google.com ([64.233.178.242] helo=hs-out-2122.google.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JLjaZ-0005TF-VF for emacs-devel@gnu.org; Sun, 03 Feb 2008 13:29:12 -0500 Original-Received: by hs-out-2122.google.com with SMTP id j58so1344377hsj.10 for ; Sun, 03 Feb 2008 10:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Q2prFZGomI1sb0OKA/vxM02VB5Aq1JxYNuwBTJBn5Oo=; b=di/vhlIfMATp1kg5RptTrPtqVydIgdEzxC60yazzkHFczJLTedekupFzNDQbkKdJdMZ1nT/qDulnmffAY2bHmPKuoROWfSKDDi24f6SjMqQuKJLfDdBlT/oXXztbcP0a0wKoLavQFdNdNmzvNVz7ZrXuymOGD3PPkDkrTgpgj/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rm0ho5+9aORULI4BbeLCx9KVGSrPSkvchF44dU78qc7yHAe8FKr2E5sbXMDpptOY25PWomxlxBD7WlYP3eguc3sOhU6XHKv5zaiWpKiFzQ2GHepNmvmiGhySyk+G00YnWJnbJHq60Imf8BdZD6wyB6GzVchcRUptb1Eg1xcAaQk= Original-Received: by 10.142.127.10 with SMTP id z10mr3022283wfc.216.1202063349788; Sun, 03 Feb 2008 10:29:09 -0800 (PST) Original-Received: by 10.142.111.4 with HTTP; Sun, 3 Feb 2008 10:29:09 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 (Google crawlbot) 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:88097 Archived-At: On 03/02/2008, Richard Stallman wrote: > Adding interprogram-highlight-function seems good to me > > Your proposed changes in x-win.el are very big; Well, the delta is bloated partly because of my verbose docstrings for the extended customizations. Those should be cut down, I tend to write too much (I was eager to explain the ramifications of the different customizations. It also seemed to make sense to reuse the x-select-text code for x-select-text-for-highlight, so I made both into wrappers around one function, x-select-text-for-op parameterised by the "op" i.e. whether the function was being called for cutting or highlighting purposes by cut (x-select-text) or highlight (x-select-text-for-highlight) wrappers. That moved some code about, but just to avoid unnecessary redundancy. (And there's one more patch touching x-win.el to come, introducing the multiple-selections return thing that started the thread, and note that the already-forwarded mouse-behaviours-nice-with-select-active-regions.diff also affects x-win.el due to introduction of an interprogram-lightins-function that is to interprogram-highlight-function as interprogram-paste-function is to interprogram-cut-function) > what is the purpose? Well, the abstract purpose remains to make kill ring and active region interaction with the X11 clipboard and primary selections customizable to historic emacs defaults - and historic emacs possible customizations AND recent X11 conventions, without breaking backward compat. Regarding x-win.el in particular, the possible values of x-select-enable-primary and x-select-enable-clipboard were extended to allow more versatile specification of what selections are involved in what interprogram-cut/paste/highlight-function operations, rather than just all-or-nothing (and thereby somewhat problematic) "nil" and "t". > Do they change the default behavior? Depends entirely on defaults chosen for customize variables x-select-enable-primary and x-select-enable-clipboard (and x-select-enable-cutbuffer, but, well, does anyone use cut buffers?) The patch picked new defaults, but only out of last-minute thoughtlessness on my part (my local tree defaults are the settings I want to get working): The existing default behaviour (and existing customisation possibilities to default behaviour) is still possible, and backward-compat is peserved, some complexity stems from me being paranoid about keeping it all possible if anything. > Why do you think there is a problem with select-active-regions? > Can you present a test case and explain what behavior you think > ought to be different? > Okay, I'll try: with transient mark mode on, select-active-regions on. a buffer with a bunch of text in. Set mark (C-SPC) somewhere, Move point somewhere else (with cursor keys). The active region between the mark and point is visible on screen as a highlight. Problem: The primary X11 selection is not updated to reflect the just-reshaped active region, despite select-active-regions being on. Why is this a problem? Because the highlight on the screen will stop matching the primary X11 selection, so users will get something unexpected or nothing when they try to middle-click transfer the emacs highlight into other applications. Why does this problem happen? Because the mark doesn't change if you only move the point, and if the mark doesn't change, the select-active-regions callout to set the X11 selection in set-mark doesn't run. How did I "fix" it (apart from "badly")? Check if the region is active on every point move as well as every mark move, and set the X11 selection then too (when select-active-regions is set). > The hook post-point-motion would be very costly, > so only a very powerful reason could convince me to install it. Well, for select-active-regions to work (work: keep active region and X11 selection synchronised), I didn't see any good way around calling something whenever the active region changes shape. And when does the active region change shape? When the point or mark moves. Without updating when the point moves, it's only doing 1/2 the job.