orgmode icon indicating copy to clipboard operation
orgmode copied to clipboard

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

Open Maltimore opened this issue 2 years ago • 3 comments

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.

Maltimore avatar Jan 16 '23 20:01 Maltimore

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

jgollenz avatar Jan 17 '23 22:01 jgollenz

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.

Maltimore avatar Jan 26 '23 20:01 Maltimore

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 :+1: 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.

jgollenz avatar Mar 02 '23 17:03 jgollenz