incorrect highlighting when backslash preceding the ending backtick of inline literal.

[madjxatw]

With ``C:\``, the first ending backtick is escaped by the backslash, resulting in the subsequent text being highlighted as inline literal until meeting with a ``.

The RST specification states:

An unescaped backslash preceding a start-string or end-string will disable markup recognition, except for the end-string of inline literals.

Therefore, any backslash within inline literal should be regarded as a literal backslash.

[marshallward]

Good catch, I did not know about that rule. Some other issues with escape characters were recently fixed, hopefully it will not be too arduous to integrate this into the logic.

I don't know when I will have time to look at this, but the work will be in L92-110 of the syntax file.

[madjxatw]

Thanks for your reply! I am using the latest rst.vim from this repo, now the reference syntax (e.g. :ref:`xxx`) doesn't get highlighted as before. I am not sure this is my computer's problem or something is broken due to the fix for escape characters.

[marshallward]

I can't seem to find any issue with :ref:`xxx`, but I may have jumbled up my own configs here. I tested this with the repo and my system install (looks like 8.1, patch 2268). It might be better to open a separate ticket in this case, possibly with your syntax file, and maybe a screenshot if you can be bothered :).

[madjxatw]

I've confirmed that is not the syntax problem but my vim color scheme not highlighting :ref:`xxx`, it works after switching to another color theme. BTW I've opened another ticket about code block.

[madjxatw]

This issue seems to be introduced by https://github.com/marshallward/vim-restructuredtext/commit/f26f94415688efbea8aa33396373e33068eb2e48 fix for #39 . After switching back to an older version, the inline literal works fine. I will comment on #39, although it has been closed.

[marshallward]

Probably better to keep the discussion here, since those changes in #39 also needed to happen. I think the exception described here ought to be explicitly included into the rule.

[madjxatw]

OK, let's stay here talking the backslash issue.

f26f944 metioned in #39 breaks inline literal rendering. For C:\, the rstEscape.a:name syntax match eats up the first the backtick. I add an if statement to exclude the inline literal from rstEscape to make it temporarily work for me.

  if a:start != '``'
    execute 'syn match rstEscape'.a:name.' +\\\\\|\\'.first.'+'.' contained'
    execute 'syn region rst' . a:name .
        \ ' start=+' . a:char_left . '\zs' . a:start .
        \ '\ze[^[:space:]' . a:char_right . a:start[strlen(a:start) - 1] . ']+' .
        \ a:middle .
        \ ' end=+' . a:end . '\ze\%($\|\s\|[''"’)\]}>/:.,;!?\\-]\)+' .
        \ ' contains=rstEscape' . a:name
    execute 'hi def link rstEscape'.a:name.' Special'
  else
    execute 'syn region rst' . a:name .
        \ ' start=+' . a:char_left . '\zs' . a:start .
        \ '\ze[^[:space:]' . a:char_right . a:start[strlen(a:start) - 1] . ']+' .
        \ a:middle .
        \ ' end=+' . a:end . '\ze\%($\|\s\|[''"’)\]}>/:.,;!?\\-]\)+'
  endif

[marshallward]

I've just tried a somewhat similar implementation (if blocks around the rstEscape bits rather than replicating the block) which seems to work, so will try to get something like this in today.

[marshallward]

I've pushed a PR (88a3297) similar to your suggestion which disables inline literal escapes. It also addresses an issue with inline literals separated by spaces.

If it's working then I can close this issue.

[madjxatw]

Thank you for your fix, it is working now.