Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 15 13:38
    yetipowers edited #374
  • Jan 15 13:38
    yetipowers edited #374
  • Jan 15 13:31
    yetipowers opened #374
  • Jan 05 19:50
    alerque labeled #422
  • Jan 05 19:50
    alerque commented #422
  • Jan 05 14:33
    wow-yes opened #422
  • Jan 05 14:05
    wow-yes edited #373
  • Jan 05 14:02
    wow-yes opened #373
  • Dec 21 2021 22:26
    rhaynes74 opened #421
  • Dec 18 2021 11:08
    alerque commented #420
  • Dec 18 2021 05:21
    Zeioth opened #420
  • Nov 20 2021 19:24
    jolars commented #384
  • Nov 05 2021 07:53
    atanasj edited #371
  • Nov 03 2021 11:02
    atanasj opened #372
  • Nov 02 2021 10:21
    atanasj edited #371
  • Oct 28 2021 17:40
    tbnorth commented #339
  • Oct 24 2021 18:42
    Konfekt edited #419
  • Oct 24 2021 18:41
    Konfekt opened #419
  • Oct 21 2021 12:32
    atanasj opened #371
  • Oct 20 2021 08:48
    abudden opened #370
Thomas Reuß
@treuss
@fmoralesc That would be the kind of solution I was hoping for. Nevertheless I havent found a way to make vim-pandoc to pass the current file's name to pandoc's -o as a parameter.
Timothy Brown
@keyofnight
Hey folks. I'm having trouble with let g:pandoc#formatting#mode = 'hA'
When I edit a paragraph and undo it the change... it takes a long time.
and when the undo finishes, it says, "XXX changes; before #1"
Where XXX is some large number that scales with how long the edit was.
Timothy Brown
@keyofnight
When I disable the folding module... things go back to normal.
Seth Bromberger
@sbromberger
Hi all. Could someone step me through creating markdown tables with vim-pandoc / vim-pandoc-syntax ? I've tried copying the examples from the screenshots but they don't render properly (columns aren't aligned, etc.)
Thibault Vatter
@tvatter
Hi, in the keyboard mapping section of the docs, I can't seem to find anything the refold an unfolded document. Is there a simple way to do that?
Zachary Yedidia
@zyedidia
Is there an option to disable the WYSIWYG features? Particularly in math mode.
Caleb Maclennan
@alerque
@zyedidia Almost everything can be turned off individually, see :help vim-pandoc-settings for details of all the settings you can override. What did you have in mind specifically?
shemot
@h8ed
When using the vim-pandoc plugin, it doesn't respect my movement key mappings (I've mapped h j k l to j k l ;). How can I go above fixing this? For some reason j and k want to revert to default vim mappings but l and ; work just as I personally mapped them..
basically making editing markdown files or other files that pandoc is enabled on, well, unusable
Caleb Maclennan
@alerque
When you remapped your movement keys did you use :nmap or :nnoremap? And what exactly did you map them to?
shemot
@h8ed
neither, I used :noremap so that it works for all modes besides insert, and so its not recursive
and, basically I did this: j/J -> h/H, k/K -> j/J, l/L -> k/K, ;/: -> l/L
also made h -> : and H -> ; so im not missing any mappings
shemot
@h8ed
https://i.imgur.com/9o8BzZO.png these are the relevant lines in my config
Caleb Maclennan
@alerque
I'm not sure. I'd suggest going ahead and opening up an issue for this, vim-pandoc shouldn't be tampering with those bindings at all, nor should it be assuming anything about them.
shemot
@h8ed
just tried manually doing all :nnoremap :vnoremap :onoremap and :snoremap and still same bug (not too surprising as that should be no different than doing :noremap) - will be opening up and issue as you suggested
Caleb Maclennan
@alerque
Nice issue report, thanks. There is enough info in there it's starting to make sense what's happening.
Not to discourage you, but this plugin isn't the only one you're going to have a hard time with, a lot of things assume those basic motion keys. I tried remapping them when I switched from QWERTY to DVORAK and gave up after a couple months, it was easier to relearn the muscle memory than fix all the plugins that didn't work as expected. That's not to say we can't fix this plugin for you –we should do that– just a heads up that you'll run into this again.
Caleb Maclennan
@alerque
@h8ed I think I found a solution for you. I edited it into my comment on #299.
bsdshell
@bsdshell
anyone know how to use external library to convert latex to html using Pandoc?
"external library" I mean I define some Latex commands in other file with
pandoc --mathjax myTexFile.tex -f latex -t html -s -o myHtmlFile.html
I use above command to convert Latex to Html
myTextFile.tex has some defined commands from other file. e.g. mylib.tex
robin
@f1refly_gitlab
I don't get syntax highlighting for inline LaTeX in my pandoc markdown (filetype is recognized as pandoc), do I have to enable that somewhere? I didn't find anything regarding it in the plugin settings
Caleb Maclennan
@alerque
@fmoralesc What Distro & build of Neovim are you using and what version of Lua is it compiled against? :version should say.
Felipe Morales
@fmoralesc
@caleb I'm following your additions to the lua module with great interest ;)
Caleb Maclennan
@alerque
I have it returning a Lua table with tag names and ranges. But I have an infant in hand right now too...
If you can figure out how to pass the current buffer in Lua and describe the exact output you want back, this won't be hard to wire up.
Felipe Morales
@fmoralesc
I will look into it
Caleb Maclennan
@alerque
{ start byte, end byte, tag name } is the info I have so far, do we need more than that? Pass whether the tag is blockwise or inline? Have two functions, one to get a block tag map and a second to get inlines?
Felipe Morales
@fmoralesc
That is absolutely all we need, and probably we should try with the current scheme before anything else. The problem we have to solve now is how to use this data. There is no way to add multiline highlights in the nvim API, so we should try with pushing region definitions (for this we have to calculate line and row of the start and end of regions). If so, we can give a uniform procedure to apply the highlighting.
Another problem will be to decide when to trigger the drawing. If this turns out to be as fast as we seem to expect, maybe we can get away with reapplying the syntax on every document change. If not, we will have to be a bit more clever (then it might be useful to distinguish between block and inline elements).
Caleb Maclennan
@alerque
It's probably worth calculating the line and column numbers on the Rust side. It's going to be an order of magnitude faster I think. But before we start optimizing that some basic proof of concepts are probably in order.
I'm guessing we'll have two refresh loops, one for the block under the cursor that only recalcs inline elements, and one for the whole buffer to find blocks.
Felipe Morales
@fmoralesc
I would imagine piggybacking on vim's line and column calculations is less expensive than doing it on the rust side (vim should have the buffer in memory already).
Caleb Maclennan
@alerque
vps = require("libvim_pandoc_syntax")
offsets = vps.get_offsets(vim.api.nvim_get_current_buf())
for i, event in ipairs(offsets) do
    print(event.tag, event.start)
end
That can be run from viml wrapped in lua << EOF .... EOF.
See just pushed commits.
AFK
Felipe Morales
@fmoralesc
@alerque I also made some progress on the python side, actually managed to get some highlighting working. passing data to python from rust was not fun, eventually i cheated and decided to pass lists of strings instead of something more natural. it looks like the lua api is simpler to manage.
regarding the highlighting itself, there is no support for multiline things at all, so that should be emulated somehow.
Caleb Maclennan
@alerque
Were you using pyo3 or something else? It looks lik it could pass data a similar way.
Felipe Morales
@fmoralesc
Using pyo3. I'm just not used to type systems, so I just went for the quickest hack. Ideally, I would be able to pass a dictionary like {1: ((start, end), tag)}, but that means I need to build a heterogeneous vec!, and I didn't understand how that works.
Caleb Maclennan
@alerque
I don't think Vec is what you want. You probably want a struct for the data we're goung to pass, then a trait to convert it to the right Python data type on the way out. The Lua one needs something like that too actually. What I have is a quick hack to stuff the Lua output table directly but I should have used a Struct with a conversion trait.
In fact with the right struct in place and type coercing either/both Python & Lua interfaces should be able to work from the same Rust code.
Felipe Morales
@fmoralesc
That makes sense.
I really need to learn more about how rust works, as I mentioned before I had never coded in it.