From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Drag and drop patch for X, please review. Date: Fri, 23 Jan 2004 21:05:05 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <6FAAFF66-4DDF-11D8-B739-00039363E640@swipnet.se> References: <200401171729.i0HHT1wq016912@stubby.bodenonline.com> <20040118004009.GA24635@fencepost> <2C5AAB61-49F7-11D8-A763-00039363E640@swipnet.se> <74293710-4B62-11D8-89AF-00039363E640@swipnet.se> <39277C06-4B8A-11D8-AF87-00039363E640@swipnet.se> <6DDE2AC7-4C61-11D8-89BA-00039363E640@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074888729 30784 80.91.224.253 (23 Jan 2004 20:12:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2004 20:12:09 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, storm@cua.dk, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jan 23 21:12:01 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ak7er-0000Ed-00 for ; Fri, 23 Jan 2004 21:12:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ak7er-00080Z-00 for ; Fri, 23 Jan 2004 21:12:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ak7eQ-0002Js-Vd for emacs-devel@quimby.gnus.org; Fri, 23 Jan 2004 15:11:34 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ak7eK-0002JT-NH for emacs-devel@gnu.org; Fri, 23 Jan 2004 15:11:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ak7do-0002DA-J2 for emacs-devel@gnu.org; Fri, 23 Jan 2004 15:11:27 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Ak7Z8-0007oJ-Gj; Fri, 23 Jan 2004 15:06:06 -0500 Original-Received: from [213.115.192.53] (helo=mail2.norrnet.net) by mx20.gnu.org with esmtp (Exim 4.24) id 1Ak7Yf-0002Xd-0F; Fri, 23 Jan 2004 15:05:37 -0500 Original-Received: from stubby.bodenonline.com (stubby.bodenonline.com [193.201.16.94]) by mail2.norrnet.net (BorderWare MXtreme Mail Firewall) with ESMTP id 69771BCA48; Fri, 23 Jan 2004 21:05:33 +0100 (CET) Original-Received: from accessno42.bodenonline.com (accessno42.bodenonline.com [193.201.16.44]) by stubby.bodenonline.com (8.12.1/8.12.1) with ESMTP id i0NKvhpi005543; Fri, 23 Jan 2004 21:57:44 +0100 In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.609) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19463 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19463 > Earlier I thought you were saying it was too difficult > to decide based on specific details whether to allow a certain > drop in a certain buffer. But now that you've explained that > every message leads to a LIsp-level event, I can see this is > not difficult at all. I probably didn't explain it very well. I was thinking of text versus file names. Dropping a file name on the menu bar, or a read only buffer is OK, it justs open the file in that window. But dropping text on the same place should not insert the text. So the question was, how can the code know if somebody has reconfigured the dropping of file names to actually insert the file name as text instead of opening it? We can not know that the drop should be rejected. But the suggestion made here was to in that case not reject it, but rather put it in the kill ring and display a message about it. > That is what I am doing now, so if you have several windows in a > frame, > the one where a file is dropped is used. This happens anywhere in > the > buffer, not just the mode line. > > That might make sense in most cases. But Dired buffers should treat > it differently, and that means it can't be a general Emacs convention. I'm working on dired so it will handle drop of files as a file manager, i.e. move, copy or link them to the directory. Jan D.