bullets-vim / bullets.vim

🔫 Bullets.vim is a Vim/NeoVim plugin for automated bullet lists.
https://doriankarter.com
Other
472 stars 37 forks source link

indent after wrap with bullets #38

Closed adidottxt closed 4 years ago

adidottxt commented 4 years ago

Referencing this issue and this comment -- does anything need to be done to activate this feature? I installed bullets.vim but the wrapping does not seem to work as described.

I also have set wrap linebreak nolist in my .vimrc, which I'd imagine could be the only other configuration that could affect this. I'm also pretty certain that this isn't an issue with the plugin installation / the plugin is installed, given the automated bullet lists feature does work.

Let me know if there's anything I can provide to help with this.

dkarter commented 4 years ago

Hi @adi-txt I created a minimal vimrc to test this. The only thing that needs to be set is textwidth for this to work as described:

syntax on
call plug#begin('~/.vim/bundle')

set textwidth=80

Plug 'dkarter/bullets.vim'

call plug#end()

Save this into a file (e.g. debug.vim) and load it using vim -Nu debug.vim

This is what it looks like (sorry for the gibberish but it makes it faster to test):

demo

Eetion commented 4 years ago

This is probably beyond my (shallow) depth. Tried creating the debug.vim file as directed, but opening via vim -Nu debug.vim just produced

Screen Shot 2019-10-07 at 14 06 17

Tried creating lists with * and - within the opened file, but for whatever reason hitting return didn't create a new bullet. Perhaps I messed with a setting somewhere. Thanks for the try!

dkarter commented 4 years ago

@Eetion my minimal vimrc is assuming you use vim-plug, and NeoVim. I'm no longer using Vim so I'm not sure that specific debug.vim file will work for your setup. However you can just try setting the textwidth value like so: set textwidth=80 and see if it works in a markdown file.

Eetion commented 4 years ago

Thanks! Just tried. The result is fairly similar to before: indentation works correctly for the first line after the bullet, but left-justifies on the third line:

- slda asdfasd asdf das asdfasd asdf sadf asdf asdf asdf asdfa sdf asdf sadf
  asdf asdf sdaf asf dasf adsfsda asdf asdf asdf asdf asdfasd fdsaf asdf asdf
asdf addsfa
dkarter commented 4 years ago

At the very least, regardless of bullets.vim you should be able to get automatic line breaks in an empty buffer like so:

demo

Notice I did not enter any bullet for that, just typed text in an empty buffer past the textwidth setting I have of 80 characters. (which is not a default setting if you run vim -u NONE).

Also, I have wrapping turned off (set nowrap) and i'm not sure if that behavior is even possible with wrapping turned on, so try turning it off and see if you get a better result

Eetion commented 4 years ago

Thanks! At present I have :set nowrap and set: textwidth=80. Lines do wrap at 80 characters in an empty buffer, and do wrap in a list (it's just that in the list they don't indent starting at the 3rd line, as in the example above). Guessing I've caused this problem by doing something that an established Vim user would know not to do, so may not be worth spending more time on it. Just in case it's ever of use/interest, though, here's my .vimrc:

"   PLUG
call plug#begin('~/.vim/plugged')
Plug 'dkarter/bullets.vim'
Plug 'JuliaEditorSupport/julia-vim'
Plug 'zhou13/vim-easyescape'
call plug#end()

"   CONVERT 1 TAB -> 4 SPACES
filetype plugin indent on
" show existing tab with 4 spaces width
set tabstop=4
" when indenting with '>', use 4 spaces width
set shiftwidth=4
" On pressing tab, insert 4 spaces
set expandtab

"   FORMAT OPTIONS
autocmd BufNewFile,BufRead * setlocal formatoptions+=tcq

"   UNKOWN
vmap <C-x> :!pbcopy<CR>
vmap <C-c> :w !pbcopy<CR><CR>

"   EASYESCAPE
let g:easyescape_chars = { "j": 1, "k": 1 }
let g:easyescape_timeout = 100
cnoremap jk <ESC>
cnoremap kj <ESC>

Thanks again for the help.

adidottxt commented 4 years ago

Hi @dkarter –– sorry for the delay with this, and I appreciate your super quick turnaround here.

I played around with my .vimrc and the minimal debug.vim version you had here and it works as you've shown. However I think I'd assumed that the indent after wrap with bullets occurred on the same "line" within Vim, as opposed to essentially splitting a longer line into two or more.

I was hoping for the indent after wrap with bullets to work on one line because it can be easier to edit a long line that isn't split into two/three/more as opposed to moving text from line to line and then reformatting with gq (which isn't the end of the world, of course).

There were certain instances while editing (see below) where the 80 character limit was exceeded on a specific line, and it took reaching to a certain number of characters before the line auto-wrapped. Again, not a big deal at all given I can reformat the lines using gq (as shown at the end of the gif below), but my ideal scenario would be to have all that text be part of the same "line" within Vim. I'm not sure if that's doable, but either way, thank you for your help!

bullets vim

dkarter commented 4 years ago

@adi-txt I’m not sure I understand the issue, but what’s happening in the gif you posted looks like normal behavior to me. To be clear, all wrapping logic is done by Vim, and I am not sure how to configure it to break the line if you start typing in a middle of an existing line that is already at the textwidth limit.

Bullets.vim doesn’t change anything about the native Vim wrapping behavior. Instead, when you press <CR> in insert mode, it checks whether you are or aren’t inside an indented bullet by looking up at previous lines.

If you are inside an indented bullet and just pressed enter, a new bullet would be created. Otherwise, it will just call the original action <CR> was supposed to execute (which is likely creating a new empty line).

Hope this makes sense.

dkarter commented 4 years ago

@Eetion

Thanks! At present I have :set nowrap and set: textwidth=80. Lines do wrap at 80 characters in an empty buffer, and do wrap in a list (it's just that in the list they don't indent starting at the 3rd line, as in the example above). Guessing I've caused this problem by doing something that an established Vim user would know not to do, so may not be worth spending more time on it. Just in case it's ever of use/interest, though, here's my .vimrc:

"   PLUG
call plug#begin('~/.vim/plugged')
Plug 'dkarter/bullets.vim'
Plug 'JuliaEditorSupport/julia-vim'
Plug 'zhou13/vim-easyescape'
call plug#end()

"   CONVERT 1 TAB -> 4 SPACES
filetype plugin indent on
" show existing tab with 4 spaces width
set tabstop=4
" when indenting with '>', use 4 spaces width
set shiftwidth=4
" On pressing tab, insert 4 spaces
set expandtab

"   FORMAT OPTIONS
autocmd BufNewFile,BufRead * setlocal formatoptions+=tcq

"   UNKOWN
vmap <C-x> :!pbcopy<CR>
vmap <C-c> :w !pbcopy<CR><CR>

"   EASYESCAPE
let g:easyescape_chars = { "j": 1, "k": 1 }
let g:easyescape_timeout = 100
cnoremap jk <ESC>
cnoremap kj <ESC>

Thanks again for the help.

I don’t think those other plugins (e.g. Julia, or vim-easy escape) are relevant to the issue, are they? Nor are the other settings? And I don’t see textwidth in your config.

The idea of the minimal vimrc is to narrow down the potential reasons of what might be causing the issue. If you remove the extraneous plugins and settings, and add the suggested ones, does the issue still happen? Try to take them out one by one until you narrow it down to the cause of the issue.

Try using the minimal vimrc I drafted above, copy the text, save it to your computer and load it as instructed above. Does it still happen with that minimal config?

adidottxt commented 4 years ago

Interesting. I think what I'd expected is that bullets.vim would wrap text but keep it within the same "line" (as defined by the line number), but it seems like this might not be possible with Vim's wrapping behavior.

Also FWIW all of this was just a point of clarification -- my initial issue with wrapping was solved by using your debug.vim file and building the rest of my .vimrc file on top of that -- I should've been clearer about that. Feel free to close this issue whenever you see fit.

Thanks!