Easy to lose in-progress capture that only ends up in temp dir with `:w`

[zivarah]

Describe the bug

If you have an in-progress capture, it can be very easy to lose it entirely. It seems to be recoverable as long as you don't close nvim, and know exactly what to do, but it doesn't seem intuitive to do so.

It appears that until you actually file the capture, it doesn't really live anywhere persistent (expected), even if you write the buffer (not expected).

Before you file or write with :w, if you use <TAB> from the agenda to open a different TODO, you'll get this error: [orgmode] vim/_editor.lua:341: nvim_exec2(): Vim(edit):E37: No write since last change (add ! to override). Similar story if you try to close the buffer or nvim as a whole. However, if you use :w, then that in-progress capture's buffer is allowed to close without being filed and without warning.

The buffer also seems to disappear entirely (ls! does not show it) when closed, which exacerbates the issue. I am not sure if this is just because it's unlisted or some other reason, but I was not able to identify a way to get this buffer back outside of manually identifying and opening the temp file. At that point, it's a plain file with no orgmode support (maybe a way to re-enable that?) but I think you'd have to manually file it.

If you don't do that, you will permanently lose that capture when nvim is closed as that temp file seems to get cleaned up.

The end result here is that I lost some notes for a meeting that, thankfully, I was just taking to get used to orgmode.

This is just one example workflow, but any way that you end up leaving nvim after saving an in-progress capture using :w will run into this, as the :w prevents any warnings.

Steps to reproduce

Edit: Keeping the below for posterity, but they don't actually reproduce the issue.
See #644 (comment) for steps that actually reproduce.

The simplest workflow, I think:

1. Start a new capture with <leader>oc
2. Write the capture buffer with :w, noting the temp file name it is written to
3. Close nvim with :q
4. See that the temp file is gone, and the capture was never filed

Expected behavior

I think there are a couple of improvements that could potentially be made here:

• Warn about any un-filed captures before overwriting the capture buffer (or allowing vim to close, if possible), regardless of whether they've been written to the temp file.
• Make the capture buffers listed. This makes them way more discoverable and provides general benefits outside of just this problem.
• Provide a command/keymap to get back to an in-progress capture with full orgmode support

Emacs functionality

No response

Minimal init.lua

local nvim_root = '/tmp/nvim_orgmode'
local lazy_root = nvim_root .. '/lazy'
local lazypath = lazy_root .. '/lazy.nvim'

-- Install lazy.nvim if not already installed
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    'git',
    'clone',
    '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git',
    '--branch=stable', -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
  {
    'nvim-orgmode/orgmode',
    dependencies = {
      { 'nvim-treesitter/nvim-treesitter', lazy = true },
    },
    event = 'VeryLazy',
    config = function()
      -- Load treesitter grammar for org
      require('orgmode').setup_ts_grammar()

      -- Setup treesitter
      require('nvim-treesitter.configs').setup({
        highlight = {
          enable = true,
          additional_vim_regex_highlighting = { 'org' },
        },
        ensure_installed = { 'org' },
      })

      -- Setup orgmode
     require('orgmode').setup({
        org_agenda_files = nvim_root .. '/org/**/*',
        org_default_notes_file = nvim_root .. '/org/refile.org',
     })
    end,
  },
}, {
  root = lazy_root,
  lockfile = nvim_root .. '/lazy.json',
  install = {
    missing = false,
  },
})

require('lazy').sync({
  wait = true,
  show = false,
})

Screenshots and recordings

No response

OS / Distro

macOS 14.2

Neovim version/commit

v0.9.4

Additional context

Also reproduced in v0.9.2 on Windows 10

[Sebastian Flügge]

Are you sure, that the content of your capture window is really lost? The default behavior is, when the temporary capture file get's closed, the content is appended to your default notes file (see org_default_notes_file in the documentation).
I just tested, what you described:

1. Open a capture
2. Write some content and save with :w
3. Open the agenda, select an entry and open it in the capture window with
4. Look into my default notes file and, voila, the content I just wrote in the capture temporary file is there.

The "simplest" workflow you describe is actually the intended one:

1. Open a capture
2. Write some content, save and close the capture window with :wq or :w and :q (both is fine)
3. Open the default notes file and see the content appended at the end of the file

You can also have more complicated captures, where you explicitly state in the capture definition the target - the file, where the capture is moved into, and even - optionally - the headline, a section into which the capture is appended.

So I'm actually unable to reproduce the issue, you describe. Maybe you can double-check, if the content is really not refiled to your default note files and if so, give a more detailed step-by-step description, how to reproduce the error. And please ensure, that you have the latest master. I did some fixes in refiling recently.

[zivarah]

Well, naturally I'm having trouble reproducing this in exactly the same way I listed in the reproduction steps. I'm not sure what I was seeing on Thursday, but I am still able to reproduce this a more complicated way (that I think is how I actually hit it in the real world). I may have just gotten confused and thought I'd reproduced it while trying to simplify the instructions - apologies for that.

Try these steps, using that same minimal config:

1. Create a todo using <leader>oc
2. Give it a title of "Test 1"
3. Save and file it
4. Create a second todo
5. Give it a title of "Test 2"
6. Save it with :w but don't close the buffer
7. Open the todo list with <leader>oa => t
8. Navigate to the first todo in the todo list and hit <TAB>
9. See that the "Test 2" buffer is replaced with the refile.org file contents, showing "Test 1"
10. Close nvim with :qa
11. See that refile.org contains only "Test 1" -- "Test 2" appears to be lost

[Sebastian Flügge]

Very interesting. You point me to a bug I already observed, but was too lazy to systematically reproduce, because it didn't hit me for quite a while.
What actually happens is, that when I do step 4 to 10, that my refile.org get's somehow scrambled additionally to the lost content of the second capture buffer.

Thanks for pointing my nose to it, I will investigate this.

[Sebastian Flügge]

I created PR #647, which fixes this bug. @kristijanhusak I created it upon another PR (#641), so we either need to merge #641 first or we close it after merging #647 directly.

[zivarah]

@seflue I tested against your fix branch and confirmed that this appears to be working as expected now. Thank you for the quick fix!