Autoformatting aggressively reformats lists

[jez]

With the following setting on:

let g:pandoc#formatting#mode = 'hA'

If you try to type in a list, it will "reformat" the list into one line, effectively turning it into one item. For example, try to type the following into a fresh buffer:

- line one
- line two

You'll see that it ends up as

- line one - line two

[fmoralesc]

Yes, this is a known issue. I don't have much time to fix it atm, but vim-pandoc needs to plug into the code that detects if the cursor is inside a list or not (see autoload/markdown/lists.vim).

[jokogr]

Is there any workaround for this? I like too much hard wraps and smart autoformatting to change the formatting mode :)

[fmoralesc]

I was just testing this, but I can't reproduce. Are you using vim-pandoc-syntax instead of the normal markdown syntax? If not, then that might be the cause of the issue: vim-pandoc actually disables autoformatting for list items, but that depends on the highlighing being recognized.

[jez]

Are you sure you're using

let g:pandoc#formatting#mode = 'hA'

vs

let g:pandoc#formatting#mode = 'ha'

I just tried it both ways and I was definitely only able to reproduce it on the former.

[fmoralesc]

I can't reproduce it in neither mode (and I always use 'hA', since it's so awesome).

[jez]

Curious. I can't think of another plugin that might be interfering, but I'll see if I can't make a reproducible Vim setup (as a zip file or something).

[jez]

Oops

[jokogr]

These are the plugins I'm using (everything is up-to-date):

Plug 'w0ng/vim-hybrid'
Plug 'bling/vim-airline'
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': 'yes \| ./install --bin' }
Plug 'junegunn/fzf.vim'
Plug 'ervandew/supertab'
Plug 'tpope/vim-commentary'
Plug 'LaTeX-Box-Team/LaTeX-Box'
Plug 'mileszs/ack.vim'
Plug 'tpope/vim-surround'
Plug 'tpope/vim-repeat'
Plug 'vim-pandoc/vim-pandoc'
Plug 'vim-pandoc/vim-pandoc-after'
Plug 'vim-pandoc/vim-pandoc-syntax'
Plug 'junegunn/goyo.vim'

and the settings related to pandoc-vim:

let g:pandoc#after#modules#enabled = ["supertab"]
let g:pandoc#formatting#mode = "hA"

Maybe vim-pandoc-after or supertab is interfering?

[mcjohnalds]

I had the same issue, but realised I had vim-pencil enabled with

Plug 'reedes/vim-pencil'
augroup pencil
    autocmd!
    autocmd FileType markdown,mkd call pencil#init()
    autocmd FileType text         call pencil#init()
augroup END

Which was causing the issue.

[a3lem]

So, has anyone found a fix for this yet?

I've noticed that this behavior is only encountered when staying in Insert Mode, that is, pressing <enter> or <ctrl-j> at the end of the first list item to open a new line below.

- this is my first item [ `<ctrl-j/enter>` start typing] - arghhhhhhh

Re-entering Normal Mode at the end of the first list item and using o to open a line below, I'm able to avoid the problem.

Of course, when I'm taking trying to take notes, e.g., in a lecture, that's a relatively slow way to go about adding list items.

Incidentally, is there a way to disable autoformatting entirely, except perhaps for hard wrapping at line ends? Given some of the unpredictable behavior of pandoc's _auto_formatting, I'd presently much prefer a good old muscle-memorized gqap for everything else

[jez]

Incidentally, is there a way to disable autoformatting entirely, except perhaps for hard wrapping at line ends? Given some of the unpredictable behavior of pandoc's autoformatting, I'd presently much prefer a good old muscle-memorized gqap for everything else

You can just use

:set textwidth=72

If you want lines to hard wrap at 72 characters. Of course, adjust this to your pleasure.

You may also be interested in this setting

:set colorcolumn=+0

Which draws a color column. Using this +N notation, the color column is drawn at column textwidth + N (which is textwidth when N is 0).

[a3lem]

Thanks for the colorcolumn tip!

In the end, I decided to bite the bullet and just disable all autoformatting.

let g:pandoc_autoformat_enabled = 0 didn't seem to do anything, though, so I additionally removed the A-option from let g:pandoc#formatting#mode='hA'. For 'context-aware' formatting I'll simply have to use the equalprg functionality (run the file through Pandoc). Sad day, of course: would much prefer to just use the smart autoformatting features, which, aside from a few kinks here and there (list formatting (i.e., the issue here), verbatim code block randomness, and some other niggling idiosyncrasies), are really nice to have, actually. As soon as those get ironed out, I'll probably be enabling it again. 👍

[thriveth]

I can report having the same problem, and it is not only in lists. It also happens when making Setext-style headers (here I have to make a double line break, then make the ='s or -'s, then delete the extra empty line), and in definition lists (haven't found a workaround for these yet, leaving for Normal mode and then pressing o does not cut it here).

[thor]

Does anyone know of similar projects where this is fixed, or of approaches or places to start to try to fix it in an ideal world?

[fmoralesc]

The problem stems from the way the structure of the document is detected. Lists are somewhat problematic because we have to look ahead and behind to capture enough context to make decisions, and the current implementation is not optimal (obviously).

Ideally (and I don't currently have time to implement this), I would try to outsource this to the pandoc parser. If the plugin was asynchronous, I think a way to do it would be to send the current paragraph to pandoc and check what the result of parsing that is. pandoc's parse tree is not ideal for all our purposes (it eats information about source lines), but it could work.

[jez]

You can try setting up prettier through ALE to run on save as a fixer for markdown and pandoc filetypes. Prettier now has a Markdown autoformatter that uses common mark, so it parses that same way pandoc does, generally.

On Thu, Jun 7, 2018 at 6:38 AM Felipe Morales [email protected] wrote:

The problem stems from the way the structure of the document is detected. Lists are somewhat problematic because we have to look ahead and behind to capture enough context to make decisions, and the current implementation is not optimal (obviously).

Ideally (and I don't currently have time to implement this), I would try to outsource this to the pandoc parser. If the plugin was asynchronous, I think a way to do it would be to send the current paragraph to pandoc and check what the result of parsing that is. pandoc's parse tree is not ideal for all our purposes (it eats information about source lines), but it could work.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/vim-pandoc/vim-pandoc/issues/147#issuecomment-395423425, or mute the thread https://github.com/notifications/unsubscribe-auth/AFSaVHCWd0AW9EelwqZSRJaULyLjjjTwks5t6SzzgaJpZM4F9TT1 .