Re: [O] [bug?] Tramp tries to open remote file links
Andreas Leha wrote: Sebastien Vauban sva-n...@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. Best regards, Seb -- Sebastien Vauban
Re: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@mygooglest.com writes: Andreas Leha wrote: Sebastien Vauban sva-n...@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
Re: [O] [bug?] Tramp tries to open remote file links
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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@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
[O] [bug?] Tramp tries to open remote file links
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:/m...@somewhere.org:papers/current.pdf][paper]] --8---cut here---end---8--- Errors: ╭ │ Tramp: Opening connection for m...@somewhere.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 m...@somewhere.org using plink...failed ╰ Is this supposed to be normal? Why does Tramp open the file? Best regards, Seb -- Sebastien Vauban
Re: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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-ohc15rc7jgtnlxjtenl...@public.gmane.org:papers/current.pdf][paper]] Errors: ╭ │ Tramp: Opening connection for me-ohc15rc7jgtnlxjtenl...@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-ohc15rc7jgtnlxjtenl...@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-ohc15rc7jgtnlxjtenl...@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-ohc15rc7jgtnlxjtenl...@public.gmane.org:papers/current.pdf][paper]] Alternatively, you could choose another file name. Best regards, Seb Best regards, Michael.
Re: [O] [bug?] Tramp tries to open remote file links
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:/m...@somewhere.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 /m...@somewhere.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:/:/m...@somewhere.org:papers/current.pdf][paper]] Alternatively, you could choose another file name. Best regards, Seb -- Sebastien Vauban
Re: [O] [bug?] Tramp tries to open remote file links
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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
Michael Albinus wrote: Sebastien Vauban sva-n...@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). But DocView won't display a PDF file as an image inside a buffer of text, will it? Best regards, Seb -- Sebastien Vauban
Re: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [bug?] Tramp tries to open remote file links
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: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@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: [O] [bug?] Tramp tries to open remote file links
Hello, Nicolas Richard theonewiththeevill...@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
