I need to invert the color when the mode is dark.
When I try to apply dark:invert I get the below error
./src/styles/input.css (./node_modules/css-loader/dist/cjs.js??ref--5-oneOf-4-1!./node_modules/postcss-loader/src??postcss!./src/styles/input.css)
Syntax error: The `dark:invert` class does not exist, but `2xl:invert` does. If you're sure that `dark:invert` exists, make sure that any `#import` statements are being properly processed before Tailwind CSS sees your CSS, as `#apply` can only be used for classes in the same CSS tree. (2:10)
1 | input[type="date"]::-webkit-calendar-picker-indicator {
> 2 | #apply dark:invert;
| ^
3 | }
I have a documentation site using MkDocs. It contains a list of documents, all with the same basic structure (we only have a list of experimental notebooks). Each notebook (written in a separate MarkDown file) should contain an author + date in the beginning using the following:
<style>table, td, th {border:none!important; font-size:15px}</style>
| | |
| -------------- | :-------------------------- |
| **Author(s):** | First Author, Second Author |
| **Date:** | 2024-01-23 |
What I would like to have is some kind of templating that enables the users to avoid adding the above lines (eg. avoid adding CSS) but instead just specifying the list of authors and a date. This would enable me as a documentation owner to change the formatting later if needed without changing each .md file content.
I read about Jinja templates and wonder if it could be used to achieve this?
My notes after studying a problem that is similar to yours:
One example using global blocks
in your case you should look at mkdocs with jinja macros.
The metadata can be directly accessed in your markdown.
So you can place at start of the document
authors: First A, Second A
docdate: 2024-01-23
and then in the document text uses {{ authors }}, it will be replaced.
You requested to use this globally without changing the markdown files. This can be done by including a block of markdown from an external file in your document. First setup mkdocs include plugin and then use something like this:
---
authors: First, second
docdate: 2024-01-23
---
{% include-markdown "../authortable.md" %}
In the authortable you can directly put your layout for the author table, and include the metadata. The include is done before variable expantion.
Your include file could be:
<style>table, td, th {border:none!important; font-size:15px}</style>
| | |
| -------------- | :-------------------------- |
| **Author(s):** | {{authors}} |
| **Date:** | {{docdate}} |
Other approaches
There are other ways of course.
You can make a python macro and call this with the metadata variables:
{{ make_the_table (authors , docdate) }}
The advantage of the macro approach is that you have the full power of Python, and can use databases, condition, file system properties, etc etc.
You can also automatically modify the raw markdown without having any tags in the documents, using a method on_post_page_macros(env) as described in advanced macro.
You may want to use metadata also called frontend data, as described in the yaml-style-meta-data section. Such information is placed at the beginning of your markdown file. The content can then be used to generate content.
The macro plugin is made for this and can be found here https://mkdocs-macros-plugin.readthedocs.io
So I've been trying to get Sphinx to generate inheritance diagrams for all submodules / classes when generating .rst files through sphinx-apidoc, similar to this example. But I have not found any built-in features to do this in Sphinx.
The nearest solution I found was to manually add an inheritance diagram line with the class name to each class docstring in code, but this is not very convenient.
So the question is how do I add inheritance diagrams to all module
.rst files?
Found a solution to the problem:
Go to the folder /usr/local/lib/python3.6/dist-packages/sphinx/templates/apidoc/
Open package.rst_t
After *{{- [submodule, "module"] | join(" ") | e | heading(2) }}* add:
.. inheritance-diagram:: {{submodule}}
:parts: 1
You also need to add these extentions in the conf.py file when making the html files:
extensions = ['sphinx.ext.graphviz','sphinx.ext.inheritance_diagram']
To make the graphs more readable I also added this to conf.py (TB=Top to bottom view):
inheritance_graph_attrs = dict(rankdir="TB", size='""')
StackOverflow is denoted as a place for AwesomeWM community support.
I would like to have a dedicated Tag in my AwesomeWM config where only three particular application will be running all the time. I managed to create new tag using sample config, and I managed to filer the applications using awful.rules.rules and place them into the tag.
I am experiencing troubles in understanding how AwesomeWM layout engine really works. I would like to achieve the following: three static columns of fixed widths, each application is located at its own column, when focus changes then no rearrangement happens, when any application is not running, then its reserved place is remain empty.
___________________
| | | |
| | | |
| A | B | C |
| | | |
| | | |
___________________
How do I specify layout in such case? Should I write my own one? Can I use flexible layout and specify position for client? What is the recommended correct way to achieve my goal?
I am experiencing troubles in understanding how AwesomeWM layout engine really works
A layout is a table with two entries:
name is a string containing, well, the name of the layout
arrange is a function that is called to arrange the visible clients
So you really only need to write an arrange function that arranges clients in the way you want. The argument to this function is the result of awful.layout.parameters, but you really need to care about
.clients is a list of clients that should be arranged.
.workarea is the available space for the clients.
.geometries is where your layout writes back the assigned geometries of clients
I would recommend to read some of the existing layouts to see how they work. For example, the max layout is as simple as:
function(p)
for _, c in pairs(p.clients) do
p.geometries[c] = {
x = p.workarea.x,
y = p.workarea.y,
width = p.workarea.width,
height = p.workarea.height
}
end
end
Should I write my own one? Can I use flexible layout and specify position for client?
Well, the above is the write-own-layout approach. Alternatively, you could also make your clients floating and assign them a geometry via awful.rules. Just have properties = { floating = true, geometry = { x = 42, y = 42, width = 42, height = 42 } }. However, with this you could e.g. accidentally move one of your clients.
What is the recommended correct way to achieve my goal?
Pick one. there is no "just one correct answer".
Is it possible to strike text through in Restructured Text?
Something that for example renders as a <strike> tag when converted to HTML, like:
ReSTructuredText
I checked the docs better, as suggested by Ville Säävuori, and I decided to add the strikethrough like this:
.. role:: strike
:class: strike
In the document, this can be applied as follows:
:strike:`This text is crossed out`
Then in my css file I have an entry:
.strike {
text-decoration: line-through;
}
There is at least three ways of doing it:
.. role:: strike
An example of :strike:`strike through text`.
.. container:: strike
Here the full block of test is striked through.
An undecorated paragraph.
.. class:: strike
This paragraph too is is striked through.
.. admonition:: cancelled
:class: strike
I strike through cancelled text.
After applying rst2html you get:
<p>An example of <span class="strike">strike through text</span>.</p>
<div class="strike container">
Here the full block of test is striked through.</div>
<p>An undecorated paragraph.</p>
<p class="strike">This paragraph too is is striked through.</p>
<div class="strike admonition">
<p class="first admonition-title">cancelled</p>
<p class="last">I strike through cancelled text.</p>
You use them with a style
.strike {
text-decoration: line-through;
}
Here I have taken the admonition directive as example but any
directive that allow the :class: option would do.
As it generates a span the role directive is the only one that
allow to apply your style to a part of a paragraph.
It is redundant to add a class strike to a directive also named
strike, as suggest Gozzilli, because the directive name is the default
class for the html output.
I have checked these syntax both with rest2html and Sphinx. But
while everything works as expected with rest2html the class
directive fail with Sphinx. You have to replace it with
.. rst-class:: strike
This paragraph too is is striked through.
This is only stated in a small
footnote of Sphinx reSt Primer.
According to the official spec there is no directive for strikethrough markup in ReST.
However, if the environment allows for :raw: role or you are able to write your own roles, then you can write a custom plugin for it.
I found the other answers very helpful.
I am not very familiar with Sphinx but I am using it for a project. I too wanted the strike-through ability and have got it working based on the previous answers.
To be clear, I added my strikethrough role as gozzilli mentioned but I saved it inside my conf.py using the rst_prolog variable as discussed in the stack overflow thread here. This means that this role is available to all of your rest files.
I then extended the base html template as described above by creating layout.htmlwithin _templatesinside my source directory. The contents of this file are:
{% extends "!layout.html" %}
{% set css_files = css_files + ["_static/myStyle.css"] %}
This basically includes a custom css file to all your built default html docs.
Finally, in my _static directory within my source directory I included the file myStyle.css which contains:
.strike {
text-decoration: line-through;
}
Which the other answers have already provided.
I am merely writing this answer as it wasn't obvious to me with my limited Sphinx experience which files to edit.
Here's a Python definition of a del role, which works better than the accepted answer if you want to use the role in multiple pages of a Pelican blog or a Sphinx documentation project:
from docutils import nodes
from docutils.parsers.rst import roles
def deleted_role(_role, rawtext, text, _lineno, _inliner, options={}, _content=[]):
roles.set_classes(options)
options.setdefault('classes', []).append("del")
return [nodes.inline(rawtext, text, **options)], []
roles.register_canonical_role('del', deleted_role)
Even better would be to extend the HTML writer to produce a proper <del> tag, like this:
from docutils import nodes
from docutils.parsers.rst import roles
from docutils.writers._html_base import HTMLTranslator
class delnode(nodes.inline):
pass
def visit_delnode(self, node):
self.body.append(self.starttag(node, 'del', ''))
def depart_delnode(self, node):
self.body.append('</del>')
HTMLTranslator.visit_delnode = visit_delnode
HTMLTranslator.depart_delnode = depart_delnode
def deleted_role(_role, rawtext, text, _lineno, _inliner, options={}, _content=[]):
roles.set_classes(options)
return [delnode(rawtext, text, **options)], []
roles.register_canonical_role('del', deleted_role)
You can trivially adjust it to produce an <s>, of course.
Consider the user may have a different background, so here is no one solution that can be suitable for everyone.
1.Only one file
If you only use it only on one file. For example, you published a simple project to PyPI, and you may probably just only one README.rst file. The following may you want.
.. |ss| raw:: html
<strike>
.. |se| raw:: html
</strike>
single line
=============
|ss| abc\ |se|\defg
multiple line
=============
|ss|
line 1
line 2
|se|
789
you can copy and paste it on this website: https://livesphinx.herokuapp.com/
and will see the picture as the following:
It's simple, and you can on directly see the preview on some IDE, for example, PyCharm.
bellow is writing for the users of Sphinx
2.beginner of Sphinx
If you are a beginner of Sphinx. ( I mean maybe you want to use Sphinx to create a document, but Python is not familiar for you ) then try as following:
# conf.py
from pathlib import Path
html_static_path = ['_static', ]
html_css_files = ['css/user.define.css'] # If you want to control which HTML should contain it, you can put it on the HTML, which is very like the answer by #Gregory Kuhn.
with open(Path(__file__).parent / Path('_static/css/user.define.rst'), 'r') as f:
user_define_role = f.read()
rst_prolog = '\n'.join([ user_define_role + '\n',]) # will be included at the beginning of every source file that is read.
# rst_epilog = '\n'.join([ user_define_role + '\n',]) # it's ok if you put it on the end.
user.define.rst
.. role:: strike
user.define.css
.strike {text-decoration: line-through;}
With the rst_prolog, It can auto-add the role on each rst files, but if you change the content( that file, it contains a format that you define), then you must rebuild to make the render is correct.
3.Create roles
You can create an extension to achieve it.
# conf.py
extensions = ['_ext.rst_roles', ]
html_static_path = ['_static', ]
html_css_files = ['css/user.define.css']
# rst_roles.py
from sphinx.application import Sphinx
from docutils.parsers.rst import roles
from docutils import nodes
from docutils.parsers.rst.states import Inliner
def strike_role(role, rawtext, text, lineno, inliner: Inliner, options={}, content=[]):
your_css_strike_name = 'strike'
return nodes.inline(rawtext, text, **dict(classes=[your_css_strike_name])), []
def setup(app: Sphinx):
roles.register_canonical_role('my-strike', strike_role) # usage: :my-strike:`content ...`
The full architecture:
conf.py
_ext/
rst_roles.py
_static/
css/
user.define.css
about the rules, you can reference this link rst-roles
And I vary recommended you to see the docutils.parsers.rst.roles.py .
I wrote an extension for this.
Just pip install sphinxnotes-strike and use:
:strike:`text`
or
:del:`text`
to show strike text.
For more info: https://sphinx-notes.github.io/strike/
Since Docutils 0.17, the HTML5-writer uses <del> if a matching class value is found in inline, literal, or container elements:
.. role:: del
:del:`This text has been deleted`, here is the rest of the paragraph.
.. container:: del
This paragraph has been deleted.