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

Highlight the content of fenced code blocks with specified language in that language. #93

Closed
wants to merge 5 commits into from

Conversation

citizenmatt
Copy link
Contributor

Based on the code from vim-notes, adds syntax highlighting for GFM code blocks. E.g.

```vim
let g:foo = 1
```

is shown as syntax highlighted with the vim syntax highlighting.

This introduces a plugin/mkd.vim file. Putting this code in ftplugin meant that it didn't refresh the syntax on BufReadPost.

As per contributing.md:

  • It can be tested with test\syntax.md, you'll see the ruby block is highlighted.
  • readme.md hasn't been updated, as it doesn't require any configuration

Code taken from https://github.com/xolox/vim-notes

Has to be in plugin/mkd.vim, or the initial BufReadPost event doesn’t
get fired. I don’t know why.
Avoids errors when including more than once, e.g. including vim twice
causes errors
@cirosantilli
Copy link
Collaborator

This is interesting. Does it work inside lists? :

- a

    ```vim
    let a = 0
    ```

@citizenmatt
Copy link
Contributor Author

It does now! 😄

@parshap
Copy link

parshap commented Jul 17, 2014

👍

1 similar comment
@Kazark
Copy link

Kazark commented Aug 11, 2014

👍

@cirosantilli cirosantilli changed the title Syntax highlighting for code blocks Syntax highlighting for fenced code blocks with specified language. Sep 7, 2014
@cirosantilli cirosantilli changed the title Syntax highlighting for fenced code blocks with specified language. Highlight the content of fenced code blocks with specified language in that language. Sep 7, 2014
@aschrab
Copy link

aschrab commented Sep 11, 2014

👍

This is awesome. Although it seems to get messed up when the file is reloaded such as with :e, but even then it's no worse than without this change.

@citizenmatt
Copy link
Contributor Author

Good spot. Reloading the buffer reset the syntax highlighting, but didn't reset the buffer variable cache of already applied syntaxes. Fixed!

@akiva
Copy link

akiva commented Sep 27, 2015

Is this ever getting merged in?

@lemonzi
Copy link

lemonzi commented Oct 16, 2015

I was thinking whether it's possible to get better syntax coloring inside long LaTeX equations. Maybe this could help by re-using whichever LaTeX syntax is available (?)

@shirosaki
Copy link
Collaborator

I've tested and syntax highlight in fenced code blocks works.
But current test suite fails.
The following code doesn't work as expected because we don't get mkdCode after the patch is applied.

https://github.com/plasticboy/vim-markdown/blob/master/indent/markdown.vim#L22
return synIDattr(synID(a:lnum, 1, 0), 'name') == 'mkdCode'

@shirosaki
Copy link
Collaborator

I am creating fixes based on this patch.
https://github.com/shirosaki/vim-markdown/commits/code-block-syntax

@shirosaki
Copy link
Collaborator

Merged.

@shirosaki shirosaki closed this Jan 13, 2016
@alexconst
Copy link
Contributor

@shirosaki and @citizenmatt

I noticed that syntax highlight is not working for bash code blocks.
It works for yaml, ruby, c, and possibly everything else, but not for bash.
Is it just me? Should I open a bug report?

Test case (unable to paste it here):
https://gist.github.com/alexconst/c50512cae8f2bef4c549

@citizenmatt
Copy link
Contributor Author

Try using sh as the language. It uses vim filetypes, rather than e.g. GitHub languages, so you'll have to use the vim filetype, which is sh.

```sh
mkdir foo
pwd
name="file.txt"
```

I did add a map into my local copy of this change, around this line, so you could add a map in your own .vimrc between the filetype you use in the markdown and the known vim filetype. That way, you can use GitHub languages.

@alexconst
Copy link
Contributor

@citizenmatt

you could add a map in your own .vimrc between the filetype you use in the markdown and the known vim filetype

How can I do that? I tried the following which didn't work:

augroup bash 
    au!
    au BufNewFile,BufRead *.sh,*.bash setlocal filetype=sh 
augroup END

It seems GFM (at least this comments here) support both sh and bash.
While Pandoc, which is what I'm using, does not (Pandoc actually depends on another library to do the highlight).

@shirosaki
Copy link
Collaborator

@alexconst
Mapping for language identifier and syntax file name is required as the following.

https://github.com/plasticboy/vim-markdown/blob/master/ftplugin/markdown.vim#L617

let s:filetype_dict = {
    \ 'c++': 'cpp',
    \ 'viml': 'vim',
    \ 'bash': 'sh'
\ }

@alexconst
Copy link
Contributor

@shirosaki any particular reason for the bash line not being included? Does it break anything?

(if nobody else wants to do it) can I submit a PR with this change?

shirosaki added a commit that referenced this pull request Jan 26, 2016
@shirosaki
Copy link
Collaborator

@alexconst No. Just I didn't need that. I fixed that.

@alexconst
Copy link
Contributor

Thanks!

@citizenmatt
Copy link
Contributor Author

I can't set s:filetype_dict from my .vimrc, can I? It'd be nice to be able to update the map with local mappings, rather than have to maintain it centrally.

@shirosaki
Copy link
Collaborator

I think you can't do that.
I agree local mapping would be nice. Can you submit a patch?

@citizenmatt
Copy link
Contributor Author

Can do. What do you think the behaviour should be - the global variable overriding the script-local one, or merging with it?

@shirosaki
Copy link
Collaborator

I think overriding script-local one is OK since I'm not sure default mapping is useful or not.
Setting like the following looks good to me from https://github.com/tpope/vim-markdown.
['c++=cpp', 'viml=vim', 'bash=sh']

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

Successfully merging this pull request may close these issues.

None yet

9 participants