config file (as in gitconfig or sublimetext) to configure macdown

[timotheecour]

Could we have a config file (eg: .macdown) to configure the various options of macdown (eg: View>Renders TOC) ?

Even something barebones and subject to change as a start would be great. It's a lot easier to edit a config file (and share it online) than to click on menu items (and more cross-platform too). It also should be easier to implement/maintain and to discover the available options for the user.

Search path could be same as gitconfig (ie a global one, which can be overridden by searching in parent directories)

Format could be json (as in sublimetext) or gitconfig like

https://github.com/uranusjr/macdown/issues/395 also proposes other config file options which would be useful

[uranusjr]

This is something I’ve though about, but having an extra file for configuration seems strange. Maybe it would be better to use front-matter for this? Something like

config:
    toc: true
    underline: false
    table: true
---

At the top of the file to override some global configs.

Problem is, I’m not sure whether other services (e.g. Jekyll) react well with unrecognised attributes. Does anyone have an idea?

[Jmuccigr]

Using such config files is most un-Mac-like. Please don't. There are preferences for that, even if the format is not the same.

[uranusjr]

I think I misunderstood the original issue message.

A application config file Sublime Text’s would be very awkward for a Mac application. MacDown is not a cross-platform application, so the config being in a universal format is basically moot.

What I suggested in my previous comment is actually something to enhance the preference mechanism, similar to the idea of EditorConfig. It can be used to provide per-file configuration, for example if I generally want superscripts, but want to disable it for some files (maybe because it is not compatible with another service’s syntax), I can use this

config:
    superscript: false

to disable it just for this file, without having to tweak the preferences every time I edit it to get the rendering results right (and having to re-enable it again after I’m done with it).

[ohthetrees]

If the OP really wants a config file, perhaps they'd be satisfied with the plist file.

Cedar

On Jun 28, 2015, at 8:05 AM, Tzu-ping Chung notifications@github.com wrote:

I think I misunderstood the original issue message.

A application config file Sublime Text’s would be very awkward for a Mac application. MacDown is not a cross-platform application, so the config being in a universal format is basically moot.

What I suggested in my previous comment is actually something to enhance the preference mechanism, similar to the idea of EditorConfig. It can be used to provide per-file configuration, for example if I generally want superscripts, but want to disable it for some files (maybe because it is not compatible with another service’s syntax), I can use this

config: superscript: false to disable it just for this file, without having to tweak the preferences every time I edit it to get the rendering results right (and having to re-enable it again after I’m done with it).

— Reply to this email directly or view it on GitHub.

[FranklinYu]

Front matters like

---
config:
    toc: true
    underline: false
    table: true
---

looks cool as long as the renderer supports it (like GitHub); it may be rendered terribly otherwise. For example, current Hoedown renders

---
config:
    toc: true
    underline: false
    table: true
---

body

as

<hr>

<p>config:
    toc: true
    underline: false</p>

<h2>    table: true</h2>

<p>body</p>

Note that table: true is rendered as <h2>. I propose HTML comments:

<!--
config:
    toc: true
    underline: false
    table: true
-->

body

[Jmuccigr]

If we're going to have something in the file itself (and I'm neutral on that), it should be YAML, as it's already something MacDown supports to some extent and is also used by pandoc.

[FranklinYu]

Forgot that currently MacDown supports front-matter. I take back my proposal. Just keep the current behavior for less surprise.

Concerning how Jekyll treats unrecognised attributes:

Any variables in the front matter that are not predefined are mixed into the data that is sent to the Liquid templating engine during the conversion.

From Jekyll doc. I assume that it works well with unrecognised attributes. This is also the case for Assemble, Hugo, and Statamic.