Skip to content

org_indent_mode = "noindent" is buggy with lists #473

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jgollenz opened this issue Dec 17, 2022 · 1 comment · Fixed by #597
Closed

org_indent_mode = "noindent" is buggy with lists #473

jgollenz opened this issue Dec 17, 2022 · 1 comment · Fixed by #597
Labels
bug Something isn't working

Comments

@jgollenz
Copy link
Contributor

jgollenz commented Dec 17, 2022

Describe the bug

When set to "noindent", adding a newline will still respect the indentation of the previous line I had a typo in the config, but it looks like I found a different bug. See comment below

Also, the default value for emacs seems to be "noindent", not "indent"

Steps to reproduce

  1. Run nvim -u minimal_init.lua foo.org
  2. Add the following line
* foo|
  1. Press <Enter>

Expected behavior

The cursor should be at the beginning of the line:

* foo
|

Emacs functionality

Emacs in general does not add any actual indenting after a headline. When org-indent-mode is activated, it only adds the respective virtual indentation:

org-indent-mode

This is not true for lists, however, no matter whether org-indent-mode is active or not. Our current description of org_indent_mode in the docs, does not reflect what the option does in emacs.

Minimal init.lua

vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])

local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'

local function load_plugins()
  require('packer').startup({
    {
      'wbthomason/packer.nvim',
      { 'nvim-treesitter/nvim-treesitter' },
      { 'kristijanhusak/orgmode.nvim', branch = 'master' },
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
    },
  })
end

_G.load_config = function()
  require('orgmode').setup_ts_grammar()
  require('nvim-treesitter.configs').setup({
    ensure_installed = { 'latex' },
    highlight = {
      enable = true,
      additional_vim_regex_highlighting = { 'org' },
    },
    org_indent_mode = 'noindent',
  })

  vim.cmd([[packadd nvim-treesitter]])
  vim.cmd([[runtime plugin/nvim-treesitter.lua]])
  vim.cmd([[TSUpdateSync org]])

  -- Close packer after install
  if vim.bo.filetype == 'packer' then
    vim.api.nvim_win_close(0, true)
  end

  require('orgmode').setup({
    org_highlight_latex_and_related = 'native',
  })

  -- Reload current file if it's org file to reload tree-sitter
  if vim.bo.filetype == 'org' then
    vim.cmd([[edit!]])
  end
end

if vim.fn.isdirectory(install_path) == 0 then
  vim.fn.system({ 'git', 'clone', 'https://github.com/wbthomason/packer.nvim', install_path })
  load_plugins()
  require('packer').sync()
  vim.cmd([[autocmd User PackerCompileDone ++once lua load_config()]])
else
  load_plugins()
  load_config()
end

Screenshots and recordings

No response

OS / Distro

Ubuntu 20.04

Neovim version/commit

0.8.1

Additional context

Related issues

#472
#422

@jgollenz jgollenz added the bug Something isn't working label Dec 17, 2022
@jgollenz
Copy link
Contributor Author

jgollenz commented Jan 12, 2023

Nevermind, I had a typo in my config. It works as expected. Something that differs from emacs is this:

indent

In emacs, duh has the same indentation as baz has. It will work correctly in nvim-orgmode when org_indent_mode is set to indent. I suspected autoindent to be the culprit, but disabling it doesn't change the result.

@jgollenz jgollenz changed the title org_indent_mode = "noindent" not working org_indent_mode = "noindent" ~~not working~~ is buggy with lists Jan 12, 2023
@jgollenz jgollenz changed the title org_indent_mode = "noindent" ~~not working~~ is buggy with lists org_indent_mode = "noindent" is buggy with lists Jan 12, 2023
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 6, 2023
Closes nvim-orgmode#473.

The previous rules were buggy for `noindent` but happened to work very
well for `indent`. It turns out there were two branches in
`OrgmodeIndentExpr()` that were responsible for this. For the second
line and onward after a list item, they fell through to the default
logic, which is:

- zero-indent if `org_indent_mode == "noindent"`,
- otherwise, copy from the previous line.

Now, they don't fall through, but instead use the previous line's
indentation.

However, there is one edge case: if the line is equally or less indented
than the previous one, then we keep the lesser indentation. This is
necessary because according to the [Orgmode syntax][1], the following
list:
- only has one line,
and the subsequent line is regular text again.

Somehow, this solution does not interfere with interactive editing and
does not break unusual cases like breaking a list item line in the
middle. Neat!

[1]: https://orgmode.org/worg/org-syntax.html#Items
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 6, 2023
Closes nvim-orgmode#473.

The previous rules were buggy for `noindent` but happened to work very
well for `indent`. It turns out there were two branches in
`OrgmodeIndentExpr()` that were responsible for this. For the second
line and onward after a list item, they fell through to the default
logic, which is:

- zero-indent if `org_indent_mode == "noindent"`,
- otherwise, copy from the previous line.

Now, they don't fall through, but instead use the previous line's
indentation.

However, there is one edge case: if the line is equally or less indented
than the previous one, then we keep the lesser indentation. This is
necessary because according to the [Orgmode syntax][1], the following
list:
- only has one line,
and the subsequent line is regular text again.

Somehow, this solution does not interfere with interactive editing and
does not break unusual cases like breaking a list item line in the
middle. Neat!

[1]: https://orgmode.org/worg/org-syntax.html#Items
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 6, 2023
Closes nvim-orgmode#473.

The previous rules were buggy for `noindent` but happened to work very
well for `indent`. It turns out there were two branches in
`OrgmodeIndentExpr()` that were responsible for this. For the second
line and onward after a list item, they fell through to the default
logic, which is:

- zero-indent if `org_indent_mode == "noindent"`,
- otherwise, copy from the previous line.

Now, they don't fall through, but instead use the previous line's
indentation.

However, there is one edge case: if the line is equally or less indented
than the previous one, then we keep the lesser indentation. This is
necessary because according to the [Orgmode syntax][1], the following
list:
- only has one line,
and the subsequent line is regular text again.

Somehow, this solution does not interfere with interactive editing and
does not break unusual cases like breaking a list item line in the
middle. Neat!

[1]: https://orgmode.org/worg/org-syntax.html#Items
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 13, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 13, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 13, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Aug 13, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Sep 12, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Sep 27, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Sep 27, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Oct 1, 2023
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.
broken-pen added a commit to broken-pen/orgmode that referenced this issue Oct 11, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant