Add Support for CriticMarkup about zettlr

[semiopat]

May I add a late comment to this thread closed instead of (and I hope better than) opening a new one?
I think, after reading your dialog, that criticmarkup can cover a gap between HTML comments (those are not equivalent: HTML comment can't handle replace, for instance) and a git repository.
I think criticmarkup's purpose is to help collaborative asynchronous editing, with less technical effort. the less technical effort part is what the markdown was made for, get it fluid when it comes to write. The GIT repository does not match this goal.
What I like in Zettlr, is that it's buit with academic needs in mind; reviewing papers is a part of theses needs, and criticmarkup seems to be a simple way to match it.

That said, I agree with the fact it's not a priority…

[nathanlesage]

I really didn't completely push it off my agenda, but it's going to be somewhat harder to implement, so yes, not now, but sometime!

[samarulmeu]

So, in the end you've giving up on adding CriticMarkup support?

[nathanlesage]

For now, as its support is still minimal and using standard HTML comments one can get a similar result. Besides, I‘m still unsure whether or not a good git integration with file diff wouldn‘t be even better... but anyways, there are more pressing issues for now. I‘ll reconsider once these are resolved. Besides, closing old issues with not so much of a support by the user base helps me not to lose my mind!

[samarulmeu]

Maybe I should have waited a little bit before posting, but I was so exited when I discovered what CriticMarkup is and can do that I searched in the issues to see if it is included in the roadmap.
I think you are right -- there are more important issues for the moment and an implementation of the named option will not appeal to most users.
The way I see it, the CriticMarkup is great for editing (I was thinking a lot of something like this -- in old days of WYSIWYG I was using a lot of footnotes and colors for highlighting), but not for everyone.

I already have my notes in a local git repository, so that I can already see the changes in a time line, but integrating in Zettlr, if it will not blot up the app, will also be nice.
Keep up the good work.

P. S. I was testing intensively the 1.3.0-alpha version and, for the moment, I found no problems with it. The only thing that I found is that it seems a bit slower than the previous version (especially when copying from the web), but that also could be an impression as I worked with bigger files lately.

[nathanlesage]

P. S. I was testing intensively the 1.3.0-alpha version and, for the moment, I found no problems with it. The only thing that I found is that it seems a bit slower than the previous version (especially when copying from the web), but that also could be an impression as I worked with bigger files lately.

Please keep an eye out for such subtle things; especially longer durations until something works are normally a sign that there's a bottleneck evolving that we should stop before it gets too big!

As a general rule of thumb: The only thing that should be expected to be slow currently is opening up the app, as the file reader currently works synchronously and that takes a lot time with many files. But everything else should be smooth -- otherwise I must get to this as well!

[semiopat]

I can wait. Thanks for your amazing work!

…

Le 15 juil. 2019 à 08:52, Hendrik Erz ***@***.***> a écrit : I really didn't completely push it off my agenda, but it's going to be somewhat harder to implement, so yes, not now, but sometime! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35?email_source=notifications&email_token=AGFOZ22E3AJOPU3776W3H6LP7QNEBA5CNFSM4FWHXR32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ43BBI#issuecomment-511291525>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGFOZ27EKIFYTUMHSZEJFP3P7QNEBANCNFSM4FWHXR3Q>.