Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts about adapting a WYSIWYG editor to work with Cryogen #266

Open
simon-brooke opened this issue Sep 1, 2024 · 5 comments
Open

Thoughts about adapting a WYSIWYG editor to work with Cryogen #266

simon-brooke opened this issue Sep 1, 2024 · 5 comments

Comments

@simon-brooke
Copy link
Contributor

Context

I'm setting up a website for an activist group most of whom are not geeks, and I need to make it as simple as possible for them to use.

Issue

Cryogen uses embedded EDN-formatted metadata at the beginning of Markdown files; existing WYSIWYG markdown editors don't recognise this, and Typora, the editor which I have been up to now actively using and recommending, inserts unneeded blank lines which, although they don't actually do harm, annoy my autistic soul and are distracting.

My initial approach to dealing with this problem was to implement metadata inference, which I've done and which has been merged into the current release and which works well for my personal blog, and for any site which has only one author.

However, where there are multiple authors, the author of each article will be shown as the last person to have executed lein run, which, in this case, will usually be a post-push git hook. I need to capture (at least) the actual author identity as metadata. The ability to have a :draft? boolean as metadata is also a very good one, and, actually, once you've accepted the idea that you need metadata you might as well have a full, extensible, suite of metadata.

Sidenote

Zettlr, a GPL licensed Markdown editor, uses embedded JSON metadata in a very similar way to Cryogen's embedded EDN metadata, and handles it well.

Proposed solutions

  1. Just say, "Simon, get over yourself" in an annoyed voice, very loudly. Embedded EDN metadata works, and non-geeks can be taught to edit it -- I can even provide them with a metadata template;
  2. Alter cryogen-core.compiler/using-embedded-metadata so that it recognises and reads either EDN formatted or JSON formatted metadata, and have the users use Zettlr;
  3. Choose an open source WYSIWYG markdown editor, fork it, and add a metadata editing pane to it (this is what I'm currently thinking of doing) -- this would require no change to Cryogen itself.

Relatedly, I am thinking of altering cryogen-core.infer-meta/infer-meta so that, having inferred metadata, it writes that metadata back to the file.

Thoughts, apart from the obvious "Simon, for heaven's sake, just get over yourself"?

@yogthos
Copy link
Member

yogthos commented Sep 1, 2024

I think adding support for json metadata would be fine. It could just be another config option. And using Zettlr compatible keys for json config seems like a decent way to go. It sounds like it should be a fairly small change overall.

@simon-brooke
Copy link
Contributor Author

Right, I'll get started on that.

@simon-brooke
Copy link
Contributor Author

simon-brooke commented Sep 8, 2024

OK, completely baffled. Where do the instantiations of cryogen-core.markup/Markup get created and registered? I can see where it happens in the test suite, but when it happens there they don't their render_fn method instantiated.

Context: I need to pass a Markup (for markdown) with a working render function into a test, in order to test that I can render a file with metadata correctly.

@yogthos
Copy link
Member

yogthos commented Sep 8, 2024

oh that's implemented in the libraries using reify, requiring a dependency provides the expected namespace

https://github.com/cryogen-project/cryogen-markdown/blob/master/src/cryogen_markdown/core.clj

@simon-brooke
Copy link
Contributor Author

OK, I have tests which pass TODAY, but because the tests do (reset-resources) and therefore test resources have to be set up each run and will have different file dates tomorrow, they will not pass tomorrow. So I'll need to see exactly what fails tomorrow and alter the tests so they're not sensitive to file dates.

Expect a pull request tomorrow or Wednesday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants