* :EXPORT_FILE_NAME: in new exporter possible? @ 2013-03-21 13:06 Rainer Stengele 2013-03-21 15:34 ` Eric Abrahamsen 2013-03-22 0:20 ` John Hendy 0 siblings, 2 replies; 21+ messages in thread From: Rainer Stengele @ 2013-03-21 13:06 UTC (permalink / raw) To: emacs-orgmode Hi, Exporting to HTML I cannot get EXPORT_FILE_NAME to work: :PROPERTIES: :VISIBILITY: folded #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org #+CATEGORY: ROB :EXPORT_FILE_NAME: //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html :END: :EXPORT_FILE_NAME: entry is in one line. Is this still possible with the new exporter? How to deal with spaces in filepaths? Thanks, Rainer Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-21 13:06 :EXPORT_FILE_NAME: in new exporter possible? Rainer Stengele @ 2013-03-21 15:34 ` Eric Abrahamsen 2013-03-21 23:15 ` Andreas Leha 2013-03-22 0:20 ` John Hendy 1 sibling, 1 reply; 21+ messages in thread From: Eric Abrahamsen @ 2013-03-21 15:34 UTC (permalink / raw) To: emacs-orgmode Rainer Stengele <rainer.stengele@online.de> writes: > Hi, > > Exporting to HTML I cannot get EXPORT_FILE_NAME to work: > > :PROPERTIES: > :VISIBILITY: folded > #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org > #+CATEGORY: ROB > :EXPORT_FILE_NAME: > //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html > :END: > > :EXPORT_FILE_NAME: entry is in one line. Tangential to the actual problem here, when I opened this message in gnus, my minibuffer showed me two copies of the error: Cannot read file "/home/eric/org/GLOBAL_SETUP_DIPLAN.org" Should I be a little worried that a #+SETUPFILE command in a news message I receive tries to load an arbitrary filepath on my local machine?? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-21 15:34 ` Eric Abrahamsen @ 2013-03-21 23:15 ` Andreas Leha 2013-03-21 23:23 ` Bastien 0 siblings, 1 reply; 21+ messages in thread From: Andreas Leha @ 2013-03-21 23:15 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Rainer Stengele <rainer.stengele@online.de> writes: > >> Hi, >> >> Exporting to HTML I cannot get EXPORT_FILE_NAME to work: >> >> :PROPERTIES: >> :VISIBILITY: folded >> #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org >> #+CATEGORY: ROB >> :EXPORT_FILE_NAME: >> //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html >> :END: >> >> :EXPORT_FILE_NAME: entry is in one line. > > Tangential to the actual problem here, when I opened this message in > gnus, my minibuffer showed me two copies of the error: > > Cannot read file "/home/eric/org/GLOBAL_SETUP_DIPLAN.org" > > Should I be a little worried that a #+SETUPFILE command in a news > message I receive tries to load an arbitrary filepath on my local > machine?? It was the same for me and this should definitely not happen. So, I am also 'a little worried'. Is this a problem with my gnus setup or an orgmode problem? Regards, Andreas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-21 23:15 ` Andreas Leha @ 2013-03-21 23:23 ` Bastien 2013-03-25 5:45 ` Bastien 0 siblings, 1 reply; 21+ messages in thread From: Bastien @ 2013-03-21 23:23 UTC (permalink / raw) To: Andreas Leha; +Cc: emacs-orgmode Hi Andreas and Eric, Andreas Leha <andreas.leha@med.uni-goettingen.de> writes: > It was the same for me and this should definitely not happen. So, I am > also 'a little worried'. Is this a problem with my gnus setup or an > orgmode problem? This is a problem with Org -- I have a patch for this on my local branch, but I will push this branch only tomorrow. Thanks for raising this issue, it's pretty annoying. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-21 23:23 ` Bastien @ 2013-03-25 5:45 ` Bastien 2013-03-25 10:09 ` Achim Gratz 0 siblings, 1 reply; 21+ messages in thread From: Bastien @ 2013-03-25 5:45 UTC (permalink / raw) To: Andreas Leha; +Cc: emacs-orgmode Bastien <bzg@altern.org> writes: > This is a problem with Org -- I have a patch for this on my local > branch, but I will push this branch only tomorrow. Applied now, thanks. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 5:45 ` Bastien @ 2013-03-25 10:09 ` Achim Gratz 2013-03-25 14:57 ` Bastien 0 siblings, 1 reply; 21+ messages in thread From: Achim Gratz @ 2013-03-25 10:09 UTC (permalink / raw) To: emacs-orgmode Am 25.03.2013 06:45, schrieb Bastien: > Bastien <bzg@altern.org> writes: > >> This is a problem with Org -- I have a patch for this on my local >> branch, but I will push this branch only tomorrow. > > Applied now, thanks. I'd like to ask you to revisit that change. I don't think the question of whether #+SETUPFILE should be honored can be decided based on whether the buffer is read-only. I'm not entirely sure what Gnus does to trigger that foray into Org (a quick glance in the documentation didn't show anything), but if anything this indicates that we might need a "safe mode" for Org to open untrusted files. Regards, -- Achim. (on the road :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 10:09 ` Achim Gratz @ 2013-03-25 14:57 ` Bastien 2013-03-25 15:09 ` Achim Gratz 0 siblings, 1 reply; 21+ messages in thread From: Bastien @ 2013-03-25 14:57 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@Nexgo.DE> writes: > Am 25.03.2013 06:45, schrieb Bastien: >> Bastien <bzg@altern.org> writes: >> >>> This is a problem with Org -- I have a patch for this on my local >>> branch, but I will push this branch only tomorrow. >> >> Applied now, thanks. > > I'd like to ask you to revisit that change. I don't think the question of > whether #+SETUPFILE should be honored can be decided based on whether the > buffer is read-only. I acknowledge this is not the ideal solution but it is better than the current behavior. > I'm not entirely sure what Gnus does to trigger that foray into Org > (a quick glance in the documentation didn't show anything), but if > anything this indicates that we might need a "safe mode" for Org to > open untrusted files. Feel free to propose a better behavior here. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 14:57 ` Bastien @ 2013-03-25 15:09 ` Achim Gratz 2013-03-25 15:54 ` Bastien 0 siblings, 1 reply; 21+ messages in thread From: Achim Gratz @ 2013-03-25 15:09 UTC (permalink / raw) To: emacs-orgmode Am 25.03.2013 15:57, schrieb Bastien: >> I'm not entirely sure what Gnus does to trigger that foray into Org >> (a quick glance in the documentation didn't show anything), but if >> anything this indicates that we might need a "safe mode" for Org to >> open untrusted files. > > Feel free to propose a better behavior here. As I said, I don't even know why Gnus decides it should treat this mail as an Org file. From the sources of Gnus, it appears that it should only do this if the MIME type was text/x-org. Rainers mail didn't have this MIME type nor was it a multipart MIME mail that had such a part, yet Gnus triggered the buffer with "Org" as the major mode, which seems to indicate that the MIME type must somehow have been inferred. I can prevent that using orgstruct-mode instead, but as I proposed already there should be a "safe" variant of org-mode (a derived mode perhaps) that doesn't load any axtra files and doesn't run any source blocks. Of course, Gnus then should use this mode (it is only meant for proper fontification anyway, which I suppose must be possible without firing a whole major mode). Regards, -- Achim. (on the road :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 15:09 ` Achim Gratz @ 2013-03-25 15:54 ` Bastien 2013-03-25 16:13 ` Achim Gratz 0 siblings, 1 reply; 21+ messages in thread From: Bastien @ 2013-03-25 15:54 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 940 bytes --] Achim Gratz <Stromeko@Nexgo.DE> writes: > As I said, I don't even know why Gnus decides it should treat this mail as > an Org file. From the sources of Gnus, it appears that it should only do > this if the MIME type was text/x-org. Rainers mail didn't have this MIME > type nor was it a multipart MIME mail that had such a part, yet Gnus > triggered the buffer with "Org" as the major mode, which seems to indicate > that the MIME type must somehow have been inferred. I can prevent that > using orgstruct-mode instead, but as I proposed already there should be a > "safe" variant of org-mode (a derived mode perhaps) that doesn't load any > axtra files and doesn't run any source blocks. Of course, Gnus then should > use this mode (it is only meant for proper fontification anyway, which I > suppose must be possible without firing a whole major mode). What about this patch? The change in Gnus is then trivial (see other patch). [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: org-read-setup-file-conditionnally.patch --] [-- Type: text/x-patch, Size: 3396 bytes --] diff --git a/lisp/org.el b/lisp/org.el index 04a0f20..88f9ea0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1266,6 +1266,26 @@ smart Make point visible, and do insertion/deletion if it is (const :tag "Show invisible part and do the edit" show) (const :tag "Be smart and do the right thing" smart))) +(defcustom org-read-setup-file 'ask + "Should Org read setup files? +A setup file can be specified with the #+SETUPFILE keyword. +When reading someone else Org files, Emacs will try to read +arbitrary read an arbitrary file on your computer. + +The default is to ask users before reading a file. +Setting this option to 'if-interactive will read the setup +file when `org-mode' has been called interactively. +Setting this option to t will always read setup files." + :group 'org-startup + :version "24.4" + :package-version '(Org . "8.0") + :type '(choice + (const :tag "Never read a setup file" nil) + (const :tag "Ask before trying to read a setup file" 'ask) + (const :tag "Read a setup file when `org-mode' is called interactively" + 'if-interactive) + (const :tag "Always try to read a setup file" t))) + (defcustom org-yank-folded-subtrees t "Non-nil means when yanking subtrees, fold them. If the kill is a single subtree, or a sequence of subtrees, i.e. if @@ -4828,8 +4848,10 @@ Support for group tags is controlled by the option (assoc (car e) org-tag-alist)) (push e org-tag-alist)))))))) -(defun org-set-regexps-and-options () - "Precompute regular expressions used in the current buffer." +(defun org-set-regexps-and-options (&optional interactivep) + "Precompute regular expressions used in the current buffer. +If INTERACTIVEP is non-nil, `org-set-regexps-and-options' has +been called from an interactive call to `org-mode'." (when (derived-mode-p 'org-mode) (org-set-local 'org-todo-kwd-alist nil) (org-set-local 'org-todo-key-alist nil) @@ -4912,7 +4934,11 @@ Support for group tags is controlled by the option (setq scripts (read (match-string 2 value))))) ((and (equal key "SETUPFILE") ;; Prevent checking in Gnus messages - (not buffer-read-only)) + (or (and (eq org-read-setup-file 'if-interactive) interactivep) + (and (eq org-read-setup-file 'ask) + (yes-or-no-p (format "Read setup file %s? " value))) + (eq org-read-setup-file t) + (progn (message "Setup file %s not read" value) (sit-for 2)))) (setq setup-contents (org-file-contents (expand-file-name (org-remove-double-quotes value)) @@ -5272,7 +5298,7 @@ The following commands are available: (if (stringp org-ellipsis) org-ellipsis "...")))) (setq buffer-display-table org-display-table)) (org-set-regexps-and-options-for-tags) - (org-set-regexps-and-options) + (org-set-regexps-and-options (org-called-interactively-p 'any)) (when (and org-tag-faces (not org-tags-special-faces-re)) ;; tag faces set outside customize.... force initialization. (org-set-tag-faces 'org-tag-faces org-tag-faces)) @@ -20152,7 +20178,7 @@ This command does many different things, depending on context: "Restart Org-mode, to scan again for special lines. Also updates the keyword regular expressions." (interactive) - (org-mode) + (call-interactively 'org-mode) (message "Org-mode restarted")) (defun org-kill-note-or-show-branches () [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: mm-view.el.patch --] [-- Type: text/x-patch, Size: 524 bytes --] diff --git a/lisp/mm-view.el b/lisp/mm-view.el index ac6170a..690402c 100644 --- a/lisp/mm-view.el +++ b/lisp/mm-view.el @@ -647,7 +647,9 @@ If MODE is not set, try to find mode automatically." (defun mm-display-org-inline (handle) "Show an Org mode text from HANDLE inline." - (mm-display-inline-fontify handle 'org-mode)) + (mm-display-inline-fontify + handle + (lambda () (let (org-read-setup-file) (org-mode))))) (defun mm-display-shell-script-inline (handle) "Show a shell script from HANDLE inline." [-- Attachment #4: Type: text/plain, Size: 14 bytes --] -- Bastien ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 15:54 ` Bastien @ 2013-03-25 16:13 ` Achim Gratz 2013-03-25 16:57 ` Bastien 0 siblings, 1 reply; 21+ messages in thread From: Achim Gratz @ 2013-03-25 16:13 UTC (permalink / raw) To: emacs-orgmode Am 25.03.2013 16:54, schrieb Bastien: > What about this patch? I don't think Gnus should be switching major modes just to get fontification and definitely not with Org. > The change in Gnus is then trivial (see other patch). Again, I'd rather have a derived mode (org-safe-mode, perhaps) that simply switches off anything related to loading other files, changing setups and executing code. This is useful in other situations as well and if one determines that the file is safe the full org-mode can be switched on and the file reloaded if necessary. That makes the patch in Gnus even more trivial (if they really can't use a more sensible method of fontiffication). Regards, -- Achim. (on the road :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 16:13 ` Achim Gratz @ 2013-03-25 16:57 ` Bastien 2013-03-25 17:00 ` Bastien 2013-03-25 17:39 ` Achim Gratz 0 siblings, 2 replies; 21+ messages in thread From: Bastien @ 2013-03-25 16:57 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@Nexgo.DE> writes: > Am 25.03.2013 16:54, schrieb Bastien: >> What about this patch? > > I don't think Gnus should be switching major modes just to get > fontification and definitely not with Org. But it does. >> The change in Gnus is then trivial (see other patch). > > Again, I'd rather have a derived mode (org-safe-mode, perhaps) that simply > switches off anything related to loading other files, changing setups and > executing code. This is useful in other situations as well and if one > determines that the file is safe the full org-mode can be switched on and > the file reloaded if necessary. That makes the patch in Gnus even more > trivial (if they really can't use a more sensible method of > fontiffication). Can you evaluate my patch against the current state of affair? Evaluating it against your ideal fix will obvisouly make it look rudimentary. But I think it's better than the current situation. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 16:57 ` Bastien @ 2013-03-25 17:00 ` Bastien 2013-03-25 17:39 ` Achim Gratz 1 sibling, 0 replies; 21+ messages in thread From: Bastien @ 2013-03-25 17:00 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Bastien <bzg@altern.org> writes: > Evaluating it against your ideal fix will obvisouly make it look > rudimentary. But I think it's better than the current situation. PS: that's not to say that the door is closed for your ideal fix, of course. But I favor existing patches vs. ideal solutions. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 16:57 ` Bastien 2013-03-25 17:00 ` Bastien @ 2013-03-25 17:39 ` Achim Gratz 2013-03-25 18:52 ` Bastien 1 sibling, 1 reply; 21+ messages in thread From: Achim Gratz @ 2013-03-25 17:39 UTC (permalink / raw) To: emacs-orgmode Am 25.03.2013 17:57, schrieb Bastien: > Can you evaluate my patch against the current state of affair? The current state of affairs is this: 1. Gnus is doing something it shouldn't do, even though it may once have been OK or at least not dangerous. 2. Org doesn't have something that can directly be used in Gnus instead. The first one's a bug in Gnus, not Org. The second would be an enhancement to Org that might be useful in other places as well, independently of the issue with Gnus. > Evaluating it against your ideal fix will obvisouly make it look > rudimentary. But I think it's better than the current situation. Both solutions rely on Gnus fixing their bug, so we might just as well wait until Gnus has done it. Depending on which way Gnus does this, we may be talking different implementations of the second point above. But given that Gnus expects to use a major mode with no setup, why not give them this: (define-derived-mode org-safe-mode org-mode "Org-Safe" ;; docstring etc. ) and then conditionalize on the value of mode-name instead of an extra variable that they should bind? This would also help to later add more "safe" functionality without changing things again and again in Org, Gnus or elsewhere. For example, not running source blocks (we already have a way of doing that for export, so it shouldn't be hard to add this). I'm not arguing against your fix, I'd just prefer we'd start with something we just need to extend into a proper safe-mode instead of having to start again from scratch after hot-fixing this unfortunate interaction with Gnus (and I still don't know how Gnus gets there, anyway). Regards, -- Achim. (on the road :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-25 17:39 ` Achim Gratz @ 2013-03-25 18:52 ` Bastien 0 siblings, 0 replies; 21+ messages in thread From: Bastien @ 2013-03-25 18:52 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@Nexgo.DE> writes: > talking different implementations of the second point above. But given > that Gnus expects to use a major mode with no setup, why not give them > this: > > (define-derived-mode org-safe-mode org-mode "Org-Safe" > ;; docstring etc. > ) My feeling is that having a new mode just for preventing users to read setup files is too much. Do you have an idea on how to make org-safe-mode not too heavy? > and then conditionalize on the value of mode-name instead of an extra > variable that they should bind? The extra defcustom is useful IMHO: the problem we have in Gnus, users will have it anytime when opening a file that is not theirs and that contains a #+SETUPFILE (e.g. files in Worg.) Paranoids (or those who don't use #+SETUPFILE) will probably want to be asked when Org tries to read an arbitrary file in their paths. Others will just set this to (setq org-read-setup-file t). So even if we have a org-safe-mode, I don't see how it will spare us with the cost of a new option. > This would also help to later add more > "safe" functionality without changing things again and again in Org, Gnus > or elsewhere. For example, not running source blocks (we already have a > way of doing that for export, so it shouldn't be hard to add this). Yeah, I see where you go, but you know my dreadful tendency to favor actual things against potential ones, and to go the ugly way rather than going the clean one :) Half-joking -- the thing is I really don't know what org-safe-mode would look like, where else it would be useful, and how it spares us the option for paranoid. If you can help on each of these three points, that'd great (no hurry, as I don't know if I'll have time to follow this thread in the next few days.) > I'm not arguing against your fix, I'd just prefer we'd start with something > we just need to extend into a proper safe-mode instead of having to start > again from scratch after hot-fixing this unfortunate interaction with Gnus > (and I still don't know how Gnus gets there, anyway). See my second patch, it gives directions on the Gnus side. -- Bastien ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-21 13:06 :EXPORT_FILE_NAME: in new exporter possible? Rainer Stengele 2013-03-21 15:34 ` Eric Abrahamsen @ 2013-03-22 0:20 ` John Hendy 2013-03-22 7:41 ` Rainer Stengele 1 sibling, 1 reply; 21+ messages in thread From: John Hendy @ 2013-03-22 0:20 UTC (permalink / raw) To: Rainer Stengele; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 948 bytes --] Can you try using just "file" and "file.html" (but without quotes) and see I'd it pops out in your working directory ? Your current path looks like a Windows server share which might be an issue. Even if not, simplifying the path might be one place to start . I just successfully exported using the file path setting in a subtree export this afternoon. (on 8.0-pre) John On Mar 21, 2013 8:06 AM, "Rainer Stengele" <rainer.stengele@online.de> wrote: > Hi, > > Exporting to HTML I cannot get EXPORT_FILE_NAME to work: > > :PROPERTIES: > :VISIBILITY: folded > #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org > #+CATEGORY: ROB > :EXPORT_FILE_NAME: > //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html > :END: > > :EXPORT_FILE_NAME: entry is in one line. > > Is this still possible with the new exporter? > How to deal with spaces in filepaths? > > Thanks, > Rainer > > Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a) > > > [-- Attachment #2: Type: text/html, Size: 1310 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 0:20 ` John Hendy @ 2013-03-22 7:41 ` Rainer Stengele 2013-03-22 14:51 ` John Hendy 2013-03-22 14:58 ` Nicolas Goaziou 0 siblings, 2 replies; 21+ messages in thread From: Rainer Stengele @ 2013-03-22 7:41 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode Am 22.03.2013 01:20, schrieb John Hendy: > Can you try using just "file" and "file.html" (but without quotes) and > see I'd it pops out in your working directory ? > > Your current path looks like a Windows server share which might be an > issue. Even if not, simplifying the path might be one place to start . > > I just successfully exported using the file path setting in a subtree > export this afternoon. (on 8.0-pre) > > John > > On Mar 21, 2013 8:06 AM, "Rainer Stengele" <rainer.stengele@online.de > <mailto:rainer.stengele@online.de>> wrote: > > Hi, > > Exporting to HTML I cannot get EXPORT_FILE_NAME to work: > > :PROPERTIES: > :VISIBILITY: folded > #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org > #+CATEGORY: ROB > :EXPORT_FILE_NAME: > //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html > :END: > > :EXPORT_FILE_NAME: entry is in one line. > > Is this still possible with the new exporter? > How to deal with spaces in filepaths? > > Thanks, > Rainer > > Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a) > > C-c C-e C-s h o does save the file under the correct path. Unfortunately the "open" part for the html file fails: Wrote //max2008/diplan/0PROJEKT/Kunden/ROB/01 Kommunikation/Statusprotokolle/Status-ROB-Electronic-20130321b.html eval: ShellExecute failed: Das System kann die angegebene Datei nicht finden which translated means: The system cannot find the file Another funny issue here is that for the test my exported subtree has the tag :noexport: My setting is: org-export-exclude-tags is a variable defined in `ox.el'. Its value is ("noexport") So the export shouldn't export that subtree shouldn't it? Thanks, Rainer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 7:41 ` Rainer Stengele @ 2013-03-22 14:51 ` John Hendy 2013-03-22 16:04 ` Rainer Stengele 2013-03-22 14:58 ` Nicolas Goaziou 1 sibling, 1 reply; 21+ messages in thread From: John Hendy @ 2013-03-22 14:51 UTC (permalink / raw) To: Rainer Stengele; +Cc: emacs-orgmode On Fri, Mar 22, 2013 at 2:41 AM, Rainer Stengele <rainer.stengele@online.de> wrote: > Am 22.03.2013 01:20, schrieb John Hendy: >> Can you try using just "file" and "file.html" (but without quotes) and >> see I'd it pops out in your working directory ? >> >> Your current path looks like a Windows server share which might be an >> issue. Even if not, simplifying the path might be one place to start . >> >> I just successfully exported using the file path setting in a subtree >> export this afternoon. (on 8.0-pre) >> >> John >> >> On Mar 21, 2013 8:06 AM, "Rainer Stengele" <rainer.stengele@online.de >> <mailto:rainer.stengele@online.de>> wrote: >> >> Hi, >> >> Exporting to HTML I cannot get EXPORT_FILE_NAME to work: >> >> :PROPERTIES: >> :VISIBILITY: folded >> #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org >> #+CATEGORY: ROB >> :EXPORT_FILE_NAME: >> //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html >> :END: >> >> :EXPORT_FILE_NAME: entry is in one line. >> >> Is this still possible with the new exporter? >> How to deal with spaces in filepaths? >> >> Thanks, >> Rainer >> >> Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a) >> >> > C-c C-e C-s h o > does save the file under the correct path. > Unfortunately the "open" part for the html file fails: > > > Wrote //max2008/diplan/0PROJEKT/Kunden/ROB/01 > Kommunikation/Statusprotokolle/Status-ROB-Electronic-20130321b.html > eval: ShellExecute failed: Das System kann die angegebene Datei nicht finden > > which translated means: The system cannot find the file > Again, I'd try just removing all the path and seeing if Emacs can find it then. Mine opens in a buffer with C-c C-e h o, by the way. I probably need to tell Emacs to use a browser somehow. > Another funny issue here is that for the test my exported subtree has > the tag :noexport: > > My setting is: > > org-export-exclude-tags is a variable defined in `ox.el'. > Its value is ("noexport") > > So the export shouldn't export that subtree shouldn't it? Not sure about the noexport tag. Perhaps manually telling it to export a subtree overrides? If you export a higher level subtree or the document, will it omit? > > Thanks, Rainer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 14:51 ` John Hendy @ 2013-03-22 16:04 ` Rainer Stengele 2013-03-22 18:20 ` Nicolas Goaziou 0 siblings, 1 reply; 21+ messages in thread From: Rainer Stengele @ 2013-03-22 16:04 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode Am 22.03.2013 15:51, schrieb John Hendy: > On Fri, Mar 22, 2013 at 2:41 AM, Rainer Stengele > <rainer.stengele@online.de> wrote: >> Am 22.03.2013 01:20, schrieb John Hendy: >>> Can you try using just "file" and "file.html" (but without quotes) and >>> see I'd it pops out in your working directory ? >>> >>> Your current path looks like a Windows server share which might be an >>> issue. Even if not, simplifying the path might be one place to start . >>> >>> I just successfully exported using the file path setting in a subtree >>> export this afternoon. (on 8.0-pre) >>> >>> John >>> >>> On Mar 21, 2013 8:06 AM, "Rainer Stengele" <rainer.stengele@online.de >>> <mailto:rainer.stengele@online.de>> wrote: >>> >>> Hi, >>> >>> Exporting to HTML I cannot get EXPORT_FILE_NAME to work: >>> >>> :PROPERTIES: >>> :VISIBILITY: folded >>> #+SETUPFILE: ~/org/GLOBAL_SETUP_DIPLAN.org >>> #+CATEGORY: ROB >>> :EXPORT_FILE_NAME: >>> //max2008/diplan/0PROJEKT/Kunden/ROB/Status-ROB-Electronic-20130321b.html >>> :END: >>> >>> :EXPORT_FILE_NAME: entry is in one line. >>> >>> Is this still possible with the new exporter? >>> How to deal with spaces in filepaths? >>> >>> Thanks, >>> Rainer >>> >>> Org-mode version 8.0-pre (release_8.0-pre-147-gfbb30a) >>> >>> >> C-c C-e C-s h o >> does save the file under the correct path. >> Unfortunately the "open" part for the html file fails: >> >> >> Wrote //max2008/diplan/0PROJEKT/Kunden/ROB/01 >> Kommunikation/Statusprotokolle/Status-ROB-Electronic-20130321b.html >> eval: ShellExecute failed: Das System kann die angegebene Datei nicht finden >> >> which translated means: The system cannot find the file >> > > Again, I'd try just removing all the path and seeing if Emacs can find > it then. Mine opens in a buffer with C-c C-e h o, by the way. I > probably need to tell Emacs to use a browser somehow. > >> Another funny issue here is that for the test my exported subtree has >> the tag :noexport: >> >> My setting is: >> >> org-export-exclude-tags is a variable defined in `ox.el'. >> Its value is ("noexport") >> >> So the export shouldn't export that subtree shouldn't it? > > Not sure about the noexport tag. Perhaps manually telling it to export > a subtree overrides? > > If you export a higher level subtree or the document, will it omit? > >> >> Thanks, Rainer > > Using :EXPORT_FILE_NAME: x:/folder1/folder2/file.html works. //server/share paths do not work. Secondly, the :EXPORT_FILE_NAME: property is only followed when doing subtree export. It is ignored for buffer export no matter where I put the property definition. Please help. Thanks, Rainer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 16:04 ` Rainer Stengele @ 2013-03-22 18:20 ` Nicolas Goaziou 0 siblings, 0 replies; 21+ messages in thread From: Nicolas Goaziou @ 2013-03-22 18:20 UTC (permalink / raw) To: Rainer Stengele; +Cc: emacs-orgmode Hello, Rainer Stengele <rainer.stengele@online.de> writes: > Secondly, the :EXPORT_FILE_NAME: property is only followed when doing > subtree export. It is ignored for buffer export no matter where I put > the property definition. > > Please help. There is no buffer keyword equivalent to :EXPORT_FILE_NAME: property. Actually, it may confuse a lot publishing process (e.g. resolving links between different files). Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 7:41 ` Rainer Stengele 2013-03-22 14:51 ` John Hendy @ 2013-03-22 14:58 ` Nicolas Goaziou 2013-03-22 15:21 ` Rainer Stengele 1 sibling, 1 reply; 21+ messages in thread From: Nicolas Goaziou @ 2013-03-22 14:58 UTC (permalink / raw) To: Rainer Stengele; +Cc: emacs-orgmode Hello, Rainer Stengele <rainer.stengele@online.de> writes: > Another funny issue here is that for the test my exported subtree has > the tag :noexport: > > My setting is: > > org-export-exclude-tags is a variable defined in `ox.el'. > Its value is ("noexport") > > So the export shouldn't export that subtree shouldn't it? You're explicitly asking for a subtree export. There's no reason for the export framework to think it is smarter than you and prevent you from doing so. When exporting a subtree, the parser only looks at the contents of the top level headline, not at its tags. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: :EXPORT_FILE_NAME: in new exporter possible? 2013-03-22 14:58 ` Nicolas Goaziou @ 2013-03-22 15:21 ` Rainer Stengele 0 siblings, 0 replies; 21+ messages in thread From: Rainer Stengele @ 2013-03-22 15:21 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode Am 22.03.2013 15:58, schrieb Nicolas Goaziou: > Hello, > > Rainer Stengele <rainer.stengele@online.de> writes: > >> Another funny issue here is that for the test my exported subtree has >> the tag :noexport: >> >> My setting is: >> >> org-export-exclude-tags is a variable defined in `ox.el'. >> Its value is ("noexport") >> >> So the export shouldn't export that subtree shouldn't it? > You're explicitly asking for a subtree export. There's no reason for the > export framework to think it is smarter than you and prevent you from > doing so. > > When exporting a subtree, the parser only looks at the contents of the > top level headline, not at its tags. > > > Regards, > Makes sense, thanks. Rainer ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-03-25 18:52 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-21 13:06 :EXPORT_FILE_NAME: in new exporter possible? Rainer Stengele 2013-03-21 15:34 ` Eric Abrahamsen 2013-03-21 23:15 ` Andreas Leha 2013-03-21 23:23 ` Bastien 2013-03-25 5:45 ` Bastien 2013-03-25 10:09 ` Achim Gratz 2013-03-25 14:57 ` Bastien 2013-03-25 15:09 ` Achim Gratz 2013-03-25 15:54 ` Bastien 2013-03-25 16:13 ` Achim Gratz 2013-03-25 16:57 ` Bastien 2013-03-25 17:00 ` Bastien 2013-03-25 17:39 ` Achim Gratz 2013-03-25 18:52 ` Bastien 2013-03-22 0:20 ` John Hendy 2013-03-22 7:41 ` Rainer Stengele 2013-03-22 14:51 ` John Hendy 2013-03-22 16:04 ` Rainer Stengele 2013-03-22 18:20 ` Nicolas Goaziou 2013-03-22 14:58 ` Nicolas Goaziou 2013-03-22 15:21 ` Rainer Stengele
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).