Roundup Tracker - Issues

Issue 2551105

classification
Title: Markdown2 emphasis intra-word
Type: behavior Severity: normal
Components: Web interface Versions: 2.0.0
process
Status: new Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ced, rouilj
Priority: Keywords: patch

Created on 2020-11-22 15:15 by ced, last changed 2021-06-29 02:47 by rouilj.

Files
File name Uploaded Description Edit Remove
intra-word-emphasis.patch ced, 2020-11-22 15:15
Messages
msg7035 Author: [hidden] (ced) Date: 2020-11-22 15:15
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
msg7036 Author: [hidden] (rouilj) Date: 2020-11-22 20:29
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?
msg7088 Author: [hidden] (rouilj) Date: 2021-03-10 02:43
Ping Cedric, any feedback on my last update?
msg7089 Author: [hidden] (ced) Date: 2021-03-10 08:20
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.
msg7091 Author: [hidden] (rouilj) Date: 2021-03-10 14:51
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?
msg7092 Author: [hidden] (ced) Date: 2021-03-10 15:02
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.
msg7093 Author: [hidden] (rouilj) Date: 2021-03-10 15:13
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.
msg7294 Author: [hidden] (rouilj) Date: 2021-06-29 02:47
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).
History
Date User Action Args
2021-06-29 02:47:25rouiljsetkeywords: - Blocker
messages: + msg7294
2021-05-06 19:16:06rouiljsetkeywords: + Blocker
2021-03-10 15:13:29rouiljsetmessages: + msg7093
2021-03-10 15:02:02cedsetmessages: + msg7092
2021-03-10 14:51:45rouiljsetmessages: + msg7091
2021-03-10 08:20:16cedsetmessages: + msg7089
2021-03-10 02:43:48rouiljsetmessages: + msg7088
2020-11-22 20:29:36rouiljsetnosy: + rouilj
messages: + msg7036
2020-11-22 15:15:31cedcreate