Support for "ignore" comments #53
Comments
This comment was marked as resolved.
This comment was marked as resolved.
|
Hi @jamescurtin and thanks for the issue! I like the feature. Some notes/thoughts regarding implementation already 😄
I'm expecting a bug free implementation could be quite hard to come up with. A plugin that brings formatting support for admonition (that you mentioned) might be easier (although not as general solution ofc).
This discussion is related to ignoring stuff from a safeguard that ensures mdformat does not alter markdown AST. All markdown is still formatted, so it's not really the same thing. |
|
Hi folks, any updates here? This is currently a bit of a deal breaker for me. |
|
No one is currently working on this to my knowledge. It seems you also need support for the non-standard admonition syntax, so seems like a plugin that brings support for that syntax would help you as well. |
This comment was marked as duplicate.
This comment was marked as duplicate.
…s locally
If you're with the VPN connected, turn it off.
feat(aleph#PDB behaves weird): PDB behaves weird
Sometimes you have two traces at the same time, so each time you run a PDB
command it jumps from pdb trace. Quite confusing. Try to `c` the one you don't
want so that you're left with the one you want. Or put the `pdb` trace in a
conditional that only matches one of both threads.
fix(gitpython): Deprecate tmpdir in favour of tmp_path
feat(pytest#The tmp_path fixture): The tmp_path fixture
You can use the `tmp_path` fixture which will provide a temporary directory
unique to the test invocation, created in the base temporary directory.
`tmp_path` is a `pathlib.Path` object. Here is an example test usage:
```python
def test_create_file(tmp_path):
d = tmp_path / "sub"
d.mkdir()
p = d / "hello.txt"
p.write_text(CONTENT)
assert p.read_text() == CONTENT
assert len(list(tmp_path.iterdir())) == 1
assert 0
```
fix(pytest#The tmpdir fixture): Deprecate the tmpdir fixture
Warning: Don't use `tmpdir` use `tmp_path` instead because `tmpdir` uses `py`
which is unmaintained and has unpatched vulnerabilities.
feat(python_snippets#Pad integer with zeros): Pad integer with zeros
```python
>>> length = 1
>>> print(f'length = {length:03}')
length = 001
```
feat(elasticsearch#Get documents that match a string): Get documents that match a string
```bash
curl \
-H 'Content-Type: application/json' \
-XPOST "https://localhost:9200/_search" \
-d' { "query": { "query_string": {"query": "test company"} }}'
```
feat(linux_snippets#df and du showing different results): df and du showing different results
Sometimes on a linux machine you will notice that both `df` command (display
free disk space) and `du` command (display disk usage statistics) report
different output. Usually, `df` will output a bigger disk usage than `du`.
The `du` command estimates file space usage, and the `df` command shows file
system disk space usage.
There are many reasons why this could be happening:
* [Disk mounted over data](linux_snippets.md#disk-mounted-over-data)
* [Used deleted files](linux_snippets.md#used-deleted-files)
feat(linux_snippets#Clean up docker data): Clean up docker data
To remove unused `docker` data you can run `docker system prune -a`. This will
remove:
- All stopped containers
- All networks not used by at least one container
- All images without at least one container associated to them
- All build cache
Sometimes that's not enough, and your `/var/lib/docker` directory still weights
more than it should. In those cases:
- Stop the `docker` service.
- Remove or move the data to another directory
- Start the `docker` service.
In order not to loose your persisted data, you need to configure your dockers to
mount the data from a directory that's not within `/var/lib/docker`.
feat(mdformat#issues): Issues
- It doesn't yet
[support admonitions](hukkin/mdformat#309)
- You can't
[ignore some files](hukkin/mdformat#359),
nor
[some part of the file](hukkin/mdformat#53)
|
This seems like it ought to be a fairly high priority. There will always be edge cases that auto-formatters end up breaking so having an escape hatch in those cases seems somewhat necessary. In my particular case mdformat is breaking mkdocs admonitions but I could have worked around that if this existed. Unfortunately, for now, I'll have to disable mdformat. |
- hukkin/mdformat#319 - and more generally hukkin/mdformat#53
- hukkin/mdformat#319 - and more generally hukkin/mdformat#53
- hukkin/mdformat#319 - and more generally hukkin/mdformat#53
|
@rmorshea did you use |
|
I gave those two a try and had no luck. I'll file an issue, but I suppose the point is that if ignore comments existed I'd be able to work around the problem until it got fixed without having to figure out how to patch those projects myself. |
Is your feature request related to a problem? Please describe.
Some officially supported Python Markdown extensions (like admonition use non-standard Markdown syntax. These cases are not properly handled by the parser currently. For example:
# Some title !!! note This will render as a tooltip box. Back to normal markdown content.Describe the solution you'd like
It would be useful if there was an "ignore" comment that could be added to a markdown file to skip formatting specific sections. The
prettierlibrary uses<!-- prettier-ignore -->and<!-- prettier-ignore-end -->for this purpose.Describe alternatives you've considered
Plugins could be written for to handle cases like this, but it would be useful if there was a global way to disable formatting in specific sections of a document.
Additional context
It looks like there's a similar discussion happening on an existing PR about how to ignore blocks of code. I'd be fine with a solution where I could wrap certain sections in a div that sets a class that's globally ignored, but I feel like a plain comment would be a better interface for this use case, as it wouldn't require modifying the AST of the markdown.
The text was updated successfully, but these errors were encountered: