From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wanrong Lin Subject: Bug found (but don't know to fix) Date: Mon, 19 May 2008 17:59:11 -0400 Message-ID: <4831F82F.90902@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0074865339==" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JyDO7-0007rU-RU for emacs-orgmode@gnu.org; Mon, 19 May 2008 17:59:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JyDO6-0007qr-34 for emacs-orgmode@gnu.org; Mon, 19 May 2008 17:59:23 -0400 Received: from [199.232.76.173] (port=56957 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JyDO5-0007qd-Se for emacs-orgmode@gnu.org; Mon, 19 May 2008 17:59:22 -0400 Received: from yw-out-1718.google.com ([74.125.46.154]:20982) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JyDO5-0006k3-BQ for emacs-orgmode@gnu.org; Mon, 19 May 2008 17:59:21 -0400 Received: by yw-out-1718.google.com with SMTP id 9so1237858ywk.66 for ; Mon, 19 May 2008 14:59:18 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org This is a multi-part message in MIME format. --===============0074865339== Content-Type: multipart/alternative; boundary="------------090306010501070205060709" This is a multi-part message in MIME format. --------------090306010501070205060709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Carsten: I have observed that in Windows "org-open-at-point" (bound to RET key in my config) does not work on something like this: file:\\hostname\path Today I dug a little bit into it, and found the problem is here (in red): (defun org-open-file (path &optional in-emacs line search) "Open the file at PATH. First, this expands any special file name abbreviations. Then the configuration variable `org-file-apps' is checked if it contains an entry for this file type, and if yes, the corresponding command is launched. If no application is found, Emacs simply visits the file. With optional argument IN-EMACS, Emacs will visit the file. Optional LINE specifies a line to go to, optional SEARCH a string to search for. If LINE or SEARCH is given, the file will always be opened in Emacs. If the file does not exist, an error is thrown." (setq in-emacs (or in-emacs line search)) (let* ((file (if (equal path "") buffer-file-name (substitute-in-file-name *(expand-file-name path)*))) *(expand-file-name path) *replaces all backslashes with forward slashes, and later in the same function (if search (org-link-search search)))) ((consp cmd) *(eval cmd)*) Here "cmd" variable is "(w32-shell-execute "open" file)", and w32-shell-execute will complain about the file not existing. When in-emacs is t, everything works fine, as Emacs understand both forward and backward slashes. Also, it works fine on regular file path like this: file:c:\path\file.txt That is because somehow my Windows system is setup (by our IT guys) to understand both forward and backward slashes, but that only works on regular file paths, not the Windows shared directory paths. I wonder whether this can get fixed. Thank you very much. Wanrong --------------090306010501070205060709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Carsten:

I have observed that in Windows "org-open-at-point" (bound to RET key in my config) does not work on something like this:

file:\\hostname\path

Today I dug a little bit into it, and found the problem is here (in red):

(defun org-open-file (path &optional in-emacs line search)
  "Open the file at PATH.
First, this expands any special file name abbreviations.  Then the
configuration variable `org-file-apps' is checked if it contains an
entry for this file type, and if yes, the corresponding command is launched.
If no application is found, Emacs simply visits the file.
With optional argument IN-EMACS, Emacs will visit the file.
Optional LINE specifies a line to go to, optional SEARCH a string to
search for.  If LINE or SEARCH is given, the file will always be
opened in Emacs.
If the file does not exist, an error is thrown."
  (setq in-emacs (or in-emacs line search))
  (let* ((file (if (equal path "")
           buffer-file-name
         (substitute-in-file-name (expand-file-name path))))

(expand-file-name path) replaces all backslashes with forward slashes, and later in the same function


    (if search (org-link-search search))))
     ((consp cmd)
      (eval cmd))

Here "cmd" variable is "(w32-shell-execute "open" file)", and w32-shell-execute will complain about the file not existing.

When in-emacs is t, everything works fine, as Emacs understand both forward and backward slashes.

Also, it works fine on regular file path like this:
 file:c:\path\file.txt

That is because somehow my Windows system is setup (by our IT guys) to understand both forward and backward slashes, but that only works on regular file paths, not the Windows shared directory paths.

I wonder whether this can get fixed. Thank you very much.

Wanrong

--------------090306010501070205060709-- --===============0074865339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --===============0074865339==--