I'd like to remove the typical IPython prompts In [35]: from the LaTeX produced by jupyter-nbconvert --to latex.
Once there was a template, style_simple.tplx, that almost did what I want but now it has been removed, otoh its companion templates, style_bw_ipython.tplx et c. are still distributed but don't work any more with the new nbconvert.
I understand that I have to write an ad hoc template in the jinja2 template language, but both jinja2 template syntax and its use in nbconvert have eluded my understanding, despite the number of attempts I had made.
Given that I cannot write such a template, I'm seeking assistance with the task.
The two places prompts appear are the input and execute_result block.
The default input block:
((* block input scoped *))
((( add_prompt(cell.source | highlight_code(strip_verbatim=True), cell, 'In ', 'incolor') )))
((* endblock input *))
We can replace that with a block that puts highlighted source code on the page directly in a verbatim block, instead of adding prompts:
((* block input scoped *))
\begin{Verbatim}[commandchars=\\\{\}]
((( cell.source | highlight_code(strip_verbatim=True) )))
\end{Verbatim}
((* endblock input *))
For outputs, we can use the fact that an execute_result output is actually the same as a display_data output, only adding prompts. So we can tell our template to display execute_result outputs the same as display_data:
((* block execute_result scoped *))
((* block display_data scoped *))
((( super() )))
((* endblock display_data *))
((* endblock execute_result *))
Putting it all together in a custom template, extending the default article template:
% extend the default article template:
((* extends 'article.tplx' *))
% display input without prompts:
((* block input scoped *))
\begin{Verbatim}[commandchars=\\\{\}]
((( cell.source | highlight_code(strip_verbatim=True) )))
\end{Verbatim}
((* endblock input *))
% treat execute_result (output with prompt) as display_data (output without prompt)
((* block execute_result scoped *))
((* block display_data scoped *))
((( super() )))
((* endblock display_data *))
((* endblock execute_result *))
If we call this file noprompts.tplx, then we can use it with:
jupyter nbconvert --to latex --template noprompts mynotebook.ipynb
Related
I am following guestbook example from the book Web Development With Clojure 3rd edition. I am struggling with including ClojureScript namespace into HTML document. Everything is working fine with example where I have one core.cljs. With that file, only I have to do is to include this piece of code into home.html document:
{% extends "base.html" %}
{% block content %}
<input id="token" type="hidden" value="{{csrf-token}}">
<div id="content"></div>
{% endblock %}
{% block page-scripts %}
{% script "/js/app.js" %}
{% endblock %}
As I mentioned, everything is ok in this situation. But when I created additional ClojureScript file and name it test.cljs and included that in the same way in the new HTML document named test.html I see errors in the console such as "Target container is not a DOM element.". I think that something is wrong with this part:
{% block page-scripts %}
{% script "/js/app.js" %}
{% endblock %}
But I can't figure out how to solve this. Actually, my question maybe should be: How to include ClojureScript into HTML file?. Is the only way this piece of code?
{% block page-scripts %}
{% script "/js/app.js" %}
{% endblock %}
Or, maybe I should change {% script "/js/app.js" %} part of this snippet?
Or even better, when I create simple HTML file without extending any base.html file, how to add clojurescript namespace, how to reference it? You know, like javascript helloworld example
<script src="myscripts.js"></script>
How to do this in ClojureScript? I am using Luminus framework.
In general, a Luminus project with ClojureScript support will compile all ClojureScript code into a single app.js file, as in this block of the project.clj file (from a project I just created with lein new luminus guestbook +h2 +immutant +cljs, where the +cljs is the important bit):
:cljsbuild{:builds
{:app
{:source-paths ["src/cljs" "src/cljc" "env/dev/cljs"]
:figwheel {:on-jsload "guestbook.core/mount-components"}
:compiler
{:main "guestbook.app"
:asset-path "/js/out"
:output-to "target/cljsbuild/public/js/app.js" ;; <= THIS
:output-dir "target/cljsbuild/public/js/out"
:source-map true
:optimizations :none
:pretty-print true}}}}
That's a very convenient default for single page apps (a la Angular or React), but I think you are thinking of a website with different HTML pages, each one including a different JavaScript file (in this case, everything is compiled to a single JavaScript file).
If you want to call different functions (eg. from different namespaces), you'll need to export them (to make them easily available from JavaScript) and then call each function in their respective HTML file, a bit like the following:
...
<!-- in test.html -->
{% script "/js/app.js" %}
<script>
guestbook.test.init();
</script>
...
in src/cljs/guestbook/test.cljs
(ns guestbook.test)
(defn mount-components []
(let [content (js/document.getElementById "app")]
(while (.hasChildNodes content)
(.removeChild content (.-lastChild content)))
(.appendChild content (js/document.createTextNode "Welcome to the test page"))))
(defn ^:export init []
(mount-components))
Also, remember to rebuild your ClojureScript files. You can leave another terminal running the following command to recompile any ClojureScript files when they change: lein cljsbuild auto
I'm working on a personal Django project where my plan is to make some sort of function in my site in form of a CSS Marquee (scrolling text).
I was able to make a marquee.html file with the code from here, and use it on several pages on my site using {% include "marquee.html" %} blocks, but the displayed string in the marquee is within the HTML file itself (marquee.html) between <p>-tags
Is there any way to send a variable/string along with a {%include "" %} block that replaces/adds to the <p> tags at the end of the marquee code?
(e.g. {% include "marquee.html" {{ stringToDisplay }} %} )
The current context is available for the included template. You can use the "with" option to send any additional context.
{% include "marquee.html" with message="Hello" %}
and in your marquee.html template
<div>{{ message }}</div>
The include documentation is here
I have the following setup:
base.html
...
{% block main-content %}
{% endblock main-content %}
...
admin.html
{% extends "base.html" %}
{% load staticfiles %}
{% block main-content %}
{% include users.html %}
{% endblock main-content %}
The file users.html uses tags like '{{ users }}' because it renders from a view that also returns several variables. Right now, if I call admin.html I can see the template of users.html (basic html, css) without the variables. I don't think the template is rendering from my views.py.
Is there anyway I can obtain the variables that the view is returning?
Note: base.html and admin.html are in the same django app, while users.html is in a different one.
Thank you!
This seems to be a common misapprehension.
Templates do not belong to views. The only relationship is that a view may (or may not) render a template: but a template itself may be rendered by one or many views, and has no actual knowledge of any of them. So when you "include" your template inside your admin template, there is no relationship to any other view that might also render it; if you need some variables in that view, you'll need to pass them there yourself.
Note that this sort of thing - that is, including a template along with some specific context variables - is usually best handled as an inclusion tag
I have some code that I've been repeating a lot in one of my jinja2 templates. When I've been turning a string into a link I want to check to see if it has a trailing / at the end and if it does then truncate it. This is what I'd like it to look like.
{% macro remove_trailing_slash(path) %}
{% if path[-1:] == '/' %}
{{ path[:-1] }}
{% else %}
{{ path }}
{% endif %}
{% endmacro %}
The problem I'm having is figuring out how to pass the modified path back to the original caller. I can't seem to find a return statement in the jinja2 docs.
This is something that would be better done with a filter in Jinja, rather than a macro.
In my understanding macros are for reusing pieces of logic, they don't really map to functions in Python (it would be within the Jinja compiler's right to copy the contents of the macro to every place the macro is invoked). Filters, on the other hand, are designed to manipulate the template's data before it is passed on to the "output stream".
If you register a filter with the Jinja environment, then you can do something like this:
{{ one_url | remove_trailing_slash }}
{{ another_url | remove_trailing_slash }}
If you are doing this all over your templates, you may be better off sanitizing these values before even passing them off to your templates.
You can also create a macro to wrap this pattern:
{% macro link(url) %}
{{ url | remove_trailing_slash }}
{% endmacro %}
Is there a way I can load a jinja2 template from within another template file? Something like
{{ render_template('path/to/file.html') }}
I have some snippets which I want to reuse, so it's important for me to have this functionality.
{% include "file" %} does this. See the jinja2 docs for more information.
Use either the extends tag or the include tag, depending on how you want to design your multi-file views.
You should make template files with {% macro -%}s and use {% import "file" as file %} to use the macros in other template files. See the docs.
Here is an example:
<!- in common_macros.html ->
{% macro common_idiom1(var1, var2, ... varN) -%}
<!- your idiom, where you can use var1 through varN ->
{%- endmacro %}
<!- in my_template.html ->
{% import "common_macros.html" as idioms %}
{{ idioms.common_idiom1(a, b, ... N) }}
Specifically this answer allows the OP to pass arguments to his macros, similar to the behavior he desired like how render_template behaves (simply including the file as previous answers have stated above does not achieve the same behavior as render_template).
This is generally better than making a fresh template for every idiom, or than using inheritance, which is a special case solution (what if you want to use the snippet multiple times in one template)?