nvim-orgmode / orgmode

Orgmode clone written in Lua for Neovim 0.9+.
https://nvim-orgmode.github.io/
MIT License
3.03k stars 134 forks source link

Newline with o and enter creates list item #2

Closed kkharji closed 2 years ago

kkharji commented 3 years ago

Hey @kristijanhusak, awesome work, I had to the chance to give orgmode.nvim a try and intending to switch to it soon.

Describe the bug Pressing enter on a section create new indented list list. Pressing enter on a todo section creates a indent line.

* Section<CR>
   * | 
* TODO Section<CR>
   |

I feel this intentional behavior and I wonder if I can disable it somehow or is there an alternative way to create sub item in normal and insert mode To Reproduce Steps to reproduce the behavior:

  1. create new heading
  2. press enter in insert mode or o in normal mode

Expected behavior

A normal enter/o should act as expected.

Emacs functionality not sure

System information:

Additional context Add any other context about the problem here.

kristijanhusak commented 3 years ago

Hey @tami5 , I'm not able to reproduce the bug, or I don't understand it completely.

When I have this:

* Section|

And I press Enter, I get this:

* Section
  |

And for todo item, this:

* TODO Section|

Becomes this:

* TODO Section
  |

I do not override functionality for either o or <CR> in org file. Maybe you are using some other plugin that overrides this. Can you check what you have mapped to those while in org buffer?

kkharji commented 3 years ago

Oh I see so the indentation is default behavior. is there away to disable it?

Indeed, is mapped to compe related function but when I changed back to <CR> same issue.

* TODO ITEM<CR>/o
   * | < appends `*`  

:nmap o isn't mapped to anything but still same issue with * TODO section creating indented list item.

I'm sure I have something conflicting somehow, I'll investigate more in the morning. Thanks for confirming

kristijanhusak commented 3 years ago

Emacs orgmode has electric-indent-mode, but from what I see, this completely removes indentation, which means that this:

* TODO Section|

Becomes this:

* TODO Section
|

But this also means that all indentation is disabled. So if you have something like this:

* TODO Section
  Some content|

Pressing <CR> does this:

* TODO Section
  Some content
|

If you want to insert additional headline below you can use <Leader><CR>, which should do this:

* TODO Section|

Becomes:

* TODO Section

* |
akinsho commented 3 years ago

FWIW I actually thought the indentation was a nice touch, not to derail this issue but if there is some change made can it be optional so it can be maintained for anyone who also likes this behaviour. That being said I'm not an orgmode expert should the next line after the todo be indented. To me it seems like it should so the asterixes are on the left marking each todo and all the content of the todo is indented e.g.

* TODO do something important 1
  :DEADLINE: <some-time>
  :PROPERTIES: stuff

* TODO do something else 2
  :DEADLINE: <some-other-stuff>
talw commented 3 years ago

@tami5

Do your formatoptions have o in them? In an org file buffer, check the output of

set formatoptions?

If you have o in the value try removing it and see if that solves the issue

set formatoptions-=o

If it does and you want this to persist, add to your config something like:

augroup orgmodeAutocommands
  au!
  autocmd filetype org setlocal formatoptions-=o
augroup END

Or just add the autocmd to your existing augroup

kkharji commented 3 years ago

Hey @talw , Indeed I had format option o but even after removing it and ending up with formatoptions=1jcrql the issue still exists, I tried and remove all formatoptions and that fixed the issue 🗡️ , I'd need to read through the format options a bit more see which one causing this issue and add autocmd as you've suggested.

Thanks so much @talw

talw commented 3 years ago

@tami5

No problem! I'm glad I could be of some help.

I guess all that's left is to try and remove each time a different letter so that you can pinpoint exactly which letter causes it, and once you do, as you said, just set an autocmd to remove it from formatoptions upon loading an org file buffer.