Hi Matt,
Matt Lundin wrote:
> Sébastien Vauban writes:
>>
>> When discussing exporters and features, two things that come up to my mind
>> as missing as a "general Org feature":
>>
>> - bibliography :: works for LaTeX[1], not for HTML export.
>
> Have you tried the contributed module org-exp-bibte
Sébastien Vauban
writes:
>
> When discussing exporters and features, two things that come up to my
> mind as missing as a "general Org feature":
>
> - bibliography :: works for LaTeX[1], not for HTML export.
Have you tried the contributed module org-exp-bibtex.el? It is not a
self-contained org-m
On Wed, Apr 6, 2011 at 00:57, Eric S Fraga wrote:
> Aankhen writes:
>
> [...]
>
>> Thank you for the clarifications. I’m going to talk a bit more about
>> HTML as that’s where I have the most experience. I am in agreement
>> with you when you say that builtin support for acronyms would be
>> us
Aankhen writes:
[...]
> Thank you for the clarifications. I’m going to talk a bit more about
> HTML as that’s where I have the most experience. I am in agreement
> with you when you say that builtin support for acronyms would be
> useful (although I feel it would be good to generalize it to
>
Hi Sébastien,
2011/4/5 Sébastien Vauban :
> Aankhen wrote:
>> [snip]
>> Acronyms are natively supported in HTML. That is all.
>
> Thanks for reporting this. Wasn't aware of it. Though, that does not alter the
> need (at least, what I consider so) for acronyms handling in/from Org.
>
> Let's clarif
Hi Aankhen,
Aankhen wrote:
> 2011/4/4 Sébastien Vauban :
>> [snip]
>>
>> When discussing exporters and features, two things that come up to my mind
>> as missing as a "general Org feature":
>>
>> - bibliography :: works for LaTeX[1], not for HTML export.
>> - acronyms :: idem.
>>
>> Maybe those sh
Hullo,
2011/4/4 Sébastien Vauban :
> [snip]
>
> When discussing exporters and features, two things that come up to my mind as
> missing as a "general Org feature":
>
> - bibliography :: works for LaTeX[1], not for HTML export.
> - acronyms :: idem.
>
> Maybe those should be made available for gene
Matt Lundin wrote:
> Hi Jambunathan,
>
> Jambunathan K writes:
>
> > Matt Lundin writes:
> >
> >> I agree that the org-exporter currently does its job very well. The
> >> astounding utility of org-mode is ample proof of the value of releasing
> >> early; even if the exporter is not as elegant
Sébastien Vauban wrote:
> Hi Nick and al.,
>
> Nick Dokos wrote:
> >> This will at least help with the first difficulty -- and motivate all
> >> people working on the exporters to address the second one. The third one
> >> can be turned into a *chance*: that of having several people working in t
Hi Jambunathan,
Jambunathan K writes:
> Matt Lundin writes:
>
>> I agree that the org-exporter currently does its job very well. The
>> astounding utility of org-mode is ample proof of the value of releasing
>> early; even if the exporter is not as elegant as a modern compiler, it
>> works. :)
Hi Nick and al.,
Nick Dokos wrote:
>> This will at least help with the first difficulty -- and motivate all
>> people working on the exporters to address the second one. The third one
>> can be turned into a *chance*: that of having several people working in the
>> same direction.
>
> Excellent pl
Matt Lundin writes:
> Eric S Fraga writes:
>
>> Jambunathan K writes:
>>
>> [...]
>>
>>> I think one of the reasons Org is so popular it is that it is a
>>> common-man's swiss army knife and not a elitist samurai sword.
>>
>> And I think this is a very important analogy. Org does a good job fo
Eric S Fraga writes:
> Jambunathan K writes:
>
> [...]
>
>> I think one of the reasons Org is so popular it is that it is a
>> common-man's swiss army knife and not a elitist samurai sword.
>
> And I think this is a very important analogy. Org does a good job for
> many (very different) tasks.
Nicolas writes:
> I have been thinking about exporters for a while now, and I'd like to
> share my point of view. Be warned, I will be a bit verbose.
[...]
+1
A remark about backwards compatibility:
I personally don't have a huge investment in documents that I export,
but I guess that backwards
Jambunathan K writes:
[...]
> I think one of the reasons Org is so popular it is that it is a
> common-man's swiss army knife and not a elitist samurai sword.
And I think this is a very important analogy. Org does a good job for
many (very different) tasks. The price is that it does not neces
> I'll show two examples to illustrate my point: lists and tables. Taken
> from a docstring,
>
> 1. first item
>+ sub-item one
>+ [X] sub-item two
>more text in first item
> 2. [@3] last item
>
> will be parsed as:
>
> (ordered (nil \"first item\"
> (unordered (nil "sub-
Jambunathan K wrote:
> Do look at my new html exporter. I have been very conservative in making
> the changes.
>
Well, Nicolas's proposal is more radical, but there is no inherent
backward compatibility disadvantage to it that I can see.
> Some observations from my side ...
>
> > It isn't doc
Backward compatibility is a real issue.
The real challenge is how to move forward while also not breaking
anything that the users have come to rely on.
> Thus, Org documentation should provide an exhaustive list of
> environments and objects it offers with their associated format during
> expor
One more thing to the list.
Use htmlfontify instead of htmlize. Former is part of standard Emacs
while the latter is not.
Jambunathan K.
Hello,
Bastien writes:
> 2. exporters use various methods to export the file (e.g. the HTML
>exporter goes line by line, the LaTeX exporter parses the file and
>render each section);
>
>*Example*: users often ask why the LaTeX exporter cannot export a
>headline of level 3 right a
Hi Jambunathan,
Jambunathan K writes:
> I pulled the master branch with an intention to "re-baseline" my branch
> and I saw some 37 lines were changed since I "branched" out my odt
> branch. My heart just sinked.
>
> A request from my side. Would it be possible to delay adding of new
> capabilit
This is slightly out of thread.
I pulled the master branch with an intention to "re-baseline" my branch
and I saw some 37 lines were changed since I "branched" out my odt
branch. My heart just sinked.
A request from my side. Would it be possible to delay adding of new
capabilities and features t
On Thu, 24 Mar 2011 15:25:02 -0400
Nick Dokos wrote:
> > PS: Also note that I couldn't be as available as I wanted the 10
> > last days due to personal problems, but things look better now.
> >
>
> I think I'm speaking for all of us: Nothing here is so urgent that it
> cannot wait for a few d
Bastien wrote:
> Here is a list of difficulties:
>
> 1. the syntax of the backends vary, and this means that all Org options
>are not meaningful in all target formats;
>
>*Example*: #+XSLT is only meaninful for the Docbook export. The
>variable `org-export-html-postamble' is only m
Bastien writes:
> I fully agree with Nick and Thomas (and others who also agreed): Org's
> export facilities need some real love and new export features need to be
> introduced as complete and as consistent accross exporters as possible.
>
> I hope we'll make progress on this for 7.6.
That would
Dear all,
I applied the patches too hastily, disregarding some inconsistency they
could introduce between exporters -- sorry for that.
I fully agree with Nick and Thomas (and others who also agreed): Org's
export facilities need some real love and new export features need to be
introduced as comp
> OTOH, it is important to document such limitations, so that innocent
> users don't end up spending hours trying to do something that cannot
> be done.
Point taken.
>
> Nick
>
>
--
Jambunathan K wrote:
>
> >> For example, I don't know if the docbook backend explicitly
> >> writes section numbers in, or if the sectioning is left to the
> >> stylesheet. If the latter, can I mark sections as ones that
> >> should be numbered and ones that shouldn't?
> >>
> >
> > And I'm sur
>> For example, I don't know if the docbook backend explicitly
>> writes section numbers in, or if the sectioning is left to the
>> stylesheet. If the latter, can I mark sections as ones that
>> should be numbered and ones that shouldn't?
>>
>
> And I'm sure Jambunathan will take care of the odt
Nick Dokos writes:
> Suvayu Ali wrote:
>
>> This works too, but Lawrence's patch makes it much easier and
>> probably works for other export formats too. Thanks a lot. :)
>>
>
> No doubt Lawrence's patch can be extended to work for other exports, but
> it's not there yet: each exporter would ne
Lawrence Mitchell wrote:
> > patches makes the behavior of different exporters potentially
> > inconsistent with each other.
>
> You can drop the potentially here!
>
Well, some people might not use the feature...
> > IMO, it would be better to accumulate the patches and once all of the
> > ex
On Mar 23, 2011, at 5:02 AM, Nick Dokos wrote:
Bastien wrote:
Hi Nick,
Nick Dokos writes:
Suvayu Ali wrote:
This works too, but Lawrence's patch makes it much easier and
probably works for other export formats too. Thanks a lot. :)
No doubt Lawrence's patch can be extended to work f
Nick Dokos wrote:
> Bastien wrote:
>> Hi Nick,
>> Nick Dokos writes:
>>> Suvayu Ali wrote:
This works too, but Lawrence's patch makes it much easier and
probably works for other export formats too. Thanks a lot. :)
>>> No doubt Lawrence's patch can be extended to work for other ex
Bastien wrote:
> Hi Nick,
>
> Nick Dokos writes:
>
> > Suvayu Ali wrote:
> >
> >> This works too, but Lawrence's patch makes it much easier and
> >> probably works for other export formats too. Thanks a lot. :)
> >
> > No doubt Lawrence's patch can be extended to work for other exports, but
>
Hi Nick,
Nick Dokos writes:
> Suvayu Ali wrote:
>
>> This works too, but Lawrence's patch makes it much easier and
>> probably works for other export formats too. Thanks a lot. :)
>
> No doubt Lawrence's patch can be extended to work for other exports, but
> it's not there yet: each exporter wo
Suvayu Ali wrote:
> This works too, but Lawrence's patch makes it much easier and
> probably works for other export formats too. Thanks a lot. :)
>
No doubt Lawrence's patch can be extended to work for other exports, but
it's not there yet: each exporter would need a change similar to the one
t
On Tue, 22 Mar 2011 10:35:10 -0400
Nick Dokos wrote:
> Suvayu Ali wrote:
>
> > Hi S=C3=A9bastien,
> >
> > On Tue, 22 Mar 2011 13:20:29 +0100
> > S=C3=A9bastien Vauban wrote:
> > > >
> > > > I was wondering whether there is some way to export the
> > > > attached org file to latex such that he
Suvayu Ali wrote:
> Hi S=C3=A9bastien,
>
> On Tue, 22 Mar 2011 13:20:29 +0100
> S=C3=A9bastien Vauban wrote:
> > >
> > > I was wondering whether there is some way to export the attached org
> > > file to latex such that headlines beyond level 2 (3 and onwards) can
> > > be exported as unnumbere
Hi Suvayu,
Suvayu Ali wrote:
> On Tue, 22 Mar 2011 13:20:29 +0100
> Sébastien Vauban wrote:
>> >
>> > I was wondering whether there is some way to export the attached org file
>> > to latex such that headlines beyond level 2 (3 and onwards) can be
>> > exported as unnumbered subsections or subsub
Hi Sébastien,
On Tue, 22 Mar 2011 13:20:29 +0100
Sébastien Vauban wrote:
> >
> > I was wondering whether there is some way to export the attached org
> > file to latex such that headlines beyond level 2 (3 and onwards) can
> > be exported as unnumbered subsections or subsubsections like this,
> >
Hi Suvayu,
Suvayu Ali wrote:
> Hi Orgers,
>
> I was wondering whether there is some way to export the attached org
> file to latex such that headlines beyond level 2 (3 and onwards) can
> be exported as unnumbered subsections or subsubsections like this,
> \subsection*{}, instead of enclosing them
41 matches
Mail list logo
