[WIP][RFC] Open tmp window: handle case where tmp window is prev window

[Maltimore]

This is my first ever contribution to an nvim plugin, so take everything with a grain of salt.

This PR fixes an issue when the win_split_mode is set such that no new window is opened, but instead the agenda/capture buffer are opened in the current window. See the following excerpt of my org config:

  win_split_mode = function(bufname) -- open agenda buffer in same window
    local bufnr = vim.api.nvim_create_buf(false, true)
    -- Setting buffer name is required
    vim.api.nvim_buf_set_name(bufnr, bufname)
    local current_window_nr = vim.api.nvim_tabpage_get_win(0)
    vim.api.nvim_win_set_buf(current_window_nr, bufnr)
  end,

There is a problem when "finalizing" the capture (with <C-c> by default), namely that it tries to close the temporary window. But a temporary window had never been opened.

I wonder if this PR is at all going in the right direction. I haven't run the test suite yet as I haven't yet learned how that works. I'll hopefully get to it in the next days unless you tell me now that this PR doesn't make sense.

[jgollenz]

Thanks for the contribution @Maltimore 👍

[jgollenz]

Probably best to also run the checks on bufnr.

if prev_bufnr and vim.api.nvim_buf_is_valid(prev_bufnr) ...

[jgollenz]

btw, what should happen if the bufnr is invalid? With winnr the window gets closed in any case.

[Maltimore]

Good point(s). I suppose if the prev_bufnr is invalid, we should simply unload the capture buffer and vim will automatically switch to some other buffer?

[jgollenz]

You can run the tests with

make test

if it's the first time you run them, be sure to get the dependencies before that

git clone https://github.com/nvim-treesitter/nvim-treesitter
git clone https://github.com/nvim-lua/plenary.nvim

All those are ran from the root of the repository

[Maltimore]

I pushed a change incorporating your suggestion, thanks again.
I thought about what to do in case prev_bufnr is invalid, and I concluded not to do anything. My first impulse was to then delete the buffer for which the tmp window was opened, but since this is such a general function (not specific to capture), we don't know what the purpose of the tmp window might've been, and we shouldn't just go around deleting buffers.

[jgollenz]

Hey @Maltimore, sorry it took me so long to respond. When the bufnr is invalid, the capture is written to the destination and we are left with an empty file. I'm not exactly sure yet, the trail led me to capture/init.luas _refile_to. Perhaps it's because we are closing the actual capture buffer without saving. But that's beside the point of this MR. This looks good to me 👍 Please, just add a warning that tells the user that no match was found both fore the prev_winnr and the prev_bufnr. I'm not even sure what would cause such a situation, but just in case.