emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] How to get to work non-interactive publishing?


From: Eric Schulte
Subject: Re: [O] How to get to work non-interactive publishing?
Date: Mon, 21 May 2012 14:10:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

"Mikhail Titov" <address@hidden> writes:

>> -----Original Message-----
>> From: address@hidden [mailto:emacs-orgmode-
>> address@hidden On Behalf Of Eric Schulte
>> Sent: Saturday, May 19, 2012 5:39 PM
>> To: Mikhail Titov
>> Cc: address@hidden
>> Subject: Re: [O] How to get to work non-interactive publishing?
>> 
>> >>> I can publish project if I don’t use –-batch . So the following works
>> >>> just fine: emacs -nw --eval '(org-publish-project "myproj")'
>> >>>
>> >>> However nothing happens if I try emacs --batch --eval '(org-publish-
>> project "myproj")'
>> ...
>> >> Using batch mode shouldn't be causing any problems with the export
>> >> process, is it possible that something in your personal config is not
>> >> compatible with batch-mode
>> ...
>> > I really did not want to create a separate init file as I was quite
>> > happy with existing dot emacs. You are right. Something was in the way.
>> > After I created a separate file that loads only necessary stuff, it
>> > published fine.
>> >
>> 
>> Happy it works, if you find the offending element of your persona
>> configuration you could remove it and continue to use your personal
>> config for batch publishing.
>> >
>> > So weird emacs did not give any error before that something is not
>> > quite right. Is there an option for emacs so that some module can say
>> > it can't work in a batch mode?
>> >
>> 
>> I don't believe that there is an automated way to raise such warnings.
>> You could do a binary search through your init.
>
> Part of my question was if there is an easy way to find it other than by 
> dichotomy? I guess not :-)
>
>> > I mean what is the point to make a separate init file other than
>> > speed?
>> >
>> 
>> Your main init file is used to customize Emacs for interactive editing,
>> many (if not most) of these settings won't apply to batch evaluation.
>> 
>> By separating your personal customization from the project init file
>> used for publishing it becomes possible to distribute your project with
>> the publication init file without sharing your personal configuration.
>
> That makes it clear.
>
> Another weird issue I experience when batch-publishing is that even
> with a separate init file, I get different "htmlization" of babel
> blocks. I mean if I load
>
> emacs -nw -Q -l myinit.el project_part.org
>
> and publish that with C-c C-e P , then I get nicely colored babel block in 
> HTML starting like
>
> <pre class="src src-R">  <span style="color: #cd00cd;">library</span>(RODBC)
>
> However, if I do
>
> emacs -Q --batch -l myinit.el -f 'org-publish-all'
>
> then I get something like
>
> <pre class="src src-R"><span style="font-weight: bold; text-decoration: 
> underline;">library</span>(RODBC)
>
> It seems odd to me that same config results in different outputs when
> publishing interactively and in a batch mode. I would prefer colored
> output.
>
> What should I pay attention to? I have a feeling that something is not loaded 
> which does in interactive mode, or vice versa.
>

The library used to colorize source code relies on the actual Emacs
colorization mechanisms, which aren't available in batch mode.  The best
solution in this case is to save your colorized CSS information into a
.css file with `org-export-htmlize-generate-css', and then use that file
in all of your exports by setting `org-export-htmlize-output-type' to
'css.  This way your fontification will be consistent across batch or
regular export.

Best,

>
> Mikhail
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



reply via email to

[Prev in Thread] Current Thread [Next in Thread]