> Nice job on the improvements.

Thank you =) I also thought of adding more information about the messages (similar to what is implemented for files). For example, displaying information about the message type (text/plain, text/x-rst or text/markdown) can be useful for troubleshooting.

I also have a problem with the markdown editor. initEasyMde() no longer seems to work without adding an event for the input field, since deferred scripts now run after the page has loaded and therefore after inline scripts.

It seems to me that the ideal option would be to replace all the inline scripts with script files. This could also simplify the CSP rules when using Roundup behind a reverse proxy.

But in the case of the markdown editor loader, there is a problem with getting the parameter value from the Roundup configuration. Javascript is not my strong point and I have no ideas other than templating a JSON object and reading the editor configuration from that object.

At the moment, the problem with the order of scripts can be solved by always calling the fuction from the inline script on an event. But maybe better to think about a more correct solution right now. Maybe you have thoughts on this?

> We will need to figure out a way to sync your github repo into the
> Roundup mercurial repo. This way the Roundup code base will reflect
> your changes.

I suggest using mercurial subrepositories for Roundup templates. They can also be added as submodules for a synchronized Github repository. The only inconvenience I see is the need to add two files with lists of submodules and subrepositories. But this adds the ability to mantain them separately from the main code. What do you think?

Just out of curiosity, have you considered moving Roundup development entirely to git? This could attract more developers to contribute to the project.

> It may be the case that changes in Roundup require changes to your
> tracker template to work with the newest unreleased Roundup. We would
> need to document these in upgrading.txt and figure out when they can
> get published in your repo if they are not compatible with earlier
> roundup releases.

It might be easier to mantain separate template repositories in a single Github organization. Unfortunately, I don't know how this can be organized on SourceForge.

> I don't want to end up with separate customizing_with_tal and
> customizing_with_jinja docs. That pretty much guarantees that one or
> the other will be unmaintained.

I'm guessing most new installations will use Jinja, I've seen almost no other templating engines used in the Python world at the moment. But I agree, it's more convenient to have examples for both engines in one place.

Also, one more question: have you considered mirroring the Roundup documentation on readthedocs?

I'm glad you liked my proposal to provide Jinja-based Classic/Devel templates in addition to TAL-based templates.

But another problem arises: Roundup currently provides a template based on the classic schema called jinja2. Should we instead provide something like a symlink to jinja2-classic in the next release?