| Hi Dan,
Yes, sorry, "gory" was off the mark.
I think your approach with minted, etc. to gain out of the box functionality like this is very useful. I'm following the conversation with interest because I am planning a publication that includes some code snippets. My reservation comes from a decade of creating and maintaining LaTeX code. When I violate the separation of semantics and implementation in a .tex file, I come to regret it sooner or later. Old .tex files with non-semantic markup typically need editing before they can be used again with a different style file.
Thinking through this a bit more, I can see that this is not really an issue if the .org source is always the master document--the .tex file can later be regenerated to meet the requirements of a new style. I guess the implementation choice is dependent on the expected use life of the LaTeX code generated by org-mode. If the LaTeX code is just an intermediate step in a single process, then it is probably best to have org-mode specify all the LaTeX implementation details. If the LaTeX code is the goal, and will have its own use life independent of the org-mode file that created it, then the implementation details in the .tex file will eventually get in the way.
All the best, Tom
On Aug 10, 2010, at 7:37 AM, Dan Davison wrote: "Thomas S. Dye" < address@hidden> writes: Hi Dan,
One of the design goals of LaTeX is to use semantic markup in the
source and to keep details of representation separate, typically in a
style or class file that is used to render the semantic markup. From
this perspective, the cleanest implementation would be to create a
LaTeX style or class file for use with org-mode, where the gory
details of listings vs. minted, etc.
Yes, although may I repeat that in the case of minted there are no gory details. The patch I submitted already works to give org users out-of-the-box pretty fontified code with nothing more required than installation of pygments and putting minted.sty in a suitable place. Pending the work on listings that you and Seb and I are proposing, the minted patch is therefore a useful advance for org mode. It can always be removed later if it becomes clear that it is completely redundant in view of newly improved org/listings support. But yes, absolutely, what you say is definitely helpful for those planning work on improving listings support. Dan could be worked out. This would
leave org-mode to do what it does very well, which is to identify and
mark the relevant semantic units, and would at the same time simplify
org-mode configuration.
For the user, this would require the org-mode.sty or org-mode.cls file
be placed somewhere LaTeX could find it and creating an export target
for it in .emacs.
This might not qualify as "out of the box" but the looser coupling
between org-mode and LaTeX is likely to be a plus in the long run.
All the best,
Tom
On Aug 9, 2010, at 12:29 PM, Dan Davison wrote:
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS
address@hidden>
writes:
Hi Dan,
Dan Davison wrote:
Sébastien Vauban
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/address@hidden
writes:
Sebastian Rose wrote:
Dan Davison <address@hidden>
writes:
Can you point me to an example that shows how to make source
code in
latex look (almost) as nice as html?
That is supposed to work with the `listings' package. I havent
tried that
yet.
If I understand you right, here's such an example you're after:
* Much better code
[...]
I've put the PDF (for easy access) onto my Web site:
http://www.mygooglest.com/sva/ECM-Listings.pdf
Wow, that's really nice. Thanks for sharing that.
I really thought that you used such a thing for a long time, having
done so
much for Org-Babel. Maybe you were more interested by the execution
stuff,
rather than its printing? For me, the opposite: I was much
interested by the
printing, now by accessing all the power of Babel.
You're probably right that I should have looked into it. But seeing as
the HTML export of code is so nice and requred no configuration, I
never
got round to it. Although I did write my Ph.D. in latex, and I am
enjoying using the listings package for formatting pseudocode in a
paper
which I'm supposed to be writing, I do need to become better friends
with latex, it's true.
I think we should aim to get to a point where org-mode can produce
such
nicely formatted source code out-of-the-box.
I share your point. I'm willing to participate, or even begin, such
a page on
Worg, with the above info.
Maybe we could even make latex inherit the colours and fonts that
emacs is
currently using for source code mark up?
For sure, that'd be nice. You mean the way htmlize works, and keeps
my colors,
right?
Dunno what it implies for Org-LaTeX... Generating your own class
customization,
and having it loaded by default (in the list of LaTeX packages)?
Usage of listings is controlled by the variable
`org-export-latex-listings', so the simplest start would be: if that
is
non-nil then code like yours could be inserted into the latex output.
I was going to suggest doing this with listings but then came
across minted,
and I wonder whether that's even more suitable? (See the other
post I just
made.)
Never heard about it before, while I'm trying to follow info about
TeX as
well.
I'm very impressed by the quality and reaction time of
french.computers.text.tex. So, I decided to ask them what they
thought about
Listings vs Minted.
,----
| "sur un post de Dan Davison parlant d'un nouveau paquet qui
| serait mieux que Listings."
`----
Hey, I never said that! :)
I said it might be better *for export of code from org-mode*. But
seriously, no problem, in addition to my character assassination, from
what I could make out they made lots of good points. Although I will
watch out now if I come across any francophones who look like they
might
be tex enthusiasts (wouldn't one always...)
What I meant is that seeing as org-users who set
`org-export-latex-listings' get black and white code with ugly fonts
by
default, there are two improvement options for us:
1. we work on incorporating nice listings configuration into org
mode so
that Org users get nice colours and fonts by default
2. we add an option to allow Org users to use the minted package,
which
gives them nice colours and fonts automatically.
(2) was easy and so I did it straight away. And (1) is still something
we want to do, not least because listings is in standard latex
distributions and doesn't have an extra python requirement. Assuming
that minted/pygments are stable software that will be around for a
while, I would vote for both options ultimately being available in
org-mode.
See on
[[http://groups.google.com/groups/search?as_umsgid%3D87lj8gp4rr.fsf%40mundaneum.com
][Email from Sébastien Vauban: Listings vs Minted]]
What's interesting is that 2 brilliant people of that list
responded on that.
I could try to translate the whole, but there already is a lot. Just
highlighting that they don't trust that much all the facts that
have been used
against Listings (and prove what they say): about Utf-8, or the
number of
languages, etc.
They agree with one inconvenient of Listings: the fact that, by
default, it
uses bad settings (like no color, and proportional font).
On the other hand, they don't like implying the use of an external
language to
LaTeX. Impacts on shell-escape.
The discussion is going on. I'll keep you posted.
For sure, the objective of getting better out-of-the-box is a goal
we can
reach.
Excellent, I think that will be a good addition to org-mode.
Dan
Best regards,
Seb
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Thomas S. Dye, Ph.D. T. S. Dye & Colleagues, Archaeologists, Inc. Phone: (808) 529-0866 Fax: (808) 529-0884 http://www.tsdye.com
|