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
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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
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.
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
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
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
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,
--
Nicolas Goaziou
From dff24cc4ec2c3466526802042fd89dce0d99f633 Mon Sep
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:
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
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.
--
23 matches
Mail list logo
