Patch for remote files in dnd.el

Patch for remote files in dnd.el

[Jason Rumney]

The following patch to dnd.el adds support for remote files via a new
variable dnd-open-remote-file-function.

On Windows, this defaults to the new function dnd-open-unc-file, on
other platforms it is nil, giving the old behavior. If other platforms
can receive remote files by drag and drop, then appropriate methods
for accessing them can be added (perhaps via tramp).


Any objections to installing this now?


*** dnd.el	05 Jun 2006 22:10:29 +0100	1.9
--- dnd.el	27 Jul 2006 23:14:05 +0100	
***************
*** 59,64 ****
--- 59,78 ----
    :group 'dnd)
  
  
+ (defcustom dnd-open-remote-file-function
+   (if (eq system-type 'windows-nt)
+       'dnd-open-unc-file
+     nil)
+   "The function to call when opening a file on a remote machine.
+ The function will be called with two arguments; URI and ACTION. See
+ `dnd-open-file' for details.
+ If nil, then dragging remote files into Emacs will result in an error.
+ Predefined functions are `dnd-open-unc-file', which attempts to open
+ the file using its UNC name and is the default on MS-Windows."
+   :version "22.1"
+   :type 'function
+   :group 'dnd)
+ 
  
  (defcustom dnd-open-file-other-window nil
    "If non-nil, always use find-file-other-window to open dropped files."
***************
*** 158,163 ****
--- 172,195 ----
  	  'private)
        (error "Can not read %s" uri))))
  
+ 
+ (defun dnd-open-unc-file (uri action)
+   "Open a remote file using its unc path.
+ The file is opened in the current window, or a new window if
+ `dnd-open-file-other-window' is set. URI is the url for the file,
+ and must have the format file://hostname/file-name. ACTION is ignored.
+ //hostname/file-name is the unc path."
+   (let ((unc-file (if (string-match "^file:" uri)
+ 		      (substring uri 5))))
+     (if (and unc-file (file-readable-p unc-file))
+ 	(progn
+ 	  (if dnd-open-file-other-window
+ 	      (find-file-other-window unc-file)
+ 	    (find-file unc-file))
+ 	  'private)
+       (error "Invalid file url"))))
+ 
+ 
  (defun dnd-open-file (uri action)
    "Open a local or remote file.
  The file is opened in the current window, or a new window if
***************
*** 169,175 ****
    ;; file.  Otherwise return nil.
    (let ((local-file (dnd-get-local-file-uri uri)))
      (if local-file (dnd-open-local-file local-file action)
!       (error "Remote files not supported"))))
  
  
  (defun dnd-insert-text (window action text)
--- 201,209 ----
    ;; file.  Otherwise return nil.
    (let ((local-file (dnd-get-local-file-uri uri)))
      (if local-file (dnd-open-local-file local-file action)
!       (if dnd-open-remote-file-function
! 	  (funcall dnd-open-remote-file-function uri action)
! 	(error "Remote files not supported")))))
  
  
  (defun dnd-insert-text (window action text)

Re: Patch for remote files in dnd.el

[Mathias Dahl]

> The following patch to dnd.el adds support for remote files via a new
> variable dnd-open-remote-file-function.

Can you explain a bit more what functionality this patch adds? I have
always (as far back as have used Emacs, which is since 1997) been able
to open remote files just by dragging and dropping them into Emacs.
For example, I just dnd:d the file
"\\Gbgfs1\archive2004-1\Docman\Core\Docman 5.9.0\Docman\access.api"
into Emacs.

Re: Patch for remote files in dnd.el

[Jan Djärv]

Jason Rumney skrev:
> The following patch to dnd.el adds support for remote files via a new
> variable dnd-open-remote-file-function.
> 
> On Windows, this defaults to the new function dnd-open-unc-file, on
> other platforms it is nil, giving the old behavior. If other platforms
> can receive remote files by drag and drop, then appropriate methods
> for accessing them can be added (perhaps via tramp).
> 
> 
> Any objections to installing this now?

Just one:


> + (defcustom dnd-open-remote-file-function
> +   (if (eq system-type 'windows-nt)
> +       'dnd-open-unc-file
> +     nil)
> +   "The function to call when opening a file on a remote machine.
> + The function will be called with two arguments; URI and ACTION. See
> + `dnd-open-file' for details.
> + If nil, then dragging remote files into Emacs will result in an error.
> + Predefined functions are `dnd-open-unc-file', which attempts to open
> + the file using its UNC name and is the default on MS-Windows."
> +   :version "22.1"
> +   :type 'function
> +   :group 'dnd)


I'd prefer if dnd-open-unc-file and the setting of 
dnd-open-remote-file-function when system-type eq 'windows-nt goes in some w32 
specific file.

	Jan D.

Re: Patch for remote files in dnd.el

[Jason Rumney]

Jan Djärv wrote:
> I'd prefer if dnd-open-unc-file and the setting of 
> dnd-open-remote-file-function when system-type eq 'windows-nt goes in 
> some w32 specific file.
I was trying to make this a generic change, not a windows only one. 
dnd-open-unc-file might be useful on other systems, should any other 
systems support unc filenames in future. There is no good reason for it 
to be in a w32 specific file.

Setting variables outside their defcustom declaration also has side 
effects like "this variable was set outside customize" or a non-default 
default, depending on how you do this.

Re: Patch for remote files in dnd.el

[Jason Rumney]

Mathias Dahl wrote:
> Can you explain a bit more what functionality this patch adds? I have
> always (as far back as have used Emacs, which is since 1997) been able
> to open remote files just by dragging and dropping them into Emacs.
> For example, I just dnd:d the file
> "\\Gbgfs1\archive2004-1\Docman\Core\Docman 5.9.0\Docman\access.api"
> into Emacs.

In CVS Emacs?

This used to work, because on Windows, we just blindly passed the 
filename to find-file. But in CVS Emacs, there is a new cross-platform 
drag and drop library, which prints "Remote files not supported" if a 
remote file is dragged onto Emacs. I only noticed this recently, and 
wrote this patch to fix it.

Re: Patch for remote files in dnd.el

[Richard Stallman]

    Any objections to installing this now?

I don't want to add features that work only on proprietary systems.
Our goal is to replace those systems, not to enhance them.
This is a fine feature, but it needs to work on GNU/Linux before
we support it.

(Also, this feature is not urgent, and this is not the time for
new features.)

Re: Patch for remote files in dnd.el

[Jason Rumney]

Richard Stallman wrote:
>     Any objections to installing this now?
>
> I don't want to add features that work only on proprietary systems.
> Our goal is to replace those systems, not to enhance them.
> This is a fine feature, but it needs to work on GNU/Linux before
> we support it.
>   
It is not a new feature. X desktops tend to use file: urls only for 
local files, and other protocols are already handled by dnd.el, so 
remote drag and drop is already available on free systems as far as I 
can tell. It was also available on Windows up until 21.4, since Windows 
used its own dnd code that did not try to differentiate local from 
remote files.

Re: Patch for remote files in dnd.el

[Jason Rumney]

Jason Rumney wrote:
> X desktops tend to use file: urls only for local files, and other 
> protocols are already handled by dnd.el
I must have been confusing the code in dnd.el with code I have seen 
elsewhere. dnd.el only handles file urls currently.

Re: Patch for remote files in dnd.el

[Richard Stallman]

    > I don't want to add features that work only on proprietary systems.
    > Our goal is to replace those systems, not to enhance them.
    > This is a fine feature, but it needs to work on GNU/Linux before
    > we support it.
    >   
    It is not a new feature. X desktops tend to use file: urls only for 
    local files, and other protocols are already handled by dnd.el, so 
    remote drag and drop is already available on free systems as far as I 
    can tell.

Are you saying that drag-and-drop of remote files works
now on GNU/Linux?

Re: Patch for remote files in dnd.el

[Stefan Monnier]

>> X desktops tend to use file: urls only for local files, and other
>> protocols are already handled by dnd.el
> I must have been confusing the code in dnd.el with code I have seen
> elsewhere. dnd.el only handles file urls currently.

Does url-handler-mode help?


        Stefan

Re: Patch for remote files in dnd.el

[Jan Djärv]

Stefan Monnier skrev:
>>> X desktops tend to use file: urls only for local files, and other
>>> protocols are already handled by dnd.el
>> I must have been confusing the code in dnd.el with code I have seen
>> elsewhere. dnd.el only handles file urls currently.
> 
> Does url-handler-mode help?

It looks useful, I'll try it.

	Jan D.

Re: Patch for remote files in dnd.el

[Mathias Dahl]

> > For example, I just dnd:d the file
> > "\\Gbgfs1\archive2004-1\Docman\Core\Docman 5.9.0\Docman\access.api"
> > into Emacs.
>
> In CVS Emacs?

Yes, but not the latest version. The version I tested in is from
February, I think (cannot check right now.)

Re: Patch for remote files in dnd.el

[Jan Djärv]

Stefan Monnier skrev:
>>> X desktops tend to use file: urls only for local files, and other
>>> protocols are already handled by dnd.el
>> I must have been confusing the code in dnd.el with code I have seen
>> elsewhere. dnd.el only handles file urls currently.
> 
> Does url-handler-mode help?

Yes it does.  But isn't it a bit "heavy" to drag in url-handler-mode just to 
support dnd?  Or should it be turned on only when it is needed?

	Jan D.

Re: Patch for remote files in dnd.el

[Jan Djärv]

I think we should install this.  On GNU/Linux neither Nautilus or Konqueror 
(file browsers for Gnome and KDE) puts the host name in files dropped.  So 
there is basically no way a user can drop remote files onto Emacs in 
GNU/Linux.  On W32 this restors the old behaviour of Emacs 21 AFAIK, so it is 
not a new feature.

	Jan D.

Richard Stallman wrote:
> I don't want to add features that work only on proprietary systems.
> Our goal is to replace those systems, not to enhance them.
> This is a fine feature, but it needs to work on GNU/Linux before
> we support it.
> 
> (Also, this feature is not urgent, and this is not the time for
> new features.)


Jason Rumney wrote:
> The following patch to dnd.el adds support for remote files via a new
> variable dnd-open-remote-file-function.
> 
> On Windows, this defaults to the new function dnd-open-unc-file, on
> other platforms it is nil, giving the old behavior. If other platforms
> can receive remote files by drag and drop, then appropriate methods
> for accessing them can be added (perhaps via tramp).
> 
> 
> Any objections to installing this now?
> 
> 
> *** dnd.el	05 Jun 2006 22:10:29 +0100	1.9
> --- dnd.el	27 Jul 2006 23:14:05 +0100	
> ***************
> *** 59,64 ****
> --- 59,78 ----
>     :group 'dnd)
>   
>   
> + (defcustom dnd-open-remote-file-function
> +   (if (eq system-type 'windows-nt)
> +       'dnd-open-unc-file
> +     nil)
> +   "The function to call when opening a file on a remote machine.
> + The function will be called with two arguments; URI and ACTION. See
> + `dnd-open-file' for details.
> + If nil, then dragging remote files into Emacs will result in an error.
> + Predefined functions are `dnd-open-unc-file', which attempts to open
> + the file using its UNC name and is the default on MS-Windows."
> +   :version "22.1"
> +   :type 'function
> +   :group 'dnd)
> + 
>   
>   (defcustom dnd-open-file-other-window nil
>     "If non-nil, always use find-file-other-window to open dropped files."
> ***************
> *** 158,163 ****
> --- 172,195 ----
>   	  'private)
>         (error "Can not read %s" uri))))
>   
> + 
> + (defun dnd-open-unc-file (uri action)
> +   "Open a remote file using its unc path.
> + The file is opened in the current window, or a new window if
> + `dnd-open-file-other-window' is set. URI is the url for the file,
> + and must have the format file://hostname/file-name. ACTION is ignored.
> + //hostname/file-name is the unc path."
> +   (let ((unc-file (if (string-match "^file:" uri)
> + 		      (substring uri 5))))
> +     (if (and unc-file (file-readable-p unc-file))
> + 	(progn
> + 	  (if dnd-open-file-other-window
> + 	      (find-file-other-window unc-file)
> + 	    (find-file unc-file))
> + 	  'private)
> +       (error "Invalid file url"))))
> + 
> + 
>   (defun dnd-open-file (uri action)
>     "Open a local or remote file.
>   The file is opened in the current window, or a new window if
> ***************
> *** 169,175 ****
>     ;; file.  Otherwise return nil.
>     (let ((local-file (dnd-get-local-file-uri uri)))
>       (if local-file (dnd-open-local-file local-file action)
> !       (error "Remote files not supported"))))
>   
>   
>   (defun dnd-insert-text (window action text)
> --- 201,209 ----
>     ;; file.  Otherwise return nil.
>     (let ((local-file (dnd-get-local-file-uri uri)))
>       (if local-file (dnd-open-local-file local-file action)
> !       (if dnd-open-remote-file-function
> ! 	  (funcall dnd-open-remote-file-function uri action)
> ! 	(error "Remote files not supported")))))
>   
>   
>   (defun dnd-insert-text (window action text)
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch for remote files in dnd.el

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I think we should install this.  On GNU/Linux neither Nautilus or
> Konqueror (file browsers for Gnome and KDE) puts the host name in
> files dropped.  So there is basically no way a user can drop remote
> files onto Emacs in GNU/Linux.  On W32 this restors the old
> behaviour of Emacs 21 AFAIK, so it is not a new feature.

I think we should generally have this transform the stuff properly,
independent of platform.

Can't we just generally use the same mechanism as for `browse-url' for
files dropped into Emacs?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Patch for remote files in dnd.el

[Jason Rumney]

David Kastrup wrote:
> I think we should generally have this transform the stuff properly,
> independent of platform.
>   
The problem is defining what "properly" means for remote file: urls. On 
Windows, the system calls handle remote files using UNC paths, generally 
via the smb protocol, but on GNU and Unix systems, there are a number of 
possible protocols (smb, nfs, afs, ftp...) which all require external 
utilities, and it is not clear which is the right choice. I imagine this 
is why Nautilus and Konqueror avoid using remote file: urls, and instead 
use protocol specific urls for remote files.

> Can't we just generally use the same mechanism as for `browse-url' for
> files dropped into Emacs?
>   
Browse URL just launches a WWW browser to deal with URLs (except for a 
few specific types like mailto: which are handled internally in Emacs). 
I don't think the user expects a file to be opened in their WWW browser 
when the drag it onto Emacs.

Re: Patch for remote files in dnd.el

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> I think we should generally have this transform the stuff properly,
>> independent of platform.
>>   
> The problem is defining what "properly" means for remote file:
> urls. On Windows, the system calls handle remote files using UNC
> paths, generally via the smb protocol, but on GNU and Unix systems,
> there are a number of possible protocols (smb, nfs, afs, ftp...) which
> all require external utilities, and it is not clear which is the right
> choice. I imagine this is why Nautilus and Konqueror avoid using
> remote file: urls, and instead use protocol specific urls for remote
> files.
>
>> Can't we just generally use the same mechanism as for `browse-url' for
>> files dropped into Emacs?
>>   
> Browse URL just launches a WWW browser to deal with URLs (except for
> a few specific types like mailto: which are handled internally in
> Emacs). I don't think the user expects a file to be opened in their
> WWW browser when the drag it onto Emacs.

Then perhaps browse-url should be made to handle more types and
protocols.  I'd prefer it if browse-url used Emacs whenever possible,
like for ftp and ssh connections.

That sounds like an approach more useful to everybody than a
Windows-specific solution.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Patch for remote files in dnd.el

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> I think we should install this.  On GNU/Linux neither Nautilus or
>> Konqueror (file browsers for Gnome and KDE) puts the host name in
>> files dropped.  So there is basically no way a user can drop remote
>> files onto Emacs in GNU/Linux.  On W32 this restors the old
>> behaviour of Emacs 21 AFAIK, so it is not a new feature.

Actually I take some of that back.  You can browse ftp:// and nfs:// in 
nautilus, it wasn't in the documentation.

> 
> I think we should generally have this transform the stuff properly,
> independent of platform.

I am not sure that would work for w32.  For Samba shares, the URL becomes 
smb://host/... But in W32, I think it is in the UNC-format (\\host\...).  The 
UNC format just works on those machines, but the smb:// URL:s are not 
supported by tramp on W32.

> 
> Can't we just generally use the same mechanism as for `browse-url' for
> files dropped into Emacs?
> 

If dnd-protocol-alist does not match the URL and if 
browse-url-browser-function is a list of handlers, then those handlers are tried.

We could also enable url-handler-mode and match against url-handler-regexp. 
If that matches, a normal find-file should work.

	Jan D.

Re: Patch for remote files in dnd.el

[Reiner Steib]

On Wed, Sep 06 2006, Jan Djärv wrote:

> Actually I take some of that back.  You can browse ftp:// and nfs:// in
> nautilus, it wasn't in the documentation.

Konqueror (KDE) you can open remote files using ssh:

  fish://foobar@somehost/home/foobar

Maybe we could transform this into tramp file names?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Patch for remote files in dnd.el

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I am not sure that would work for w32.  For Samba shares, the URL
> becomes smb://host/... But in W32, I think it is in the UNC-format
> (\\host\...).  The UNC format just works on those machines, but the
> smb:// URL:s are not supported by tramp on W32.

One could easily extend Tramp for mapping the smb protocol onto UNC,
when on W32. The only restriction is that UNC file names don't allow
access under a different user name (AFAIK).

> 	Jan D.

Best regards, Michael.

Re: Patch for remote files in dnd.el

[Michael Albinus]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Konqueror (KDE) you can open remote files using ssh:
>
>   fish://foobar@somehost/home/foobar
>
> Maybe we could transform this into tramp file names?

The fish protocol expects a fish server on the remote side. Konqueror
transfers such a server (.fishsrv.pl) initially, when it doesn't exist
there.

I'm currently implementing the fish protocol for Tramp 2.1, driven by
performance considerations. But (at least for the time being) it isn't
foreseen to provide such a server by Tramp; it should be available on
the remote side already.

The fish protocol defines a fallback in case there is no server on the
remote side: use shell commands. One could say that Tramp has
implemented this fallback already :-)

Anyway, this won't be available for Emacs 22.1, because Tramp 2.0 is
integrated there.

> Bye, Reiner.

Best regards, Michael.

Re: Patch for remote files in dnd.el

[Richard Stallman]

    I think we should install this.  On GNU/Linux neither Nautilus or Konqueror 
    (file browsers for Gnome and KDE) puts the host name in files dropped.  So 
    there is basically no way a user can drop remote files onto Emacs in 
    GNU/Linux.

I don't think that changes the question.  We can wait to implement the feature
until it works on GNU/Linux.

Emacs must not be distorted into a means of making Windows more
attractive!

Re: Patch for remote files in dnd.el

[Richard Stallman]

    I'm currently implementing the fish protocol for Tramp 2.1, driven by
    performance considerations. But (at least for the time being) it isn't
    foreseen to provide such a server by Tramp; it should be available on
    the remote side already.

Tramp is supposed to do the client side of the job;
I wouldn't expect it to do the server side.

    Anyway, this won't be available for Emacs 22.1, because Tramp 2.0 is
    integrated there.

We wouldn't want to install such changes now anyway, but there's no
rush on this.  We can wait.

Re: Patch for remote files in dnd.el

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 27 Jul 2006 23:22:28 +0100, Jason Rumney <jasonr@gnu.org> said:

> The following patch to dnd.el adds support for remote files via a
> new variable dnd-open-remote-file-function.

Does the following change work for remote file access?  I can't test
it by myself.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: lisp/term/w32-win.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/term/w32-win.el,v
retrieving revision 1.77
diff -c -s -r1.77 w32-win.el
*** lisp/term/w32-win.el	20 May 2006 04:30:46 -0000	1.77
--- lisp/term/w32-win.el	7 Sep 2006 07:21:37 -0000
***************
*** 121,127 ****
  						 "/")
  				   "/")))
  		(dnd-handle-one-url window 'private
! 				    (concat "file:" file-name)))
  		(car (cdr (cdr event)))))
    (raise-frame)))
  
--- 121,127 ----
  						 "/")
  				   "/")))
  		(dnd-handle-one-url window 'private
! 				    (concat "file://" file-name)))
  		(car (cdr (cdr event)))))
    (raise-frame)))

Re: Patch for remote files in dnd.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     I'm currently implementing the fish protocol for Tramp 2.1, driven by
>     performance considerations. But (at least for the time being) it isn't
>     foreseen to provide such a server by Tramp; it should be available on
>     the remote side already.
>
> Tramp is supposed to do the client side of the job;
> I wouldn't expect it to do the server side.

Fish v0.0.3 introduces a protocol extension, which allows to transfer
the server code on request. I plan to ignore this command; Tramp could
fall back to POSIX shell commands via ssh method if there is no server
available. This is also conform with the fish protocol, at least since
v0.0.2.

Best regards, Michael.

Re: Patch for remote files in dnd.el

[Jason Rumney]

YAMAMOTO Mitsuharu wrote:
> Does the following change work for remote file access?  I can't test
> it by myself.
>   
Interesting hack. It makes the file URLs invalid but looks like it will 
work. But it violates Richards policy of being antagonistic towards 
Windows users, so I won't install it.

Re: Patch for remote files in dnd.el

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 07 Sep 2006 09:12:12 +0100, Jason Rumney <jasonr@gnu.org> said:

>> Does the following change work for remote file access?  I can't
>> test it by myself.
>> 
> Interesting hack. It makes the file URLs invalid but looks like it
> will work.

I'm not sure if file:////REMOTEHOST/DIRECTORY/NAME or
file://localhost//REMOTEHOST/DIRECTORY/NAME is invalid or not.  But
even the current code uses invalid file:/DIRECTORY/FILE. :-)

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Patch for remote files in dnd.el

[Jan Djärv]

Jason Rumney skrev:
> YAMAMOTO Mitsuharu wrote:
>> Does the following change work for remote file access?  I can't test
>> it by myself.
>>   
> Interesting hack. It makes the file URLs invalid but looks like it will 
> work. But it violates Richards policy of being antagonistic towards 
> Windows users, so I won't install it.

I've installed your patch along with code to handle remote url:s (with 
url-handle-mode) for non-MS platforms in dnd.el.  I can at least drop 
ftp://-urls from nautilus.  url-handler-mode does not handle smb://-urls, but 
it seems tramp do.  Is that an oversight in url-handle-mode?

	Jan D.

Re: Patch for remote files in dnd.el

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> YAMAMOTO Mitsuharu wrote:
>> Does the following change work for remote file access?  I can't test
>> it by myself.
>>   
> Interesting hack. It makes the file URLs invalid but looks like it
> will work. But it violates Richards policy of being antagonistic
> towards Windows users, so I won't install it.

It is not "antagonistic" not to make the FSF-maintained version of
Emacs a rallying ground for Windows-only extensions.  That would be
rather pointless, in contrast to consistently maintaining
functionality that is the same or similar across platforms.

I think it was pretty clear that if this feature was implemented in a
way that did not exclude free operating systems, there would be no
problem with it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Patch for remote files in dnd.el

[Jason Rumney]

David Kastrup wrote:
> I think it was pretty clear that if this feature was implemented in a
> way that did not exclude free operating systems, there would be no
> problem with it.
>   
You could at least look at my original patch before spouting such 
nonsense. There was no exclusion in this patch that restored 
functionality that is present in every version of Emacs released in the 
last 7 years.

Re: Patch for remote files in dnd.el

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
>>>>>> On Thu, 07 Sep 2006 09:12:12 +0100, Jason Rumney <jasonr@gnu.org> said:
> 
>>> Does the following change work for remote file access?  I can't
>>> test it by myself.
>>>
>> Interesting hack. It makes the file URLs invalid but looks like it
>> will work.
> 
> I'm not sure if file:////REMOTEHOST/DIRECTORY/NAME or
> file://localhost//REMOTEHOST/DIRECTORY/NAME is invalid or not.  But
> even the current code uses invalid file:/DIRECTORY/FILE. :-)

They all are invalid URLs, but only in some instances URLs are sent with DND. 
  The current code uses file:/DIRECTORY/FILE because some DND protocols sends 
this.  One could argue that when file:/DIRECTORY/FILE is used, it is not an 
URL, but a DND-specific information :-).

	Jan D.

Re: Patch for remote files in dnd.el

[Jan Djärv]

Jan Djärv skrev:
> 
> 
> Juanma Barranquero skrev:
>> On 9/7/06, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>> I've installed your patch along with code to handle remote url:s (with
>>> url-handle-mode) for non-MS platforms in dnd.el.
>>
>> ...which breaks bootstrapping (at least on Windows).
>>
>> Loading c:/bin/emacs/HEAD/lisp/dnd.el (source)...
>> Cannot open load file: url-handlers
>> make[1]: *** [bootstrap-emacs] Error -1
>> make[1]: Leaving directory `C:/bin/emacs/HEAD/src'
>> make: *** [bootstrap-gmake] Error 2
>>
> 
> Why is it loading dnd.el as source?   Didn't you recompile it?

Duh, stupid questions...

> Is 
> url-hanslers not used on W32?
> 

	Jan D.

Re: Patch for remote files in dnd.el

[Stefan Monnier]

>>> Does the following change work for remote file access?  I can't test
>>> it by myself.
>>> 
>> Interesting hack. It makes the file URLs invalid but looks like it will
>> work. But it violates Richards policy of being antagonistic towards
>> Windows users, so I won't install it.

> I've installed your patch along with code to handle remote url:s (with
> url-handle-mode) for non-MS platforms in dnd.el.  I can at least drop
> ftp://-urls from nautilus.  url-handler-mode does not handle smb://-urls,
> but it seems tramp do.  Is that an oversight in url-handle-mode?

I believe so, yes.  URL could also be expanded with an `ssh' protocol
(using Tramp).


        Stefan

Re: Patch for remote files in dnd.el

[Stuart D. Herring]

> I'm not sure if file:////REMOTEHOST/DIRECTORY/NAME or
> file://localhost//REMOTEHOST/DIRECTORY/NAME is invalid or not.  But
> even the current code uses invalid file:/DIRECTORY/FILE. :-)

See RFC 3986, section 3.2.2.  file:/dir/file is equivalent to
file:///dir/file and to file://localhost/dir/file.  In the first two cases
you mention, the "path" component of the URI is
"//REMOTEHOST/DIRECTORY/NAME", and it is up to the authority (in this
case, the system file name interpreter and file system) to determine its
meaning; presumably Windows interprets "//R/D/N" as being a UNC path.

The trick is in section 3.3: URIs without authority components (like
"file:/DIRECTORY/FILE") can't have paths that begin with two slashes,
since two slashes begin the authority.  So
"file://REMOTEHOST/DIRECTORY/NAME" is a file on a machine whose FQDN is
REMOTEHOST (according to RFC 1738), although I imagine that most systems
would simply attempt to resolve REMOTEHOST as a hostname (thus succeeding
with local names and local DNS systems) or, perhaps, would use some sort
of file-sharing protocol (like SMB) and interpret REMOTEHOST as an
identifier for use with it.

In short, "file:/dir/file" is valid, but perhaps only one of
"file://host/dir/file" and "file:////host/dir/file" will work (with any
given file-sharing arrangement).  Whichever mode seems to work with
existing arrangements should be used (even for local files, for
consistency).  Are there even any schemes in common use other than UNC? 
NFS in typical use doesn't involve URIs, and even in "public handle" use
involves nfs: URIs, not file:.

URIs are confusing business!  Hope this helps.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Patch for remote files in dnd.el

[KOBAYASHI Yasuhiro]

I tried the latest HEAD but I have the error which occured
with the filename with SPACEs or MULTIBYTEs.

Debugger entered--Lisp error: (error "Invalid file url")
  signal(error ("Invalid file url"))
  error("Invalid file url")
  dnd-open-unc-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
  dnd-open-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
  [...]

How about the following?

*** /tmp/dnd.el~	Fri Sep  8 08:35:07 2006
--- /tmp/dnd.el	Fri Sep  8 08:34:33 2006
***************
*** 181,187 ****
  and must have the format file://hostname/file-name. ACTION is ignored.
  //hostname/file-name is the unc path."
    (let ((unc-file (if (string-match "^file:" uri)
! 		      (substring (uri) 5))))
      (if (and unc-file (file-readable-p unc-file))
  	(progn
  	  (if dnd-open-file-other-window
--- 181,187 ----
  and must have the format file://hostname/file-name. ACTION is ignored.
  //hostname/file-name is the unc path."
    (let ((unc-file (if (string-match "^file:" uri)
! 		      (substring (url-unhex-string uri) 5))))
      (if (and unc-file (file-readable-p unc-file))
  	(progn
  	  (if dnd-open-file-other-window
-- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>

Re: Patch for remote files in dnd.el

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 7 Sep 2006 08:50:37 -0700 (PDT), "Stuart D. Herring" <herring@lanl.gov> said:

>> I'm not sure if file:////REMOTEHOST/DIRECTORY/NAME or
>> file://localhost//REMOTEHOST/DIRECTORY/NAME is invalid or not.  But
>> even the current code uses invalid file:/DIRECTORY/FILE. :-)

> See RFC 3986, section 3.2.2.  file:/dir/file is equivalent to
> file:///dir/file and to file://localhost/dir/file.

Ah, I thought that the latest definition of file: URL was in RFC 1738.
Thanks for the info.

RFC 1738 says:

  A file URL takes the form:

       file://<host>/<path>

  As a special case, <host> can be the string "localhost" or the empty
  string; this is interpreted as `the machine from which the URL is
  being interpreted'.

RFC 3986 says:

  If the URI scheme defines a default for host, then that default
  applies when the host subcomponent is undefined or when the
  registered name is empty (zero length).  For example, the "file" URI
  scheme is defined so that no authority, an empty host, and
  "localhost" all mean the end-user's machine, whereas the "http"
  scheme considers a missing authority or empty host invalid.

The latter mentions the "no authority" case, indeed.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Patch for remote files in dnd.el

[Jason Rumney]

Is this not a problem for local files as well? The "url" is constructed 
in the same way, and it is probable that Gnome, KDE etc will send such 
URLs (I don't have either in front of me right now, only CDE and Windows).


KOBAYASHI Yasuhiro wrote:
> I tried the latest HEAD but I have the error which occured
> with the filename with SPACEs or MULTIBYTEs.
>
> Debugger entered--Lisp error: (error "Invalid file url")
>   signal(error ("Invalid file url"))
>   error("Invalid file url")
>   dnd-open-unc-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
>   dnd-open-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
>   [...]
>
> How about the following?
>
> *** /tmp/dnd.el~	Fri Sep  8 08:35:07 2006
> --- /tmp/dnd.el	Fri Sep  8 08:34:33 2006
> ***************
> *** 181,187 ****
>   and must have the format file://hostname/file-name. ACTION is ignored.
>   //hostname/file-name is the unc path."
>     (let ((unc-file (if (string-match "^file:" uri)
> ! 		      (substring (uri) 5))))
>       (if (and unc-file (file-readable-p unc-file))
>   	(progn
>   	  (if dnd-open-file-other-window
> --- 181,187 ----
>   and must have the format file://hostname/file-name. ACTION is ignored.
>   //hostname/file-name is the unc path."
>     (let ((unc-file (if (string-match "^file:" uri)
> ! 		      (substring (url-unhex-string uri) 5))))
>       (if (and unc-file (file-readable-p unc-file))
>   	(progn
>   	  (if dnd-open-file-other-window
>   

Re: Patch for remote files in dnd.el

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 08 Sep 2006 09:25:20 +0100, Jason Rumney <jasonr@gnu.org> said:

> Is this not a problem for local files as well? The "url" is
> constructed in the same way, and it is probable that Gnome, KDE etc
> will send such URLs (I don't have either in front of me right now,
> only CDE and Windows).

For local files, %-escapes are unescaped when creating a file name
from a URL using dnd-get-local-file-name.  See also the following
message:

  Re: %-escapes in file URL
  http://lists.gnu.org/archive/html/emacs-devel/2006-05/msg01060.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Patch for remote files in dnd.el

[Richard Stallman]

    Does the following change work for remote file access?  I can't test
    it by myself.

What systems would you expect this code to work on?

Re: Patch for remote files in dnd.el

[Richard Stallman]

    But it violates Richards policy of being antagonistic towards 
    Windows users, so I won't install it.

We have no policy of being antagonistic to Windows users.  We have a
policy of not giving Microsoft Windows better support than GNU/Linux.

GNU Emacs does not exist for the purpose of helping people use
Microsoft Windows.  It is part of a project whose goal is to eliminate
proprietary software (such as Microsoft Windows).

Re: Patch for remote files in dnd.el

[Richard Stallman]

    You could at least look at my original patch before spouting such 
    nonsense. There was no exclusion in this patch that restored 
    functionality that is present in every version of Emacs released in the 
    last 7 years.

dnd.el was first installed less than two years ago.

Re: Patch for remote files in dnd.el

[Jason Rumney]

Richard Stallman wrote:
>     You could at least look at my original patch before spouting such 
>     nonsense. There was no exclusion in this patch that restored 
>     functionality that is present in every version of Emacs released in the 
>     last 7 years.
>
> dnd.el was first installed less than two years ago.
>   
Drag and drop functionality has been present in Emacs since April 1998. 
It was never a problem until I tried to restore the recent dnd.el based 
support to its former functionality.

Re: Patch for remote files in dnd.el

[Jan Djärv]

Richard Stallman skrev:
>     You could at least look at my original patch before spouting such 
>     nonsense. There was no exclusion in this patch that restored 
>     functionality that is present in every version of Emacs released in the 
>     last 7 years.
> 
> dnd.el was first installed less than two years ago.

I think the point was that there was a W32 version of DND before dnd.el.  On 
W32 UNC-paths just work if you give them to open.  Thus, UNC-paths that was 
DND:ed to Emacs worked on W32 before dnd.el.

	Jan D,

Re: Patch for remote files in dnd.el

[Richard Stallman]

    I think the point was that there was a W32 version of DND before dnd.el.

Do you mean that DND worked in Emacs on Microsoft Windows before it worked
on GNU/Linux?  If so, that sounds like a bad direction to have gone in,
precisely the sort of thing that we shouldn't do.

Re: Patch for remote files in dnd.el

[Jan Djärv]

Richard Stallman skrev:
>     I think the point was that there was a W32 version of DND before dnd.el.
> 
> Do you mean that DND worked in Emacs on Microsoft Windows before it worked
> on GNU/Linux?

Yes.

> If so, that sounds like a bad direction to have gone in,
> precisely the sort of thing that we shouldn't do.


	Jan D.

Re: Patch for remote files in dnd.el

[Jan Djärv]

Shall this be installed?  Can W32-users confirm that this works OK?

	Jan D.

KOBAYASHI Yasuhiro skrev:
> I tried the latest HEAD but I have the error which occured
> with the filename with SPACEs or MULTIBYTEs.
> 
> Debugger entered--Lisp error: (error "Invalid file url")
>   signal(error ("Invalid file url"))
>   error("Invalid file url")
>   dnd-open-unc-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
>   dnd-open-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" private)
>   [...]
> 
> How about the following?
> 
> *** /tmp/dnd.el~	Fri Sep  8 08:35:07 2006
> --- /tmp/dnd.el	Fri Sep  8 08:34:33 2006
> ***************
> *** 181,187 ****
>   and must have the format file://hostname/file-name. ACTION is ignored.
>   //hostname/file-name is the unc path."
>     (let ((unc-file (if (string-match "^file:" uri)
> ! 		      (substring (uri) 5))))
>       (if (and unc-file (file-readable-p unc-file))
>   	(progn
>   	  (if dnd-open-file-other-window
> --- 181,187 ----
>   and must have the format file://hostname/file-name. ACTION is ignored.
>   //hostname/file-name is the unc path."
>     (let ((unc-file (if (string-match "^file:" uri)
> ! 		      (substring (url-unhex-string uri) 5))))
>       (if (and unc-file (file-readable-p unc-file))
>   	(progn
>   	  (if dnd-open-file-other-window

Re: Patch for remote files in dnd.el

[Jason Rumney]

It works, but I just noticed that so does using dnd-open-local-file 
instead of dnd-open-unc-file, which avoids loading url*.elc if they are 
not already (they are on Windows though, so in practice this may not 
make much difference). So we could get rid of dnd-open-unc-file 
altogether. Note that the optional must-exist parameter to 
dnd-get-local-file-name does not work as advertised, and it is only ever 
called with it set to t. The only thing preventing remote files working 
on Windows before was the check in dnd-open-file. Since unc filenames 
are handled the same way as local filenames on Windows, it is not 
unreasonable to switch to using dnd-open-local-file.


Jan Djärv wrote:
>
> Shall this be installed?  Can W32-users confirm that this works OK?
>
>     Jan D.
>
> KOBAYASHI Yasuhiro skrev:
>> I tried the latest HEAD but I have the error which occured
>> with the filename with SPACEs or MULTIBYTEs.
>>
>> Debugger entered--Lisp error: (error "Invalid file url")
>>   signal(error ("Invalid file url"))
>>   error("Invalid file url")
>>   
>> dnd-open-unc-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" 
>> private)
>>   
>> dnd-open-file("file://NSZ/home/kobayays/My%20Documents/w_s3alog.csv" 
>> private)
>>   [...]
>>
>> How about the following?
>>
>> *** /tmp/dnd.el~    Fri Sep  8 08:35:07 2006
>> --- /tmp/dnd.el    Fri Sep  8 08:34:33 2006
>> ***************
>> *** 181,187 ****
>>   and must have the format file://hostname/file-name. ACTION is ignored.
>>   //hostname/file-name is the unc path."
>>     (let ((unc-file (if (string-match "^file:" uri)
>> !               (substring (uri) 5))))
>>       (if (and unc-file (file-readable-p unc-file))
>>       (progn
>>         (if dnd-open-file-other-window
>> --- 181,187 ----
>>   and must have the format file://hostname/file-name. ACTION is ignored.
>>   //hostname/file-name is the unc path."
>>     (let ((unc-file (if (string-match "^file:" uri)
>> !               (substring (url-unhex-string uri) 5))))
>>       (if (and unc-file (file-readable-p unc-file))
>>       (progn
>>         (if dnd-open-file-other-window
>

Re: Patch for remote files in dnd.el

[Jan Djärv]

Jason Rumney skrev:
> It works, but I just noticed that so does using dnd-open-local-file 
> instead of dnd-open-unc-file, which avoids loading url*.elc if they are 
> not already (they are on Windows though, so in practice this may not 
> make much difference). So we could get rid of dnd-open-unc-file 
> altogether. Note that the optional must-exist parameter to 
> dnd-get-local-file-name does not work as advertised, and it is only ever 
> called with it set to t. The only thing preventing remote files working 
> on Windows before was the check in dnd-open-file. Since unc filenames 
> are handled the same way as local filenames on Windows, it is not 
> unreasonable to switch to using dnd-open-local-file.

Sounds OK to me.  Can you check that in, as you also can test it?

	Jan D.

Re: Patch for remote files in dnd.el

[Jason Rumney]

Jan Djärv wrote:
> Jason Rumney skrev:
>> It works, but I just noticed that so does using dnd-open-local-file 
>> instead of dnd-open-unc-file, which avoids loading url*.elc if they 
>> are not already (they are on Windows though, so in practice this may 
>> not make much difference). So we could get rid of dnd-open-unc-file 
>> altogether. Note that the optional must-exist parameter to 
>> dnd-get-local-file-name does not work as advertised, and it is only 
>> ever called with it set to t. The only thing preventing remote files 
>> working on Windows before was the check in dnd-open-file. Since unc 
>> filenames are handled the same way as local filenames on Windows, it 
>> is not unreasonable to switch to using dnd-open-local-file.
>
> Sounds OK to me.  Can you check that in, as you also can test it?

Will do, later today.