razziel89 / mdslw Goto Github PK

Before a 1.0 release that comes with some stability guarantees, some things should be taken care of. This is issue collects all such tasks.

• #16: handle features in a more sustainable way
• #15: support hierarchical configuration files
• #17: simplify supporting new extensions

In case a file differs from the desired state, it could be useful to provide more information about the deviation. That way, mdslw could possibly even serve as a linter that could be hooked into a general purpose language server such as efm-langserver. The similar crate could be used to compute a diff. Since such a computation can be costly, it should only be done if explicitly requested.

Many Some markdown extensions appear to work the following way:

• There is a single line that has a specific indentation, prefix character, or may simply contain text.
• The next line also has a specific indentation or a prefix character, but both values are different than for the previous line.
• At the same indentation level, arbitrary markdown content may follow. Not all extensions require indentation here, but requiring the same indentation level makes detection a lot easier and, thus, is likely a requirement that should be added.
• After an optional empty line, a line like the second one and everything following it may repeat.

In the example of definition lists, the first line is simply unindented text while the second line may have some indentation and has a colon as a prefix character.

Such extensions could be supported by adding a generic struct that contains all that logic. It basically detects the markdown covered by the extension and extracts the basic markdown contained within. Then, that extracted markdown, with a reduced maximum line width due to the indentation, can be formatted in the usual way.

Currently, definition lists get mangled by mdslw.
I realize, that there are a lot of markdown extensions out there, but I could not find an explicit statement about scope in the README.md (CommonMark?).

Is this a bug or a feature :) ?

At the moment, the --features flag serves as a bit of a dumping ground for new functionality that may or may not be useful. Those --features that are unused or not useful should be removed while those --features that are use and useful should be converted into something more permanent. They could be converted into their own command line flags, for example.

If you are a user of mdslw and find specific features useful, please comment on this issue, naming those useful --features. At the moment, more or less all --features are up for removal.

Hello,
it seems that mdslw formats frontmatter as well in some cases. An example:

---
item1: hello
item2:
- my
- list
---

mdslw should not change this, but when run, it yields:

---
item1:
hello item2:
- my
- list
---

It would be desirable to support something similar to a .prettierrc file, maybe calling it mdslw.yaml, that can be used to configure mdslw in a hierarchical way. That is, each such file influences how mdslw behaves for all files below it in the file tree. If there are two config files above a markdown file, then the closer one will overwrite options in the one farther away. The precedence of config files lies above that of default values and below that of environment variables.

It would be useful if clap supported such layered/hierarchical config files, but it does not at the moment, cf. this discussion.