Closed MatthiasKauer closed 8 years ago
I suppose you could overwrite that setting somewhere (though my knowledge of vim configuration is too limited to help you there), or use a workaround (as two-space indentation is more beautiful IMO). Essentially, while writing my own tool based on pandoc to process markdown files, I doubled the amount of leading spaces on each line. You could use a similar approach, or some similar functionality (along with some other options maybe) could be included here. That's my suggestion, not sure how @gabrielelana plans to handle that.
I realize I'm probably opening a can of worms here, but I'll ask anyway.
Sort of :-) you already spotted the real problem:
the highlighting of * also seems to be defined elsewhere
Yes, that's the real problem, the syntax requires two spaces, you could find the magic number 2
in the code (ex. here)
I think we could turn that number as a configurable variable or better, we could take that number from the configuration (ts
and sw
)
A pull request is welcome, let me know if you are up for it :smile: otherwise I'll do it
Meanwhile you can clone the repository and replace the 2
s with 4
s
Thanks for chiming in. I see this is a real conundrum :) I'm wondering if it'd be better to work with tabs instead of spaces; that would let users set the display width for those locally.
I'd be interested in contributing and have done a few things in vimL, but it's hard to see how large the rabbit hole is here. Can you give an estimate here?
@ibabushkin have you published your preprocessor somewhere?
@MatthiasKauer in fact, I have: morgue. However, it is supposed to be a standalone toolchain (along with a fork of this very repo here) and does a lot more.
As for the tabs question, I am not sure about it: Although the markdown specs mention tabs in multiple contexts (so it is safe to assume tabs are in fact legal), they might be a problem for users because of the very reason you stated: Further incompatibility with other tools and setups, which is an issue if you share your documents etc. For instance, I am not sure about pandoc's notion of things there, but it seems that it treats them as spaces: search for the word "tabs" here.
@MatthiasKauer @ibabushkin we could let the user choose but... the problem will be that, if the user uses expandtab
, the configuration of tabstop
, softtabstop
and shiftwith
must be compatibile with the syntax defined in this plugin
If you expand tabs to 4 spaces, then the list indentation in the syntax must consider 4 spaces as indentation. Note also that the syntax is loaded one time, if you change the configuration after it's not going to work. I don't see a clean solution for this that will make everyone happy :disappointed:
@MatthiasKauer I guess that the simplest thing to do for you is to use tabs in your local configuration ex. au FileType markdown setlocal ts=4 sw=4 noet
Let me know if this solves your issue
hmm, that's quite a conundrum indeed :/ I'm still leaning towards deactivating expandtab for markdown by force in the plugin. The last time I tried local (vimrc) settings were overwritten by the plugin (checked sw and ts, I believe). I guess I'll have to play with this a bit.
Hi, I realize I'm probably opening a can of worms here, but I'll ask anyway. I created a markdown document with your plugin and then converted it to docx or pdf with pandoc. So far so good, but the unordered lists I had did not respect all levels.
After a while I figured out that this has to do with different indentation expectations. I stumbled upon this discussion and example for various implementations.
This comes down to these lines in ftplugin as far as I can tell.
Given the "evidence" I have so far, I'd propose to change that to 4/4, but I'm wondering if you have other thoughts? Meanwhile: If I create my own ftplugin/markdown.vim, can I overwrite the settings from your plugin in that way? [edit: that didn't work; ts=2 still holds and the highlighting of * also seems to be defined elsewhere.]
Kind regards, Matthias