emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Thomas S. Dye" <tsd@tsdye.com>
To: Dan Davison <davison@stats.ox.ac.uk>
Cc: "emacs-orgmode list" <emacs-orgmode@gnu.org>,
	"Sébastien Vauban"
	<public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@plane.gmane.org>
Subject: Re: How to get pretty printed source code in PDFLaTeX
Date: Tue, 10 Aug 2010 09:08:30 -1000	[thread overview]
Message-ID: <B8B9A6A1-6867-473F-BAF0-4A6CF51CBAD0@tsdye.com> (raw)
In-Reply-To: <871va6xtal.fsf@stats.ox.ac.uk>


[-- Attachment #1.1: Type: text/plain, Size: 9454 bytes --]

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



[-- Attachment #1.2: Type: text/html, Size: 31686 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

      reply	other threads:[~2010-08-10 19:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 17:00 Change resolution of LaTeX formulas in HTML output? amscopub-mail
2010-08-04 22:32 ` Bastien
2010-08-05 19:11   ` Dan Davison
2010-08-06  9:12     ` Bastien
2010-08-06 10:46   ` Carsten Dominik
2010-08-06 17:21     ` Bastien
2010-08-05 19:14 ` Dan Davison
2010-08-05 20:34   ` Sebastian Rose
2010-08-05 21:36     ` Dan Davison
2010-08-05 22:14       ` Sebastian Rose
2010-08-06  7:59         ` How to get pretty printed source code in PDFLaTeX Sébastien Vauban
2010-08-06 13:39           ` Dan Davison
2010-08-09 20:30             ` Sébastien Vauban
2010-08-09 22:29               ` Dan Davison
2010-08-10 16:38                 ` Thomas S. Dye
2010-08-10 17:37                   ` Dan Davison
2010-08-10 19:08                     ` Thomas S. Dye [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B8B9A6A1-6867-473F-BAF0-4A6CF51CBAD0@tsdye.com \
    --to=tsd@tsdye.com \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@plane.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).