hard pencil mode deleting issue

[kevin4fly]

steps to reproduce the issue:

1. launch vim
2. copy the code snippet below into vim

function! ToggleGUICruft()
    if &guioptions=='i'
        exec('set guioptions=imTrL')
    else
        exec('set guioptions=i')
    endif
endfunction

3, vip= to format the code

4. run :HardPencil
5. yip to copy the code snippet and paste it to the blank space.
6. move the cursor the beginning of endfuntion and press <BS> key.

result:

function! ToggleGUICruft()
    if &guioptions=='i'
        exec('set guioptions=imTrL')
    else
        exec('set guioptions=i')
    endif
endfunction

function! ToggleGUICruft()
    if &guioptions=='i'
        exec('set guioptions=imTrL')
    else exec('set guioptions=i') endifendfunction

[reedes]

A few questions:

yip will copy the paragraph of 7 lines of the code snippet to the clipboard, but what command are you using to paste?

Are you in Insert mode when pressing <BS> key?

Also, what specific behavior are you expecting in this case?

Thanks.

[kevin4fly]

yip will copy the paragraph of 7 lines of the code snippet to the clipboard, but what command are you using to paste?

Go<CR><ESC>p go to the last line, insert mode line below, newline, normal mode, paste

Are you in Insert mode when pressing key?

yep

Also, what specific behavior are you expecting in this case?

actual result:

function! ToggleGUICruft()
    if &guioptions=='i'
        exec('set guioptions=imTrL')
    else exec('set guioptions=i') endifendfunction

expected result:

function! ToggleGUICruft()
    if &guioptions=='i'
        exec('set guioptions=imTrL')
    else exec('set guioptions=i') 
endifendfunction

[reedes]

Ah, okay. I think I understand now.

Pencil's hard line break mode makes use of vim's native auto-format capability, which is enabled when you enter Insert mode.

But it'll refrain from enabling auto-format if it encounters a syntax highlight attribute found in pencil's blacklist.

So, if you pasted this snippet inside of a fenced code block in a markdown filetype document, there'd be a markdownCode highlight in the blacklist, and auto-format would NOT be enabled.

But because you're pasting the snippet inside of a text or vim filetype document, there is no such protection.

You could add vim[A-Za-z]+ as a new entry to the g:pencil#autoformat_blacklist, but I'd recommend against it. Pencil's hard line break mode is best suited to prose file types where any code contained within will be in a fenced block which can be blacklisted.

Does that make sense?

[kevin4fly]

is this feature deliberately implemented or some other limitation that hard line break mode breaks auto-format?

[reedes]

The feature (of enabling auto-format in Insert mode) is by design. It benefits users who are editing documents with hard line breaks.

[kevin4fly]

hey, i think maybe i don't say it clearly. let me clarify it again.

here is the screenshot to illustrate the issue:

i think vim-pencil should only affect auto-format or wrap, breakline, however, it doesn't and has side effect.

do the step 6 in insert mode, we get top-left to top-right. compared with without vim-pencil, we get bottom-left to bottom-right, which is i expected.

what's more, if i wanna recover my code snippet, move cursor to top-right line 5 between )|e, press <enter> and then press <left>, things get massed up again. i hope you can get a try, thanks.

[reedes]

Are you explicitly initializing pencil for the vim filetype? Or is this a side-effect of merely having pencil installed?

Pencil isn't designed for code filetypes (such as vim above), but rather for prose-oriented filetypes like Markdown, textile, tex, rsh, etc.

[kevin4fly]

make sense that Pencil is used for prose and it do work. close it.

[kevin4fly]

thanks for your work of this plugin and reply my questions.

i have a idea here that is about the 'formatoptions' option in vim, if there is a c flag contained in this option, it will only auto-format comments, it is pretty nice when editing source code. so, what i hope is that hardline mode can be enabled if we inside a comment, whereas disable hardline if we out of a comment.

[reedes]

I hadn't considered the case of enabling word processing features exclusively inside of comments for code modules, but I can see how that would be useful.

One of the key challenges is to balance settings that affect both code and prose, such as iskeyword, to ensure that supporting a setting in prose wouldn't come at code's expense, or visa versa.

I'll keep this use case in mind, though at this point I'm not optimistic that the competing needs can be satisfied.