I'm writing some coding tutorials in rST/Sphinx and I'd like to differentiate the input (ie: the code-block) from the output (to the terminal). Because the output needs to be literal too, I can't simply use a custom class or container, as these still get interpreted and don't display correctly (see below). How can I create a class or container or something which I can apply to a subset of literal blocks?
Note that this doesn't need to be anything fancy - maybe just changing the background colour on my "output" blocks compared to my "code-block" blocks.
I've tried:
Creating a custom class called "terminal", but this is still interpreted and returns errors about its contents:
.. container:: terminal
-----------------------------------------------
MY **EXAMPLE** GOES HERE
-----------------------------------------------
... produces an interpreted output, the class is applied correctly, but the horizontal lines are missing, the "EXAMPLE" is bold etc.
Nesting a literal block inside the terminal container:
::
.. container:: terminal
-----------------------------------------------
MY **EXAMPLE** GOES HERE
-----------------------------------------------
... produces the literal output formatted as input code:
.. container:: terminal
-----------------------------------------------
MY **EXAMPLE** GOES HERE
-----------------------------------------------
Nesting the other way around:
.. container:: terminal
::
-----------------------------------------------
MY **EXAMPLE** GOES HERE
-----------------------------------------------
... produces a div with the terminal formatting around a nested div with the literal block, which retains the standard literal formatting (which I want to over-ride).
I think there must be something really simple I'm missing but I really can't see it!
Try .. code-block:: bash where "bash" is the name of the language to which you want syntax highlighting applied. Available syntaxes are provided by Pygments as "lexers".
.. code-block:: bash
-----------------------------------------------
MY **EXAMPLE** GOES HERE
-----------------------------------------------
If you are dissatisfied with the syntax highlighting provided by your Sphinx theme, you can override it with a custom style.
As an example of what is possible, I changed the style for a specific selector. Put something similar in your theme's CSS.
div.highlight-text > table > tbody > tr > td.code > div > pre {
background-color: #32cd32;
}
Related
I've defined a conditional tag in my makefile so I can use the ONLY directive to conditionally remove blocks of text.
Makefile entry:
...
set BUILDDIR=_build
sphinx-build -t internal
...
I have a single LINE of information that I need to make disappear for a specific docs build. Here is the instance:
general:
workspace: "xxx"
<first indented list items>
.. only:: internal
xt-team-name: "phoenix" # for use with XT Grok - exclude this line otherwise **
<following list items - must stay put>
The 'internal' directive works, BUT it wipes out everything following the single line of text, that I DID NOT want to wipe out for this build. I have no spacebar characters or tab stops after the excluded text line - just a bare newline. I thought the newline would end the conditional operation?
What's the trick to get it to work on just the one piece? Can't move anything - it would disrupt the logic of the preceding and following indented sections of information. Tweaked the example to make it clearer.
White space has meaning in reStructuredText.
Indent the content that you want to hide for internal under the only directive.
Do not indent the content that you want to show.
general:
workspace: "xxx"
...
.. only:: internal
xt-team-name: "phoenix" # for use with XT Grok - exclude this line otherwise **
<following body of information>
Edit
Upon realizing that you want a list of items, not paragraphs, you can still get this to work with proper indentation.
List of Items
* One
* Two
.. only:: internal
* Two and one-half (hidden)
* Three
sphinx-build -b html . _build
sphinx-build -b html -t internal . _build
Also if you do not want "Two and one-half (hidden)" to be a member of a nested list, but of its parent list, then you can dedent it and its only directive.
I recently discovered that ls in pry can take an argument like so: ls -l.
My initial question is what the -l part actually is - it is clearly not a string or symbol, and there is no local variable or method l defined, so is there something else going on behind the scenes?
As an extension to my question, is ls just a "normal" Ruby method defined by pry, or does it behave slightly differently?
I also noted that you get a different output if you pass a string (ls 'l') or symbol (ls :l). Is there a full reference of the possible options?
Passing -l works as the whole line is evaluated as a string by the pry_eval method. From that it matches the beginning against an existing command and extracts the rest as options to be passed in. From the Pry documentation:
Nearly every piece of functionality in a Pry session is implemented as
a command. Commands are not methods and must start at the beginning of
a line, with no whitespace in between. Commands support a flexible
syntax and allow 'options' in the same way as shell commands
You can see the full list of options by running ls -h. This will return:
-m, --methods Show public methods defined on the Object (default)
-M, --instance-methods Show methods defined in a Module or Class
-p, --ppp Show public, protected (in yellow) and private (in green) methods
-q, --quiet Show only methods defined on object.singleton_class and object.class
-v, --verbose Show methods and constants on all super-classes (ignores Pry.config.ls.ceiling)
-g, --globals Show global variables, including those builtin to Ruby (in cyan)
-l, --locals Show locals, including those provided by Pry (in red)
-c, --constants Show constants, highlighting classes (in blue), and exceptions (in purple)
-i, --ivars Show instance variables (in blue) and class variables (in bright blue)
-G, --grep Filter output by regular expression
-h, --help Show this message.
Follow-up to: Colored text printing spaces in shell script
I have a script I wrote (with some help from #Barmar) which displays my current CPU and memory load visually. The output looks like so:
I then put the following into my .tmux.conf file:
set -g status-right "#(~/load.sh)"
I reload my tmux config and get the following output in the bottom-right:
There are two issues:
The CPU section should contain 11 characters: a "clear color code" character (tput sgr0) and 10 spaces. Instead it contains (B[m
The MEM section... should exist. The entire [| ] has turned into a y> -- I don't even know how the square bracket is missing, that should get printed before any color codes or weird control characters
Can tmux status bars simply not contain color?
tmux status bars don't use ANSI escape codes, they use the same color code format as other things in tmux. You want something more like (assuming 256-color mode):
#[fg=colour28 bg=colour250]Hello World!
Pandoc supports a YAML metadata block in markdown documents. This can set the title and author, etc. It can also manipulate the appearance of the PDF output by changing the font size, margin width and the frame sizes given to figures that are included. Lots of details are given here.
I'd like to use the metadata block to remember the command line arguments that I'm supposed to be using, such as --toc and --number-sections. I tried this, adding the following to the top of my markdown:
---
title: My Title
toc: yes
number-sections: yes
---
Then I used the command line:
pandoc -o guide.pdf articheck_guide.md
This did produce a table of contents, but didn't number the sections. I wondered why this was, and if there is a way I can specify this kind of thing from the document so that I don't need to add it on the command line.
YAML metadata are not passed to pandoc as arguments, but as variables. When you call pandoc on your MWE, it does not produce this :
pandoc -o guide.pdf articheck_guide.md --toc --number-sections
as we think it would. rather, it calls :
pandoc -o guide.pdf articheck_guide.md -V toc:yes -V number-sections:yes
Why, then, does you MWE produces a toc? Because the default latex template makes use of a toc variable :
~$ pandoc -D latex | grep toc
$if(toc)$
\setcounter{tocdepth}{$toc-depth$}
So setting toc to any value should produce a table of contents, at least in latex output. In this template, there is no number-sections variables, so this one doesn't work. However, there is a numbersections variable :
~$ pandoc -D latex | grep number
$if(numbersections)$
Setting numbersections to any value will produce numbering in a latex output with the default template
---
title: My Title
toc: yes
numbersections: yes
---
The trouble with this solution is that it only works with some output format. I thought I had read somewhere on the pandoc mailing-list that we soon would be able to use metadata in YAML blocks as intended (ie. as arguments rather than variables), but I can't find it anymore, so maybe it won't happen very soon.
Have a look at panzer (GitHub repository).
This was recently announced and released by Mark Sprevak -- a piece of software, that adds the notion of 'styles' to Pandoc.
It's basically a wrapper around Pandoc. It exploits the concept of YAML metadata blocks to the maximum.
The 'styles' provide a way to set all options for a Pandoc document conversion process with one line ("I want this document be an article/CV/notes/letter.").
You can regard this as more general abstraction than Pandoc templates. Styles are combinations of...
...Pandoc command line options,
...metadata settings,
...templates,
...instructions to run filters, and
...instructions to run pre/postprocessors.
These settings can be customized on a per output type as well as a per document basis. Styles can be...
...combined and
...can bear inheritance relations to each other.
panzer styles simplify Makefiles: they bundle everything concerning the look of a document in one place -- the YAML metadata (a block in the Markdown file, or a separate file).
You just add one line of metadata (style: ...) to your document, and it will be treated as a letter/article/CV/notebook or whatever.
if is a ".log" file, want to make every line containing keyword "dog" in the file to be in red, and make every line containing keyword "cat" in the file to be in yellow. This should be done automatically when I open a ".log" file in vim. Is there any way to do this?
First, define the colors as highlight groups:
:hi Dogs ctermbg=red guibg=red
:hi Cats ctermbg=yellow guibg=yellow
You can add (window-local) highlighting via the :match commands or the matchadd() function. By matching the entire line containing the keyword, you'll get all highlighted. The :autocmd installs that for your log files (though I would prefer to use Vim's filetype detection instead of hard-coding the file pattern).
:autocmd BufWinEnter *.log call matchadd('Dogs', '^.*dog.*$') | call matchadd('Cats', '^.*cat.*$')
The benefit of :match is that is doesn't interfere with syntax highlighting (which would be an alternative). The downside is that the highlighting will persist when you view a non-log buffer in the same window. (You can fix this by adding more autocmds, but it's not trivial.)