[bug?] Tramp tries to open remote file links

[bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Hello,

When I just open an Org file that has a link to a remote file, Tramp
tries to open it, leading to errors and timeouts when offline, at least.

--8<---------------cut here---------------start------------->8---
* References

Some files of interest:

[[file:/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf][paper]]
--8<---------------cut here---------------end--------------->8---

Errors:

  ╭────
  │ Tramp: Opening connection for me-oHC15RC7JGTNLxjTenLetw@public.gmane.org using plink...
  │ Tramp: Sending command `plink -l me  -ssh -t somewhere.org " env 'TERM=dumb' 'PROMPT_COMMAND=' 'PS1=#$ ' /bin/sh " && exit || exit'
  │ Tramp: Waiting for prompts from remote shell...
  │ Tramp failed to connect.  If this happens repeatedly, try
  │     `M-x tramp-cleanup-this-connection'
  │ Tramp: Waiting for prompts from remote shell...failed
  │ Tramp: Opening connection for me-oHC15RC7JGTNLxjTenLetw@public.gmane.org using plink...failed
  ╰────

Is this supposed to be normal?  Why does Tramp open the file?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Nicolas Richard]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:
> Hello,
>
> When I just open an Org file that has a link to a remote file, Tramp
> tries to open it, leading to errors and timeouts when offline, at least.

It doesn't happen to me. I tried "emacs -Q path/to/test.org" and the
file opened normally.

Grepping, I see that tramp-maybe-open-connection is responsible for the
tramp messages. so you could eval:
(trace-function-background
 'tramp-maybe-open-connection
 "*trace*"
 (lambda () (with-output-to-string (backtrace))))

then reproduce and look into the buffer *trace* to see what called
tramp.

Call M-x untrace-function RET TAB RET to remove the tracing.

-- 
Nico.

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Hello,

Hi Sebastien,

> When I just open an Org file that has a link to a remote file, Tramp
> tries to open it, leading to errors and timeouts when offline, at least.
>
> * References
>
> Some files of interest:
>
> [[file:/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf][paper]]
>
> Errors:
>
>   ╭────
>   │ Tramp: Opening connection for
> me-oHC15RC7JGTNLxjTenLetw@public.gmane.org using plink...
>   │ Tramp: Sending command `plink -l me -ssh -t somewhere.org " env
> 'TERM=dumb' 'PROMPT_COMMAND=' 'PS1=#$ ' /bin/sh " && exit || exit'
>   │ Tramp: Waiting for prompts from remote shell...
>   │ Tramp failed to connect.  If this happens repeatedly, try
>   │     `M-x tramp-cleanup-this-connection'
>   │ Tramp: Waiting for prompts from remote shell...failed
>   │ Tramp: Opening connection for
> me-oHC15RC7JGTNLxjTenLetw@public.gmane.org using plink...failed
>   ╰────
>
> Is this supposed to be normal?  Why does Tramp open the file?

Because Tramp has been instructed so? I suppose, following the above
link results in

(insert-file-contents "/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf")

This is remote file name syntax, and Tramp tries to do its job, using
the default method "plink". You could avoid Tramp's reaction by a link
like (untested)

[[file:/:/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf][paper]]

Alternatively, you could choose another file name.

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Michael Albinus wrote:
> Sebastien Vauban writes:
>> When I just open an Org file that has a link to a remote file, Tramp
>> tries to open it, leading to errors and timeouts when offline, at least.
>>
>> * References
>>
>> Some files of interest:
>>
>> [[file:/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf][paper]]
>>
>> Is this supposed to be normal?  Why does Tramp open the file?
>
> Because Tramp has been instructed so? I suppose, following the above
> link results in

I think we did not understand each other (or did we?) because that's the
thing: I don't follow the link, I just open the file which contains such
a link.

See http://screencast.com/t/aXoxf9D1P.

> (insert-file-contents "/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf")
>
> This is remote file name syntax, and Tramp tries to do its job, using
> the default method "plink". You could avoid Tramp's reaction by a link
> like (untested)
>
> [[file:/:/me-oHC15RC7JGTNLxjTenLetw@public.gmane.org:papers/current.pdf][paper]]
>
> Alternatively, you could choose another file name.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Hello Nicolas,

Nicolas Richard wrote:
> Sebastien Vauban writes:
>> When I just open an Org file that has a link to a remote file, Tramp
>> tries to open it, leading to errors and timeouts when offline, at least.
>
> It doesn't happen to me. I tried "emacs -Q path/to/test.org" and the
> file opened normally.
>
> Grepping, I see that tramp-maybe-open-connection is responsible for the
> tramp messages. so you could eval:
> (trace-function-background
>  'tramp-maybe-open-connection
>  "*trace*"
>  (lambda () (with-output-to-string (backtrace))))
>
> then reproduce and look into the buffer *trace* to see what called
> tramp.

--8<---------------cut here---------------start------------->8---
1 -> (tramp-maybe-open-connection [#("plink" 0 5 (tramp-default t)) "myself" "some.where.org" "papers/last.pdf" nil])  backtrace()
  (let ((standard-output standard-output)) (backtrace))
  (progn (let ((standard-output standard-output)) (backtrace)) (save-current-buffer (set-buffer standard-output) (buffer-string)))
  (unwind-protect (progn (let ((standard-output standard-output)) (backtrace)) (save-current-buffer (set-buffer standard-output) (buffer-string))) (kill-buffer standard-output))
  (let ((standard-output (get-buffer-create (generate-new-buffer-name " *string-output*")))) (unwind-protect (progn (let ((standard-output standard-output)) (backtrace)) (save-current-buffer (set-buffer standard-output) (buffer-string))) (kill-buffer standard-output)))
  (lambda nil (let ((standard-output (get-buffer-create (generate-new-buffer-name " *string-output*")))) (unwind-protect (progn (let ((standard-output standard-output)) (backtrace)) (save-current-buffer (set-buffer standard-output) (buffer-string))) (kill-buffer standard-output))))()

  <... lots of contents...>

  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" ((8960 3 . 4947) (24647 . 36859)))
  find-file-noselect("~/test.org" nil nil t)
  (with-no-warnings (funcall ad--addoit-function filename wildcards))
  (setq ad-return-value (with-no-warnings (funcall ad--addoit-function filename wildcards)))
  (let ((filename filename) (find-file-time-start (float-time))) (message "(Info) Finding file %s..." filename) (setq ad-return-value (with-no-warnings (funcall ad--addoit-function filename wildcards))) (message "(Info) Found file %s in %.2f s" filename (- (float-time) find-file-time-start)))
  (let (ad-return-value) (let ((filename filename) (find-file-time-start (float-time))) (message "(Info) Finding file %s..." filename) (setq ad-return-value (with-no-warnings (funcall ad--addoit-function filename wildcards))) (message "(Info) Found file %s in %.2f s" filename (- (float-time) find-file-time-start))) ad-return-value)
  ad-Advice-find-file(...
  find-file("~/test.org" t)
  funcall-interactively(find-file "~/test.org" t)
  call-interactively(find-file nil nil)
  command-execute(find-file)
--8<---------------cut here---------------end--------------->8---

See http://screencast.com/t/pXrFeTR5J9
for a video of the full trace.

And, yes, I do have an advice around find-file:

--8<---------------cut here---------------start------------->8---
  (defadvice find-file (around leuven-find-file activate)
    "Open the file named FILENAME and report time spent."
    (let ((filename (ad-get-arg 0))
          (find-file-time-start (float-time)))
      (message "(Info) Finding file %s..." filename)
      ad-do-it
      (message "(Info) Found file %s in %.2f s" filename
               (- (float-time) find-file-time-start))))
--8<---------------cut here---------------end--------------->8---

Though, commenting that did not solve the current problem at hand...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

>>> Is this supposed to be normal?  Why does Tramp open the file?
>>
>> Because Tramp has been instructed so? I suppose, following the above
>> link results in
>
> I think we did not understand each other (or did we?) because that's the
> thing: I don't follow the link, I just open the file which contains such
> a link.

It doesn't for me, when I have a simple org file with just your
example. I use org 8.2.6.

Do you have some customization, which let org expand links per default?
Does it also happen when you start "emacs -Q"?

Or do you have some customization code in the file itself? Local
variables, code snippets to be evaluated when opening the file?

> See http://screencast.com/t/aXoxf9D1P.

This does not work for me :-(

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Nicolas Richard]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:
>
>   <... lots of contents...>
>
>   org-mode()

This means that org-mode calls things which in the end calls
tramp-maybe-open-connection. But what "something" is is in the "lots of
contents" part that you didn't show. Unfortunately a video isn't very
searchable.

Still, I spotted that org-element-context is called at some point, which
in turn calls org-element-link-parser, and that's what does
expand-file-name. Perhaps that would be a bug ?

-- 
Nico.

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Nicolas Richard wrote:
> Sebastien Vauban writes:
>
>>   org-mode()
>
> This means that org-mode calls things which in the end calls
> tramp-maybe-open-connection. But what "something" is is in the "lots
> of contents" part that you didn't show. Unfortunately a video isn't
> very searchable.
>
> Still, I spotted that org-element-context is called at some point,
> which in turn calls org-element-link-parser, and that's what does
> expand-file-name. Perhaps that would be a bug ?

I found out the responsible line in my setup:

--8<---------------cut here---------------start------------->8---
  ;; show inline images when loading a new Org file
  (setq org-startup-with-inline-images t)
--8<---------------cut here---------------end--------------->8---

With it, the problem occurs; without, it does not.

Though, is it normal to try to open a remote PDF file while Emacs is
unable of displaying it in the buffer (unlike PNG files, IIUC)?

Maybe that's not a bug per se, but rather a feature that should only be
enabled for specific file extensions?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

>   <... lots of contents...>

Well, Tramp is invoked via (expand-file-name "/myself@..."). The call
hierarchy is (if I haven't overseen something)

expand-file-name
org-element-link-parser
org-element-context
org-image-file-name-regexp
org-display-inline-images
org-mode

Maybe it is worth to find out, why org-display-inline-images is invoked?

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Though, is it normal to try to open a remote PDF file while Emacs is
> unable of displaying it in the buffer (unlike PNG files, IIUC)?

Emacs is also able to open and display a remote PDF file.

> Maybe that's not a bug per se, but rather a feature that should only be
> enabled for specific file extensions?

I wouldn't parse URI-like file names in org-mode at all. There is
url-handlers.el, which shall do it proper.

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Michael Albinus wrote:
> Sebastien Vauban writes:
>
>> Though, is it normal to try to open a remote PDF file while Emacs is
>> unable of displaying it in the buffer (unlike PNG files, IIUC)?
>
> Emacs is also able to open and display a remote PDF file.

IIUC, Emacs can't display real PDF files. It only can convert them (via
DocView) to PNG, one per page, in order to give a similar experience.

If that's right, a PDF file on itself, be it an image, never will be
displayed in Emacs, unless one adds extra machinery in Org mode.

Then, should Org try to open a PDF (remote or local, same question)?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news@mygooglest.com> writes:

> Michael Albinus wrote:
>> Sebastien Vauban writes:
>>
>>> Though, is it normal to try to open a remote PDF file while Emacs is
>>> unable of displaying it in the buffer (unlike PNG files, IIUC)?
>>
>> Emacs is also able to open and display a remote PDF file.
>
> IIUC, Emacs can't display real PDF files. It only can convert them (via
> DocView) to PNG, one per page, in order to give a similar experience.

That's what I'm speaking about. And if you have a local DocView
installation, it works for either remote or local files (Tramp provides
a local copy of the remote file).

If you want to suppress PDFs in org, you shall do it regardless of its
location.

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Michael Albinus wrote:
> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>> Michael Albinus wrote:
>>> Sebastien Vauban writes:
>>>
>>>> Though, is it normal to try to open a remote PDF file while Emacs is
>>>> unable of displaying it in the buffer (unlike PNG files, IIUC)?
>>>
>>> Emacs is also able to open and display a remote PDF file.
>>
>> IIUC, Emacs can't display real PDF files. It only can convert them (via
>> DocView) to PNG, one per page, in order to give a similar experience.
>
> That's what I'm speaking about. And if you have a local DocView
> installation, it works for either remote or local files (Tramp provides
> a local copy of the remote file).

But DocView won't display a PDF file as an image inside a buffer of
text, will it?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Nicolas Richard]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
> With it, the problem occurs; without, it does not.

Also note that this is a problem in master only ; maint has an older
version of org-display-inline-images which doesn't use org-element.

> Though, is it normal to try to open a remote PDF file while Emacs is
> unable of displaying it in the buffer (unlike PNG files, IIUC)?

Org Mode is not trying to display the PDF (at least not at that point).
The problems occurs when parsing the buffer : org-element-link-parser
uses expand-file-name to normalize the URI. Should it ? IDK. Nicolas
G might have an opinion on this.

-- 
Nico.

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

>> That's what I'm speaking about. And if you have a local DocView
>> installation, it works for either remote or local files (Tramp provides
>> a local copy of the remote file).
>
> But DocView won't display a PDF file as an image inside a buffer of
> text, will it?

No, it uses an own buffer.

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Michael Albinus wrote:
> Sebastien Vauban writes:
>
>>> That's what I'm speaking about. And if you have a local DocView
>>> installation, it works for either remote or local files (Tramp
>>> provides a local copy of the remote file).
>>
>> But DocView won't display a PDF file as an image inside a buffer of
>> text, will it?
>
> No, it uses an own buffer.

OK, so we do agree that trying to open a PDF file in the context of
*inline images*[1] does not make much sense, right?

Best regards,
  Seb

[1] (setq org-startup-with-inline-images t)

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Nick Dokos]

Sebastien Vauban <sva-news@mygooglest.com>
writes:

> Michael Albinus wrote:
>> Sebastien Vauban writes:
>>
>>>> That's what I'm speaking about. And if you have a local DocView
>>>> installation, it works for either remote or local files (Tramp
>>>> provides a local copy of the remote file).
>>>
>>> But DocView won't display a PDF file as an image inside a buffer of
>>> text, will it?
>>
>> No, it uses an own buffer.
>
> OK, so we do agree that trying to open a PDF file in the context of
> *inline images*[1] does not make much sense, right?
>

Are you trying to say that the org code for inline images should figure
out that such a link should *not* be inlined because it would open a
non-image file? If so, how would you define "non-image file"? And would
that definition vary depending on the capabilities of one's emacs (e.g.
maybe my emacs can display PNG files but not GIF files)?

Nick

Re: [bug?] Tramp tries to open remote file links

[Nicolas Goaziou]

Hello,

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Org Mode is not trying to display the PDF (at least not at that point).
> The problems occurs when parsing the buffer : org-element-link-parser
> uses expand-file-name to normalize the URI. Should it ? IDK. Nicolas
> G might have an opinion on this.

I guess the only way to know is to remove `expand-file-name'. We'll see
if someone complains.

Done in master.


Regards,

-- 
Nicolas Goaziou

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Nick Dokos wrote:
> Sebastien Vauban writes:
>> Michael Albinus wrote:
>>> Sebastien Vauban writes:
>>>
>>>>> That's what I'm speaking about. And if you have a local DocView
>>>>> installation, it works for either remote or local files (Tramp
>>>>> provides a local copy of the remote file).
>>>>
>>>> But DocView won't display a PDF file as an image inside a buffer of
>>>> text, will it?
>>>
>>> No, it uses an own buffer.
>>
>> OK, so we do agree that trying to open a PDF file in the context of
>> *inline images*[1] does not make much sense, right?
>
> Are you trying to say that the org code for inline images should figure
> out that such a link should *not* be inlined because it would open a
> non-image file?

I'm not sure I use the right wording, but I'm trying to say that Org
(when set to open inline images) should never try to open PDF files, as
they can't be opened inline in a buffer anyway.

> If so, how would you define "non-image file"?

There are variables such as `image-library-alist' which show some image
extensions.

> And would that definition vary depending on the capabilities of one's
> emacs (e.g.  maybe my emacs can display PNG files but not GIF files)?

Every Emacs instance can be tested to see if it supports some file
extension; for example, for PNG:

M-: (image-type-available-p 'png)

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Michael Albinus]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> I'm not sure I use the right wording, but I'm trying to say that Org
> (when set to open inline images) should never try to open PDF files, as
> they can't be opened inline in a buffer anyway.

This might change, when Emacs' xwidget branch is merged into trunk.
And no, I don't know when this will happen.

> Best regards,
>   Seb

Best regards, Michael.

Re: [bug?] Tramp tries to open remote file links

[Andreas Leha]

Sebastien Vauban <sva-news@mygooglest.com>
writes:

> Nick Dokos wrote:
>> Sebastien Vauban writes:
>>> Michael Albinus wrote:
>>>> Sebastien Vauban writes:
>>>>
>>>>>> That's what I'm speaking about. And if you have a local DocView
>>>>>> installation, it works for either remote or local files (Tramp
>>>>>> provides a local copy of the remote file).
>>>>>
>>>>> But DocView won't display a PDF file as an image inside a buffer of
>>>>> text, will it?
>>>>
>>>> No, it uses an own buffer.
>>>
>>> OK, so we do agree that trying to open a PDF file in the context of
>>> *inline images*[1] does not make much sense, right?
>>
>> Are you trying to say that the org code for inline images should figure
>> out that such a link should *not* be inlined because it would open a
>> non-image file?
>
> I'm not sure I use the right wording, but I'm trying to say that Org
> (when set to open inline images) should never try to open PDF files, as
> they can't be opened inline in a buffer anyway.
>

I produce most of my plots as pdfs.  Removing the possibility to display
them with inline image would be a loss for me.

[...]

- Andreas

Re: [bug?] Tramp tries to open remote file links

[Sebastien Vauban]

Andreas Leha wrote:
> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>> Nick Dokos wrote:
>>> Sebastien Vauban writes:
>>>> Michael Albinus wrote:
>>>>> Sebastien Vauban writes:
>>>>>
>>>>>>> That's what I'm speaking about. And if you have a local DocView
>>>>>>> installation, it works for either remote or local files (Tramp
>>>>>>> provides a local copy of the remote file).
>>>>>>
>>>>>> But DocView won't display a PDF file as an image inside a buffer of
>>>>>> text, will it?
>>>>>
>>>>> No, it uses an own buffer.
>>>>
>>>> OK, so we do agree that trying to open a PDF file in the context of
>>>> *inline images*[1] does not make much sense, right?
>>>
>>> Are you trying to say that the org code for inline images should figure
>>> out that such a link should *not* be inlined because it would open a
>>> non-image file?
>>
>> I'm not sure I use the right wording, but I'm trying to say that Org
>> (when set to open inline images) should never try to open PDF files, as
>> they can't be opened inline in a buffer anyway.
>
> I produce most of my plots as pdfs.  Removing the possibility to display
> them with inline image would be a loss for me.

You mean you see your PDF images inside your Org buffer, along with the
text?

How did you do that?  I never got any PDF displayed inside a text
buffer.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [bug?] Tramp tries to open remote file links

[Andreas Leha]

Sebastien Vauban <sva-news@mygooglest.com>
writes:

> Andreas Leha wrote:
>> Sebastien Vauban <sva-news@mygooglest.com> writes:
>>> Nick Dokos wrote:
>>>> Sebastien Vauban writes:
>>>>> Michael Albinus wrote:
>>>>>> Sebastien Vauban writes:
>>>>>>
>>>>>>>> That's what I'm speaking about. And if you have a local DocView
>>>>>>>> installation, it works for either remote or local files (Tramp
>>>>>>>> provides a local copy of the remote file).
>>>>>>>
>>>>>>> But DocView won't display a PDF file as an image inside a buffer of
>>>>>>> text, will it?
>>>>>>
>>>>>> No, it uses an own buffer.
>>>>>
>>>>> OK, so we do agree that trying to open a PDF file in the context of
>>>>> *inline images*[1] does not make much sense, right?
>>>>
>>>> Are you trying to say that the org code for inline images should figure
>>>> out that such a link should *not* be inlined because it would open a
>>>> non-image file?
>>>
>>> I'm not sure I use the right wording, but I'm trying to say that Org
>>> (when set to open inline images) should never try to open PDF files, as
>>> they can't be opened inline in a buffer anyway.
>>
>> I produce most of my plots as pdfs.  Removing the possibility to display
>> them with inline image would be a loss for me.
>
> You mean you see your PDF images inside your Org buffer, along with the
> text?
>
> How did you do that?  I never got any PDF displayed inside a text
> buffer.
>

Neither do I.  Please disregard my previous message.  Clearly not enough coffee
yesterday ;-)

Andreas