Created on 2020-11-22 15:15 by ced, last changed 2021-06-29 02:47 by rouilj.
|intra-word-emphasis.patch||ced, 2020-11-22 15:15|
|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 extra on markdown2 to ensure the same result in each implementation.  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 <firstname.lastname@example.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).
messages: + msg7294
|2021-05-06 19:16:06||rouilj||set||keywords: + Blocker|
|2021-03-10 15:13:29||rouilj||set||messages: + msg7093|
|2021-03-10 15:02:02||ced||set||messages: + msg7092|
|2021-03-10 14:51:45||rouilj||set||messages: + msg7091|
|2021-03-10 08:20:16||ced||set||messages: + msg7089|
|2021-03-10 02:43:48||rouilj||set||messages: + msg7088|
messages: + msg7036