Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Bastien b...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 25.03.2013 06:45, schrieb Bastien: Bastien b...@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 :-)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@nexgo.de writes: Am 25.03.2013 06:45, schrieb Bastien: Bastien b...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
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 :-)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@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). 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 @@ smartMake 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 () 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. -- Bastien
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
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 :-)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Bastien b...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
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 :-)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
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.steng...@online.de mailto:rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
On Fri, Mar 22, 2013 at 2:41 AM, Rainer Stengele rainer.steng...@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.steng...@online.de mailto:rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Hello, Rainer Stengele rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 22.03.2013 15:58, schrieb Nicolas Goaziou: Hello, Rainer Stengele rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 22.03.2013 15:51, schrieb John Hendy: On Fri, Mar 22, 2013 at 2:41 AM, Rainer Stengele rainer.steng...@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.steng...@online.de mailto:rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Hello, Rainer Stengele rainer.steng...@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
[O] :EXPORT_FILE_NAME: in new exporter possible?
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)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Rainer Stengele rainer.steng...@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??
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Eric Abrahamsen e...@ericabrahamsen.net writes: Rainer Stengele rainer.steng...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Hi Andreas and Eric, Andreas Leha andreas.l...@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
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
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.steng...@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)
