Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible incompatibility with the Markdown plugin #21

Open
Grahack opened this issue Jan 4, 2015 · 5 comments
Open

Possible incompatibility with the Markdown plugin #21

Grahack opened this issue Jan 4, 2015 · 5 comments

Comments

@Grahack
Copy link

Grahack commented Jan 4, 2015

Hi,
I use this markdown plugin on my DW instance and wanted to try your MathJax plugin.
There seem to be a problem with underscores. I do not claim that this is a bug in your plugin, but ask for some help!

I already tried to tweak the getSort value with no luck. I'm not strong enough in DW internals to fully understand the problem. The markdown plugin has 20+ files with different getSort values, ranging from 8 to 219.
If I understand correctly, getType returning protected should prevent this very problem.

You can try yourself to tweak a page where both are installed:
http://galerie.microalg.info/profgra:tests:mathjax

markdowku/syntax/italicunderline.php:14:    function getSort()  { return 79; }
markdowku/syntax/anchorsinline.php:14:    function getSort()  { return 102; }
markdowku/syntax/codespans4.php:14:    function getSort()  { return 96; }
markdowku/syntax/anchorsreference.php:18:    function getSort()  { return 102; }
markdowku/syntax/references.php:15:    function getSort()  { return 100; }
markdowku/syntax/olists.php:15:    function getSort()  { return 09; }
markdowku/syntax/imagesreference.php:18:    function getSort()  { return 102; }
markdowku/syntax/escapespecialchars.php:16:    function getSort()  { return 61; }
markdowku/syntax/imagesinline.php:14:    function getSort()  { return 101; }
markdowku/syntax/linebreak.php:14:    function getSort()  { return 139; }
markdowku/syntax/blockquotes.php:12:    function getSort()  { return 219; }
markdowku/syntax/ulists.php:15:    function getSort()  { return 09; }
markdowku/syntax/codespans2.php:14:    function getSort()  { return 98; }
markdowku/syntax/codespans1.php:14:    function getSort()    { return 99; }
markdowku/syntax/boldasterisk.php:14:    function getSort()  { return 69; }
markdowku/syntax/autolinks.php:14:    function getSort()  { return 102; }
markdowku/syntax/hr.php:17:    function getSort()  { return 08; } /* Before list block parsing. */
markdowku/syntax/headeratx.php:14:    function getSort()  { return 49; }
markdowku/syntax/codeblocks.php:14:    function getSort()  { return 199; }
markdowku/syntax/codespans5.php:14:    function getSort()  { return 95; }
markdowku/syntax/githubcodeblocks.php:19:    function getSort()  { return 91; }
markdowku/syntax/italicasterisk.php:14:    function getSort()  { return 79; }
markdowku/syntax/headersetext.php:16:    function getSort()  { return 49; }
markdowku/syntax/codespans3.php:14:    function getSort()  { return 97; }
@liffiton
Copy link
Owner

liffiton commented Jan 5, 2015

I'm afraid I'm not familiar enough with the dokuwiki internals either, and I'm not sure what's going on there. Your understanding matches mine, but clearly we're missing something. You could try to change the return value of getType in the mathjax plugin from protected to disabled, and let me know if that helps. Unfortunately, I don't see any other issue given my limited understanding of dokuwiki's parsing.

@msakuta
Copy link

msakuta commented May 19, 2016

Same happened for me. In my case, changing return value of getType to 'formatting' magically solved the issue (changing to disabled didn't help).

First, this problem happens only if I use two or more underscores in math in a bulleted line. I guess this problem is caused by both italic style (surrounded by underscores) and unordered list (lines starting with a *).

For example, * $x_0$ is okay, but * $x_0, y_0$ has the problem.

Another speculation of mine is that the meaning of getType's return value is that, in which types of parser modes this plugin should be accepted, rather than which types of modes this plugin wants to accept.

So, this is probably what's happening:

  1. First, markdowku's ulists syntax plugin finds a line of text beginning with an asterisk *.
  2. ulists enters the mode plugin_markdowku_ulists which do not accept protected modes. (see /plugins/markdowku/syntax/ulists.php)
  3. Since syntax_plugin_mathjax_protecttex.getType() returns protected, MathJax protection is not invoked.
  4. markdowku's italicunderline syntax is invoked, which destroys the LaTex markups.

The return value of getSort doesn't matter because unordered list container (between * and \n) is larger than the math, so the unordered list is always processed first.
The problem is that markdowku overrides both underscores and unordered lists, which makes the situation complicated and hard to debug.

Considering the true purpose, I think syntax_plugin_mathjax_protecttex.getType() should return formatting, but I'm not sure if it has any negative side-effects. I love both plugins (I use lots of maths in my DokuWiki), so I wish this issue to have been fixed.

@Grahack
Copy link
Author

Grahack commented May 19, 2016

The formatting trick did it for me too. Thanks.
I leave this issue open until the code is updated and/or the trick tripled checked.
Cheers.

@liffiton
Copy link
Owner

Thanks for digging into this and figuring it out. From the syntax plugin documentation and its base code, it looks to me like getType() should return the parser mode that the plugin is. And of the types available, protected seems the most appropriate for this plugin. Isn't the proper fix then for markdowku's ulists module to add protected to its list of allowed types?

Protected blocks (like <file>) can be placed in list items in plain Dokuwiki syntax, anyway, so I don't see a problem with allowing the protected type in ulists. If I understand correctly, markdowku doesn't allow for <file> blocks, etc. to be placed in unordered lists -- while Dokuwiki itself does -- which would also seem to be an issue.

I see no negative side-effects of your fix myself, but I want to find the most appropriate fix for this. I think that fix is to add 'protected' to the allowed types in markdowku's ulists. Does that sound right to you? If so, we can report it to markdowku's author.

@msakuta
Copy link

msakuta commented May 20, 2016

Yes, adding protected to the return value of syntax_plugin_markdowku_ulists's getAllowedTypes method like below also fixed the problem.

    function getAllowedTypes() {
        return array('formatting', 'substition', 'paragraphs', 'baseonly', 'container', 'protected');
    }

I also checked the source of standard DokuWiki syntax for unordered lists. Like you said, the standard syntax accepts protected, although I have no idea what #XXX new means in the source comment.

dokuwiki/inc/parser/parser.php (462):

class Doku_Parser_Mode_listblock extends Doku_Parser_Mode {

    function Doku_Parser_Mode_listblock() {
        global $PARSER_MODES;

        $this->allowedModes = array_merge (
                $PARSER_MODES['formatting'],
                $PARSER_MODES['substition'],
                $PARSER_MODES['disabled'],
                $PARSER_MODES['protected'] #XXX new
            );

    //    $this->allowedModes[] = 'footnote';
    }

I'm still not sure which plugin should be fixed. I agree that MathJax markup should not include any other DokuWiki syntax, but it's determined solely by MathJax plugin's getAllowedTypes (which returns empty array, derived from DokuWiki_Syntax_Plugin class), not by the return value of getType. getType affects only the other syntaxes which may contain a MathJax markup. I mean, it feels more like a formatting syntax from other plugins' perspective.

That said, I'm inclined to fixing markdowku side, because it's at least not consistent with standard syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants