Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-28 Thread Bastien
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: I tend to think it's more a developer information. By looking at the manual, there's no confusion possible for a user. A footnote would not hurt, if only as a way to answer future questions? Maybe it should go in

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-27 Thread Bastien
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Applied on master, since it introduces a syntax change. Tell me if you want it on maint anyway (or just cherry-pick it yourself). 2 cents: it's better on maint, since people are more likely to read change logs for 8.1 rather than for

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-27 Thread Bastien
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Basically, #+HTML_INCLUDE_STYLE: nil becomes #+OPTIONS: html-style:nil Is this the rule for all #+... options ? What about #+LaTeX: options ? See for example ox-rss.el: should I keep using #+RSS_EXTENSION or use a new item for

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-27 Thread Nicolas Goaziou
Hello, Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: Basically, #+HTML_INCLUDE_STYLE: nil becomes #+OPTIONS: html-style:nil Is this the rule for all #+... options ? What about #+LaTeX: options ? See for example ox-rss.el: should I keep using

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-27 Thread Bastien
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Basically, #+keyword: is for strings, #+OPTIONS: use `read' on the values, so it should be used for every other type. Thanks for the explanation, it makes sense. Let's make it explicit somewhere in the manual, so that users have a clear

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-27 Thread Nicolas Goaziou
Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: Basically, #+keyword: is for strings, #+OPTIONS: use `read' on the values, so it should be used for every other type. Thanks for the explanation, it makes sense. Let's make it explicit somewhere in the manual, so

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-24 Thread Achim Gratz
Carsten Dominik writes: Indeed, too much punctuation. How about something along these lines? #+OPTIONS: :enable *e: :disable ^| I agree with this proposal. The property-lit like style should use longer names and avoid the short ones. And we should also keep supporting the old compact

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-23 Thread Carsten Dominik
On 21.6.2013, at 22:41, Achim Gratz strom...@nexgo.de wrote: Nicolas Goaziou writes: Here is a preliminary patch. It doesn't update org.texi yet. I find the new syntax weird for one character keys: #+OPTIONS: :* t :e t :: t :f t :- t :^ t :| t Maybe we should expand them in order to

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Sebastien Vauban
Hello Nicolas, Nicolas Goaziou wrote: Any objection to applying the following patch to master? Not at all. Basically, #+HTML_INCLUDE_STYLE: nil becomes #+OPTIONS: html-style:nil and #+HTML_HTML5_FANCY: t becomes #+OPTIONS: html5-fancy:t Though, I'd also even prefer the

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Eric Abrahamsen
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Any objection to applying the following patch to master? Basically, #+HTML_INCLUDE_STYLE: nil becomes #+OPTIONS: html-style:nil and #+HTML_HTML5_FANCY: t becomes #+OPTIONS: html5-fancy:t Regards, Looks good! +1 for

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Carsten Dominik
Hi Nicolas, This is a good change - I am also for merging it. - Carsten On Jun 20, 2013, at 9:20 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Any objection to applying the following patch to master? Basically, #+HTML_INCLUDE_STYLE: nil becomes #+OPTIONS:

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Nicolas Goaziou
Hello, Carsten Dominik carsten.domi...@gmail.com writes: This is a good change - I am also for merging it. Applied on master, since it introduces a syntax change. Tell me if you want it on maint anyway (or just cherry-pick it yourself). As for the move from #+OPTIONS: key:value to #+OPTIONS:

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Rick Frankel
On 2013-06-21 13:28, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: This is a good change - I am also for merging it. Applied on master, since it introduces a syntax change. Tell me if you want it on maint anyway (or just cherry-pick it yourself). As for the

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Achim Gratz
Nicolas Goaziou writes: As for the move from #+OPTIONS: key:value to #+OPTIONS: :key value, I can provide a patch, but it will break export in many documents. A workaround would be to support both versions and document only the newest one. I didn't know supporting both styles was in the

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Nicolas Goaziou
Hello, Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: As for the move from #+OPTIONS: key:value to #+OPTIONS: :key value, I can provide a patch, but it will break export in many documents. A workaround would be to support both versions and document only the newest one. I

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Samuel Wales
On 6/21/13, Nicolas Goaziou n.goaz...@gmail.com wrote: #+OPTIONS: :* t :e t :: t :f t :- t :^ t :| t Maybe we should expand them in order to make them less cryptic. To me, that would be ideal. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress.

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Thorsten Jolitz
Nicolas Goaziou n.goaz...@gmail.com writes: I find the new syntax weird for one character keys: #+OPTIONS: :* t :e t :: t :f t :- t :^ t :| t Maybe we should expand them in order to make them less cryptic. +1 for making this #+OPTIONS lines human readable ... -- cheers, Thorsten

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Eric Schulte
As for the move from #+OPTIONS: key:value to #+OPTIONS: :key value, I can provide a patch, but it will break export in many documents. A workaround would be to support both versions and document only the newest one. I didn't know supporting both styles was in the cards. If it isn't overly

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-21 Thread Achim Gratz
Nicolas Goaziou writes: Here is a preliminary patch. It doesn't update org.texi yet. I find the new syntax weird for one character keys: #+OPTIONS: :* t :e t :: t :f t :- t :^ t :| t Maybe we should expand them in order to make them less cryptic. Indeed, too much punctuation. How about

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-20 Thread Nicolas Goaziou
Update. I forgot to change #+HTML_INCLUDE_SCRIPTS: t into #+OPTIONS: html-scripts:t for the same reason. -- Nicolas Goaziou From f99c5a071e185301bbef576c042afa07f4c76488 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou n.goaz...@gmail.com Date: Thu, 20 Jun 2013 21:14:57 +0200 Subject:

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-20 Thread Samuel Wales
It seems reasonable to me. I also think it is good that you are using hyphen-separated human-readable identifiers like html-style instead of single-character identifiers. I wonder if it would be worth the backward incompatibility to make a:b syntax become :a b syntax to be consistent with Babel

Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items

2013-06-20 Thread Achim Gratz
Samuel Wales writes: I wonder if it would be worth the backward incompatibility to make a:b syntax become :a b syntax to be consistent with Babel and backends, but presume we've already decided not to do so. Yes, I do think that this sort of consistency would be welcome. Regards, Achim. --