Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 20 14:05
    carldelfin opened #417
  • Sep 11 11:00
    Konfekt closed #415
  • Sep 11 11:00
    Konfekt commented #415
  • Sep 07 19:24

    fmoralesc on master

    python/helpparser: fix version … (compare)

  • Sep 07 19:24
    fmoralesc closed #332
  • Sep 06 14:01
    Konfekt edited #415
  • Sep 06 13:40
    Konfekt opened #416
  • Sep 06 13:37
    Konfekt opened #415
  • Sep 06 13:23
    Konfekt commented #332
  • Sep 06 10:58
    user202729 commented #366
  • Sep 06 10:56
    user202729 commented #366
  • Sep 05 14:19
    lyndhurst commented #368
  • Sep 05 01:37
    user202729 opened #369
  • Sep 05 01:36
    user202729 commented #367
  • Sep 04 00:28
    user202729 commented #363
  • Sep 04 00:23
    user202729 commented #368
  • Sep 03 17:41
    elshize closed #347
  • Sep 03 17:41
    elshize commented #347
  • Sep 03 14:04
    fmoralesc commented #368
  • Sep 03 08:54
    lyndhurst opened #368
Caleb Maclennan
@alerque
Hey what do you think about the idea of actually splitting this off as a different plugin? I don't see how pulldown-cmark is going to support all of Pandoc's extentions any time soon which means we could only merge this work as some sort of alternate reality to the default Pandoc mode until we get our hands on commonmark-hs or similar. I'm actually really hopefull the latter will happen soon and/or we can directly wire into it in a similar way. I see the need for a strict CommonMark syntax variant, and maybe the GFM mode too, both of which pulldown-cmark works for now. We could reuse all/part of the design or make it a dependency if there is anything we can gain now.
I'm not sure on this, just brain-storming. Trying to convince myself maybe ;-)
Caleb Maclennan
@alerque
...I actually headed down that road in a new repo. I'm open to redirection though, I'm not super confident an independent plugin is the right approach, but it seemed like the most likely way to get something usable out there without getting blocked on Pandoc extension support.
Felipe Morales
@fmoralesc
That sounds fine to me ;) I was thinking we could split the rust library from the plugin.
Caleb Maclennan
@alerque
I thought about that, but I think it would make more sense if we were using it as an RPC end-point. Right now it's pretty closely tied to what we want to call through the vim interface code.
I may have another use for a Lua library wrapping pulldown-cmark so that might make sense ultimately, but I'm not sure yet where to draw the boundary between the various API levels. Since pulldown-cmark already is an idiomatic Rust interface, I'm not sure a 100% Lua wrapper around that is an improvement over a customized wrapper that does exactly what the Lua endpoint needs.
Felipe Morales
@fmoralesc
Sure.
Perhaps one idea for vim-pandoc-syntax could be to use this as a base and override the highlighting for unrecognized block types in some way. For example, I make use of yaml blocks, and this breaks them.
Caleb Maclennan
@alerque
I could see that working.
Felipe Morales
@fmoralesc
I'm digging in ;)
Caleb Maclennan
@alerque
I'm still at the point of rebasing master as I wire stuff together, but it's working on Arch/Neovim using a vim-plug install + make ;-)
Felipe Morales
@fmoralesc
I'm trying out seeing what happens if I install it through vim-plug with :Plug alerque/vim-commonmark {'do': 'make'}
It works. But oh the colors~ :p
Caleb Maclennan
@alerque
I imported your Python code too because I have an idea we might need to go down the Python road after all if we want this to support Vim8. I looked at the VIM8 Lua interface and it just doesn't have an API that works the same way.
It might still work, but it would require some rewiring. There is no vim.api, only a bunch of piecemeal hooks via vim.window, vim.buffer, etc.

It works. But oh the colors~ :p

Ay, it's ugly an dirt. I was mostly worried about checking what it was or wasn't matching, not in making it look good.

Felipe Morales
@fmoralesc
My python was constructed around neovim's remote plugin architecture, though, I don't know if vim8 offers something similar. One advantage it might have over the lua version is that it runs in a separate process.

It works. But oh the colors~ :p

Ay, it's ugly an dirt. I was mostly worried about checking what it was or wasn't matching, not in making it look good.

I understand. But it's in a public repo now, so maybe it's a good idea to provide some 'release' defaults ;)

Caleb Maclennan
@alerque
Yup yup.
Caleb Maclennan
@alerque
So @fmoralesc you are probably interested in this comment and this AUR package I just setup (precompiled package in my repo).
Some preliminary testing suggests commonmark-cli doing syntax coloring runs about 2× orders of magnitude slower than pulldown-cmark doing an HTML render. So that's not good. On the plus side it does cover all or most of the Pandoc flavor syntax! If we work out how to background the job of parsing and only block during updates to a limited portion of the buffer at a time we can probably make it work.
I figured out how to get Haskell→Lua bindings but not Lua→Haskell yet. We probably want to go down the RPC path for this.
I still want to finish off a working vim-commonmark using the Rust parser, but the lessons learned will be directly applicable to wiring in a different backend.
Felipe Morales
@fmoralesc
@alerque :+1: sounds good to me
ivanvgav
@ivanvgav
Hello, i'm trying to setting up vim-pandoc around vimwiki and a zettelkasten system. I would like to have the autocompletion feature from vim-pandoc but i can't make it works. I'm on nvim
My settings are: " Pandoc
let g:vimwiki_filetypes = ['pandoc', 'markdown', 'textile']
let g:vimwiki_folding = 'custom'
let g:pandoc#folding#fdc = 0
let g:pandoc#folding#level = 999
let g:pandoc#folding#mode = 'stacked'
let g:pandoc#modules#enabled = ['folding', 'command']
let g:pandoc#biblio#sources = 'gy'
let g:pandoc#biblio#use_bibtool = 1
let g:pandoc#completion#bib#mode = 'citeproc'
let g:pandoc#biblio#bibs = ["Documents/biblio.bib"]
" Pandoc Autocomplete
augroup my_cm_setup
autocmd!
autocmd BufEnter * call ncm2#enable_for_buffer()
autocmd Filetype pandoc call ncm2#register_source({
\ 'name': 'pandoc',
\ 'priority': 8,
\ 'scope': ['pandoc'],
\ 'mark': 'md',
\ 'word_pattern': '\w+',
\ 'complete_pattern': ['@'],
\ 'on_complete': ['ncm2#on_complete#omni', 'pandoc#completion#Complete'],
\ })
augroup END
Domenico Ipri
@emeralit_gitlab
Hi,
please see issue #377
ivanvgav
@ivanvgav
Thanks I'll check it
RhymeJob
@RhymeJob
Hi, I'm wondering where the documentation for vim-pandoc is supposed to be. I've looked through the git repository and haven't found anything, and general web searches don't give me anything either.
Caleb Maclennan
@alerque
@RhymeJob It's documented using VIM's internal help system. Use :help vim-pandoc to get there.
If you're poking around the git repo without the plugin installed the sources for it are in the docs directory.
robertdg
@robertdg:matrix.org
[m]
I usually process my .md documents to pdf via groff ms (mainly because I don't have TeX installed on my laptops). So, for example, I would issue a command like: "pandoc -t ms -o test.pdf test.md". But when I try and issue a command like that via :Pandoc, it tries to process to pdf via html, and complains about missing utilities. Can I tell vim-pandoc to process to pdf via groff ms? And can I change the vim-pandoc compile to pdf command so that it always uses that route?
Caleb Maclennan
@alerque
@tami5 Just pinging so you know about this channel we sometimes talk Vim/Pandoc dev stuff in.
tami5
@tami5
Hey @alerque thanks for the invite. That would be really helpful, I was meaning to ask you if WithConcealin vim-pandoc-syntax, might be causing performance drawbacks. I'm copying the same pattern-ish right now
tami5
@tami5
I also wonder why some calls has almost identical parameters getting called for the same group. like bellow the only difference is in the end
start=/\\\@1<!\(\_^\|\s\|[[:punct:]]\)\@<=\*\S\@=/ skip=/\(\*\*\|__\)/ 
start=/\\\@1<!\(\_^\|\s\|[[:punct:]]\)\@<=_\S\@=/ skip=/\(\*\*\|__\)/ 

end=/\*\([[:punct:]]\|\s\|\_$\)\@=/ 
end=/\S\@1<=_\([[:punct:]]\|\s\|\_$\)\@=/
call s:WithConceal('block', 'syn region mdEmphasis matchgroup=mdOperator start=/\\\@1<!\(\_^\|\s\|[[:punct:]]\)\@<=\*\S\@=/ skip=/\(\*\*\|__\)/ end=/\*\([[:punct:]]\|\s\|\_$\)\@=/ contains=@Spell,mdNoFormattedInEmphasis,mdLatexInlineMath,mdAmpersandEscape', 'concealends')
call s:WithConceal('block', 'syn region mdEmphasis matchgroup=mdOperator start=/\\\@1<!\(\_^\|\s\|[[:punct:]]\)\@<=_\S\@=/ skip=/\(\*\*\|__\)/ end=/\S\@1<=_\([[:punct:]]\|\s\|\_$\)\@=/ contains=@Spell,mdNoFormattedInEmphasis,mdLatexInlineMath,mdAmpersandEscape', 'concealends')
foersben
@foersben

Greetings folks,
I do not manage to get any syntax highlighting for my markdown file:

The content is pretty plain: ('Test.md')

Test

asdfasdf

Test 2

Test 3

My vimrc looks as follows:
https://pastebin.com/dR69vAib

Maybe you can give me a hint? Syntax highlighting for everything else works fine, the .md file is recognised as markdown filetype

foersben
@foersben

adding those two lines:
let g:pandoc#filetypes#handled = ["pandoc", "markdown"]
let g:pandoc#filetypes#pandoc_markdown = 0

gave me conceal results but I still have no highlighting when using filetype pandoc or markdown