From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas S. Dye" Subject: Re: How to get pretty printed source code in PDFLaTeX Date: Tue, 10 Aug 2010 09:08:30 -1000 Message-ID: References: <308653.38337.qm@web65503.mail.ac4.yahoo.com> <871vacswh4.fsf@stats.ox.ac.uk> <87aap0ol2n.fsf@gmx.de> <877hk4rbco.fsf@stats.ox.ac.uk> <8762zoogf5.fsf@gmx.de> <87k4o4893x.fsf_-_@mundaneum.com> <87vd7nn9lt.fsf@stats.ox.ac.uk> <87aaovcyvc.fsf@mundaneum.com> <87hbj31kup.fsf@stats.ox.ac.uk> <1DF1CFB0-2986-4A04-A4D2-AF2279F0A54E@tsdye.com> <871va6xtal.fsf@stats.ox.ac.uk> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: multipart/mixed; boundary="===============1798695485==" Return-path: Received: from [140.186.70.92] (port=60748 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OiuBi-0002qb-O7 for emacs-orgmode@gnu.org; Tue, 10 Aug 2010 15:08:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OiuBg-00032u-Fh for emacs-orgmode@gnu.org; Tue, 10 Aug 2010 15:08:38 -0400 Received: from oproxy1-pub.bluehost.com ([66.147.249.253]:57089) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OiuBf-00032P-TY for emacs-orgmode@gnu.org; Tue, 10 Aug 2010 15:08:36 -0400 In-Reply-To: <871va6xtal.fsf@stats.ox.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dan Davison Cc: emacs-orgmode list , =?ISO-8859-1?Q?S=E9bastien_Vauban?= --===============1798695485== Content-Type: multipart/alternative; boundary=Apple-Mail-3-364916396 --Apple-Mail-3-364916396 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Dan, Yes, sorry, "gory" was off the mark. I think your approach with minted, etc. to gain out of the box =20 functionality like this is very useful. I'm following the =20 conversation with interest because I am planning a publication that =20 includes some code snippets. My reservation comes from a decade of =20 creating and maintaining LaTeX code. When I violate the separation of =20= semantics and implementation in a .tex file, I come to regret it =20 sooner or later. Old .tex files with non-semantic markup typically =20 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 =20= issue if the .org source is always the master document--the .tex file =20= can later be regenerated to meet the requirements of a new style. I =20 guess the implementation choice is dependent on the expected use life =20= of the LaTeX code generated by org-mode. If the LaTeX code is just an =20= intermediate step in a single process, then it is probably best to =20 have org-mode specify all the LaTeX implementation details. If the =20 LaTeX code is the goal, and will have its own use life independent of =20= the org-mode file that created it, then the implementation details in =20= 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" 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 =20 > 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 =20 >> 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=E9bastien Vauban >> +FvcfC7Uqw@public.gmane.org> >>> writes: >>> >>>> Hi Dan, >>>> >>>> Dan Davison wrote: >>>>> S=E9bastien Vauban >>>>> = >>>>> writes: >>>>>> Sebastian Rose wrote: >>>>>>> Dan Davison >>>>>>> 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 =20 >>> 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 =20 >>> 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, =20= >>> 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 =20 >>> 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%40mund= aneum.com >>>> ][Email from S=E9bastien 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. =20 >>>> 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. >>> Emacs-orgmode@gnu.org >>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Please use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> 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 --Apple-Mail-3-364916396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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" <tsd@tsdye.com> = 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=E9bastien Vauban = <wxhgmqzgwmuf-geNee64TY+gS
+FvcfC7Uqw@public.gmane.org>
writes:

Hi = Dan,

Dan = Davison wrote:
S=E9bastien = Vauban
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/= +iSw@public.gmane.orgrg
writes:
Sebastian Rose = wrote:
Dan Davison <davison-+7= o2aNKnwVPQzY9nttDBhA@public.gmane.org>
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
<= /blockquote>
yet.
=

If I = understand you right, here's such an example you're = after:

* Much = better = code
<= blockquote type=3D"cite">

[...]

I've = put the PDF (for easy access) onto my Web = site:
=

http://www.mygoogl= est.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%3D87lj8g= p4rr.fsf%40mundaneum.com
][Email from S=E9bastien 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.
Emacs-orgmode@gnu.org
http://lists.= gnu.org/mailman/listinfo/emacs-orgmode


_______________________________________________
Emacs-orgmode mailing = list
Please use `Reply All' to = send replies to the list.
Emacs-orgmode@gnu.org
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

 =

= --Apple-Mail-3-364916396-- --===============1798695485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --===============1798695485==--