gabrielelana / vim-markdown

Markdown for Vim: a complete environment to create Markdown files with a syntax highlight that doesn't suck!
MIT License
740 stars 59 forks source link

Indentation settings not consistent with, e.g., pandoc #41

Closed MatthiasKauer closed 8 years ago

MatthiasKauer commented 8 years ago

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.

setlocal ts=2 sw=2 expandtab smarttab

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

ibabushkin commented 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.

gabrielelana commented 8 years ago

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 2s with 4s

MatthiasKauer commented 8 years ago

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?

ibabushkin commented 8 years ago

@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.

gabrielelana commented 8 years ago

@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

MatthiasKauer commented 8 years ago

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.