There are many options to config stylelint, like
a stylelint property in package.json
.stylelintrc.json, .stylelintrc.yaml, .stylelintrc.js etc.
a stylelint.config.js file
Is there any difference when I'm deciding which one to use?
Official document says:"You may want to use an extension so that your text editor can better interpret the file, and help with syntax checking and highlighting."Any other difference except that?
Thanks!
stylelint uses cosmiconfig, all of the options you mention are made available through cosmiconfig.
So it's more about flexibility and offering that personal choice to stylelint users to choose a filename and format that they find most suitable.
Each of the formats are fully supported and have no other differences with different formats offering different functionality, they all support all of stylelints configuration options out of the box
Related
I'm looking for a solution that would allow us to have separate themes in the built docs through rtd, based on urls. The project is github-hosted, so we're using the Webhook integration there for rtd.
Basically, we'd like to have slug.readthedocs.io use a default, and have a custom domain through rtd, i.e. docs.ourdomain.org, use a theme styled to match our site.
on_rtd, it seems, is True whenever rtd builds the docs, so that's likely not useful, but please correct me if I'm wrong.
Perhaps multiple Webhooks? Some sphinx magic I haven't discovered yet?
Considering using branches or tags, but that just seems a bit much, and would, I believe, call for multiple project-naming on rtd. Though, again, please correct me if I'm wrong.
At the moment, we've implemented our site theming, and simply let that be in place for both, but ideally, we hope to have the slug.readthedocs.io site be more generic and in-line with the readthedocs.io feel.
At the moment, Read the Docs doesn't support multiple themes for a given repo/branch.
There are at least a couple of approaches available here.
1) Use branches to host alternative docs. Read The Docs has an example project illustrating this approach here:
Read the Docs Sphinx Theme Examples
-- [Github Repository]
2) Use sub-projects.
Neither of these really addresses the use case in my question directly, but they do offer a sort alternative approach to multiple themes.
What means the TYPO3 configuration "Disable override demand"? Sometimes plugins can have this configuration. Can anyone explain it in two or three sentences? Translations in my language are not satisfactory.
This isn't a convention, but rather an implementation that depends on each extension, but I assume you mean EXT:news so I will use that as example.
Disabling override demands means users can't override the settings you (the editor) defined in the plugin instance, when they view the plugin rendered in the frontend. So for example, disabling this means things like filtering and sorting will not be possible - the filtering and sorting you decided will always be used.
Take this with a grain of salt though. There could be some arguments which are exempt from being disabled - as stated, the exact implementation may differ and you need to check the individual extensions' documentation for a detailed description of the behavior.
I would like to use ReadTheDocs to host my Sphinx documentation. The project is hosted on github. I can connect to it just fine.
The particularity that I have is that the project contains 2 Sphinx documents (e.g. a programmer's manual and a user's manual). ReadTheDocs appears to be detecting both (there are two conf.py) and building both. However when it comes to displaying them, it displays the html for only one of them, as far as I can make it, the first one alphabetically.
So my questions are:
If both have been built, how do you get to see the other one?
Is there a way to use "subprojects" to specify the path to each conf.py and hence have clear URL to each document/manual? That would be the ideal solution.
Read the Docs does not support building two different sets of documentation from the same repository and same Read the Docs project. However, you could use sphinx-multiproject extension to achieve this.
You will need to define this extension in your requirements (see https://docs.readthedocs.io/en/stable/guides/specifying-dependencies.html) and then import your repository twice under Read the Docs --one time per set of documentation you want to host: mydocs-users and mydocs-developers, for example.
Note that this is the exact pattern that Read the Docs itself uses for its documentation:
User's documentation: https://docs.readthedocs.io/
Developer's documentation: https://dev.readthedocs.io/
The repository for both sets of documentation is the same (https://github.com/readthedocs/readthedocs.org/) but documentation generated on each of the projects is defined by that sphinx-multiproject extension. See https://github.com/readthedocs/readthedocs.org/blob/6bf0bede7b757f1e9458e29ba89b591389cae4d5/docs/conf.py#L48-L63
Be sure you follow the tutorial.
Usually you need an index (in conf.py it is referred as master_doc).
Then each file must be referenced, either in a toctree or a include, or a link, etc.
Look at examples on github (ie: the Sphinx-doc repository).
I'm trying to make an Eclipse plugin that will highlight certain lines certain colors based on outside input. Is there any way to specify the behavior of a new IMarker rather than rely on basic implementation of bookmarks, problems, etc?
Thanks
I don't have the complete solution, but I think, I can give you some starting points.
The basic idea is to create custom annotations for your custom markers. You can define your own marker types, and register constant formatting rules for it (the latter one is a shameless link to one of my own blog posts). In this case, if your code creates the correct marker types, you can add the different formatting regarding the output.
On the other hand, if you have only a single problem type, I don't know the correct answer, but the Annotation Model Creation extension seems to be the answer. For details look at the Eclipse help.
I am using the Zend Framework and I cannot locate in the documentation the values I can specify in the application.ini file. Does anyone have a link to where I could see them?
Thanks,
Darren
There is no exhaustive list, since you can specify arbitrary configuration values that are specific to your app.
The "built-in" stuff is mostly about configuting build-in resource plugins, so a good source of information on those might help you. The manual describes them in fair detail.