:EXPORT_FILE_NAME: in new exporter possible?

:EXPORT_FILE_NAME: in new exporter possible?

[Rainer Stengele]

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: :EXPORT_FILE_NAME: in new exporter possible?

[Eric Abrahamsen]

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??

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Andreas Leha]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[John Hendy]

[-- 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 --]

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Rainer Stengele]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[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,

-- 
Nicolas Goaziou

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Rainer Stengele]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Rainer Stengele]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Nicolas Goaziou]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[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.

-- 
 Bastien

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Achim Gratz]

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 :-)

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Achim Gratz]

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: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

[-- 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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Achim Gratz]

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: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

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

Re: :EXPORT_FILE_NAME: in new exporter possible?

[Achim Gratz]

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: :EXPORT_FILE_NAME: in new exporter possible?

[Bastien]

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