When writing markdow like: 'self.this_long_attr'

markdown2 replaces the '_' by <em>
markdown does not replace
mistune does not replace
simplemde does not replace

So I think we should activate code-friendly[1] extra on markdown2 to ensure the same result in each implementation.

[1] https://github.com/trentm/python-markdown2/wiki/code-friendly

Unfortunately code-friendly looks like it may clobber _emphesis_
as well.

"The code-friendly extra disables the use of leading, trailing and --
most importantly-- intra-word emphasis (<em>) and strong (<strong>) 
using single or double underscores, respectively."

https://github.com/trentm/python-markdown2/issues/38

I wonder if we wouldn't be better served by exposing the python 
configuration arrays for markdown and have people perform 
overrides/settings using interface.py.

This would allow people to tune markdown as they want it without
core code changes. I am not quite sure how to structure this.

Analogs are: setting values in Cache_Control in class Client in
cgi/client.py, ability to override functions in the rest rate
limiting code (getRateLimit) etc.

Thoughts?

Ping Cedric, any feedback on my last update?

For me the main problem is to have the same rendering between the JS library and the server side library. Otherwise for the user it is not WYSIWYG. I do not think making it configurable will improve the situation.

Hi Cédric:

In message <1615364416.22.0.599309679296.issue2551105@roundup.psfhosted.org>,
=?utf-8?q?C=C3=A9dric_Krier?= writes:
>For me the main problem is to have the same rendering between the JS
>library and the server side library. Otherwise for the user it is not
>WYSIWYG. I do not think making it configurable will improve the
>situation.

Well in Markdown2, it's impossible to get it to match the JS
library. So the only alternative as I see it is to make it
configurable so that the admin can choose which incompatible features
s/he wants.

Do you have another alternative?

On 2021-03-10 14:51, John Rouillard wrote:
> Well in Markdown2, it's impossible to get it to match the JS
> library. So the only alternative as I see it is to make it
> configurable so that the admin can choose which incompatible features
> s/he wants.
> 
> Do you have another alternative?

Another way could be to let the JS library render also the posted
messages.

Hi Cédric:

In message <YEjfVM2KaELBTiP8@kei>,
=?utf-8?q?C=C3=A9dric_Krier?= writes:
>On 2021-03-10 14:51, John Rouillard wrote:
>> Well in Markdown2, it's impossible to get it to match the JS
>> library. So the only alternative as I see it is to make it
>> configurable so that the admin can choose which incompatible features
>> s/he wants.
>> 
>> Do you have another alternative?
>
>Another way could be to let the JS library render also the posted
>messages.

Also true.   Might be quite resource intensive on the device though.

AFAIK that can already be done without any back end changes though, so
nothing has to be done on this ticket to support that option. Unless
you are proposing we incorporate node into roundup to do the markdown
rendering serverside using the js library.

Removing this as a blocker for 2.1.0.

There doesn't appear to be a good answer here for markdown2.
Regardless of which way you configure it, you won't get parity.

I think the way forward here needs three things.

1) Properly set up config for markdown.

This includes a keyword in the [markdown] section (e.g. renderer) to
select the rendering engine: one of markdown, markdown or mistune.
This is similar to how indexing is configured (xapian, woosh,
native).

Per back end config settings. Either:

  markdown2_code_friendly=True/False
  
to enable/disable code friendly mode.

It may be possible to allow multiple settings depending on the
renderer list of strings as options, we can just pass the setting
along:

   markdown2_options = code-friendly, foo_bar_enable ....

If it accepts a dict of strings maybe:

   renderer1_options = key:value, key:value

can be processed as a new options_dict type.

IIRC at least one backend expects it's own objects and not strings for
customizing. Not sure how we handle that. May need specific flags for
each option we chose to support.

2) rewrite the code in cgi/templating.py to use the selection and options
   mechanism.

3) After handling the configuration, create a doc/markdown_use.txt file
to document markdown use and the [markdown] config items. Discuss
current issues with the different backends (search tracker for
markdown). It should discuss how the jinja template integrated
simplemde. It can include my example rest renderer as a
example (see msg6815 and surrounding msgs in issue2550856).

https://github.com/trentm/python-markdown2/issues/38

has been closed with this PR:

  https://github.com/trentm/python-markdown2/pull/522

It adds an extras=['middle-word-em'] setting that has to be disabled:

  extras=['middle-word-em'= False]

So adding extras = {'fenced-code-blocks': {}, 'nofollow': None, 'middle-word-em': False}

to disable the middle work emphasis to make 'self.this_long_attr' display with the
underscores and without emphasis.

This will only work in the upcomming 2.4.10 release. I will commit code that
adapts Roundup to different versions of markdown2 shortly.

Once that is committed PTC to add this for 2.4.10 welcome. I don't think a new [markdown]
option needs to be added to config.ini to enable/disable this option. I thin enabiling
it in all cases to make it operate like other cited markdown formatters is fine.

Oops bad job with my example code change:

Use:

  extras = {'fenced-code-blocks': {}, 'nofollow': None, 'code-friendly': True
            'middle-word-em': False }

plus a suitable test (see attached patch) I think will work.