Indentation increases with each item #472
Comments
|
I guess I'll be more specific about what I'd expect to happen: After headlines, one indentation level should be added, but if I then type After a list item, the indentation should stay the same. Increased or decreased nesting of subsequent items should be done by the user. E.G.: After typing After typing |
|
If this is the intended behavior and I'm missing something, I'd love to hear what the right way to be doing this is :). |
|
I understand that the behavior you expect makes sense from your point of view, but I think it needs a bit more nuance. E.g. These would be very awkward to write with what you are proposing. Granted, you're more likely to add a new heading/list-item than doing what I did above. We surely can discuss whether your suggestion would be more beneficial. Concerning your original issue: the reason (or at least that's how I interpret it) why indentation is added after pressing enter at the end of a list-item, is that you might want to write something that still belongs to the list-item in a new line: If you want to add a new list-item, you can use |
|
I just checked and I can reproduce this with |
|
Ok, in emacs the list-items still preserve the indentation on |
|
Thanks for responding, @jgollenz! That's certainly interesting...it kinda feels like it's treating adding a new list item immediately like the edge case rather than the normal thing...but that's just me I guess. If that's the way the original org mode does it, then I guess it's correct 🤷. Just to add in my perspective a little more I guess, most of the time in other word processors and stuff like that, pressing enter adds a new list item at the same level. If you want to adjust the level, you can normally do this with tab/shift-tab, backspace, or enter, or sometimes all three (i.e. tab increases level, shift-tab, backspace, and enter decrease level). Then shift-enter is often what is used to add a newline without adding a new list item. Again, just throwing it out there. Compatibility with org mode, at least by default, makes sense. It's just that exiting normal mode and pressing |
|
I get your points. Even Github follows this conventions to a degree. They treat lists as bullet-lists per default. However, in general it's probably not fair to compare neovim to a word processor. If you indent text in neovim and then add a new line with There is an argument to be had whether its worthwhile to enable the functionality you mentioned with a flag. Generally speaking, this repo tries to be a port and only add additional features that make sense in the neovim world. Personally I think that this feature will result in more complexity. I'd rather spent more energy on trying to be faithful to emacs orgmode first. Btw, in emacs this does not impact users as much, since they can just press |
|
@pianocomposer321 in any case, the title for this GH issue doesn't really describe a bug. Can you please remove the |
|
Fair enough, that makes sense. Having I'm not actually sure how to change the labels on GH issues lol. I'm not seeing an x or anything to remove the bug label. 🤷 |
I guess @kristijanhusak has to do that then |
kristijanhusak
added
core-feature
jgollenz
added
non-core-feature
|
I ran into the same issue. I think, we should provide org_meta_return also for insert mode. It feels very clunky to have to always exit insert mode when I need a new item (which is - as @pianocomposer321 already stated out) the more expected usecase. |
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
Closes nvim-orgmode#473. I tried doing small fixes to this code, but kept running into edge cases. Hence, this complete rewrite. :) The important points: - The queries in `indent.scm` no longer match on top-level (i.e un-nested) lists, but instead on list items of all levels. - List item indentation no longer relies on the previous non-empty line. Each list item stores whether it's in a top-level or a nested list and calculates its indent based on that. - The check whether we are in bulleted line or not no longer uses `str.match()`, since its pattern was buggy and forgot a few kinds of bullets. (namely, indented `*` bullets and `a.` ordered bullets) Instead, we compare the current line number to `match.line_nr`. We can do that because we query list items instead of lists now. There is an edge case when the user is appending to a list. We want that next line to be indented (see nvim-orgmode#472), but it's technically outside of the list. At the same time, if an unindented line follows a list, it should not become part of the list. The best solution I found for this was to make the behavior of `indentexpr()` depend on whether we are in insert mode. If yes, the line after a list is part of the list. If not, it isn't. The new code also correctly takes into account that two consecutive empty lines always end a preceding list.
|
Has anyone found a way to create new list items without exiting to normal mode since the last comment? |
|
Support for this was added on the latest |
|
Thanks @kristijanhusak I can confirm that with the minimal configuration using nightly the |
Describe the bug
I'm having a hard time determining if this is intended or not...but it's really annoying and I'm not sure how to disable it, or if I'm just doing something wrong. The problem is that when I'm writing a list, instead of being on the same indentation level, it adds one on the new line. This is super confusing, and it also happens when
org_indent_modeis set tonoindent.Steps to reproduce
When I start a list like so (| = cursor):
Then I press enter, I would expect this:
But instead I get this:
This means that repeatedly adding items gets each one indented an additional level, which is not what I want. If I want another level, I'll add one myself...
Expected behavior
Explained above.
Emacs functionality
Not really sure...I'm not an emacs user, and I'm not in a position to install it and check at the moment, but what demo videos I can find online do not seem to function the way this plugin does...though I think they're doing something more clever that I'm not sure is possible with neovim at all at the moment (with virtual indents and whatnot).
Minimal init.lua
The template works: https://github.com/nvim-orgmode/orgmode/blob/master/scripts/minimal_init.lua
Screenshots and recordings
No response
OS / Distro
Debian 11
Neovim version/commit
0.8.1
Additional context
No response
The text was updated successfully, but these errors were encountered: