Skip to content
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

go to definition closes jupynium tab and stops syncing #34

Closed
fecet opened this issue Feb 16, 2023 · 15 comments
Closed

go to definition closes jupynium tab and stops syncing #34

fecet opened this issue Feb 16, 2023 · 15 comments
Labels
bug Something isn't working

Comments

@fecet
Copy link
Contributor

fecet commented Feb 16, 2023

In my setup, jupynium will automaticlly close tab when the sync file is not in current buffers. But this would be a little annoyed if I just leave the current file just to check some definition by vim.lsp.buf.definition.

Is this by design? Could I do something to workaround it or if there exist a better workflow?

@kiyoon
Copy link
Owner

kiyoon commented Feb 16, 2023

I'm using BufWinLeave event to check if the buffer is closed. Maybe that is causing this. I can change it to BufDelete but then it won't close on :wq. I'll see if there's any better event to use

@fecet
Copy link
Contributor Author

fecet commented Feb 16, 2023

So how do you check definition? I'm open to change my workflow to suit this plugin. :)

@kiyoon
Copy link
Owner

kiyoon commented Feb 16, 2023

it's clearly a bug and I'll try to fix this. I probably haven't used gd whilst using Jupynium yet. I probably used peek definition from nvim-treesitter-textobjects

@fecet
Copy link
Contributor Author

fecet commented Feb 16, 2023

x this. I probably have

Ya that make sense, I'm generally also use glance.nvim to peek definition so just realized this problem recently.

@kiyoon
Copy link
Owner

kiyoon commented Feb 16, 2023

I created repro.lua that will log all buffer related events for vim. You can watch in /tmp/listener.log and this includes pyright LSP with gd keymapping.

With this configuration you can see that when you gd it will call BufWinLeave. Same for :q, unless vim is closed entirely it will not call BufUnload.

I don't know if it's vim's limitation. It seems like there's no other autocmd that distinguishes these.

Workaround: when BufWinLeave occurs, check if BufWinEnter is occurred at the same time. If BufWinEnter is not occurred it's :q. Otherwise it's goto definition and we do not close the tab. It may not cover all the edge cases. Will need to investigate further how to implement this

vim.cmd([[
set nocompatible
function s:EchoEvent(msg)
  redir >> /tmp/listener.log | echo a:msg | redir END
endfunction

au BufNewFile * call s:EchoEvent("BufNewFile")
au BufReadPre * call s:EchoEvent("BufReadPre")
au BufRead * call s:EchoEvent("BufRead")
au BufReadPost * call s:EchoEvent("BufReadPost")
au BufWrite * call s:EchoEvent("BufWrite")
au BufWritePre * call s:EchoEvent("BufWritePre")
au BufWritePost * call s:EchoEvent("BufWritePost")
au BufAdd * call s:EchoEvent("BufAdd ".expand("<abuf>")." ".expand("<afile>"))
au BufCreate * call s:EchoEvent("BufCreate ".expand("<abuf>")." ".expand("<afile>"))
au BufDelete * call s:EchoEvent("BufDelete ".expand("<abuf>")." ".expand("<afile>")." ".bufnr())
au BufWipeout * call s:EchoEvent("BufWipeout ".expand("<abuf>")." ".expand("<afile>"))
au BufFilePre * call s:EchoEvent("BufFilePre")
au BufFilePost * call s:EchoEvent("BufFilePost")
au BufEnter * call s:EchoEvent("BufEnter ".bufnr()." ".bufname())
au BufLeave * call s:EchoEvent("BufLeave ".expand("<abuf>")." ".expand("<afile>"))
au BufWinEnter * call s:EchoEvent("BufWinEnter ".bufnr()." ".bufname())
au BufWinLeave * call s:EchoEvent("BufWinLeave ".expand("<abuf>")." ".expand("<afile>"))
au BufUnload * call s:EchoEvent("BufUnload ".expand("<abuf>")." ".expand("<afile>"))
au BufHidden * call s:EchoEvent("BufHidden ".expand("<abuf>")." ".expand("<afile>"))
au BufNew * call s:EchoEvent("BufNew ".expand("<abuf>")." ".expand("<afile>"))
au VimEnter * call s:EchoEvent("VimEnter")
]])

local pattern = "python"
local cmd = { "pyright-langserver", "--stdio" }
-- Add files/folders here that indicate the root of a project
local root_markers = { ".git", ".editorconfig" }
-- Change to table with settings if required
local settings = vim.empty_dict()

vim.api.nvim_create_autocmd("FileType", {
	pattern = pattern,
	callback = function(args)
		local match = vim.fs.find(root_markers, { path = args.file, upward = true })[1]
		local root_dir = match and vim.fn.fnamemodify(match, ":p:h") or nil
		vim.lsp.start({
			name = "pyright",
			cmd = cmd,
			root_dir = root_dir,
			settings = settings,
		})
	end,
})

-- vim.lsp.handlers["textDocument/publishDiagnostics"] = vim.lsp.with(vim.lsp.diagnostic.on_publish_diagnostics, {
--   update_in_insert = true,
-- })
local config = {
	-- virtual_text = true,
	virtual_text = { spacing = 3, prefix = "" },
	signs = {
		active = signs, -- show signs
	},
	update_in_insert = true,
	underline = true,
	severity_sort = true,
	float = {
		focusable = true,
		style = "minimal",
		border = "rounded",
		source = "always",
		header = "",
		prefix = "",
	},
}

vim.diagnostic.config(config)

vim.keymap.set("n", "gd", vim.lsp.buf.definition)

@kiyoon kiyoon changed the title go definition without close current jupynium instance go to definition closes jupynium tab and stops syncing Feb 16, 2023
@kiyoon kiyoon added the bug Something isn't working label Feb 16, 2023
@fecet
Copy link
Contributor Author

fecet commented Feb 17, 2023

So the problem is there isn't a simple way to distinguish between bufwenleave and close vim?

@kiyoon
Copy link
Owner

kiyoon commented Feb 17, 2023

@fecet not closing vim but closing the buffer.

Let's say you have a vsplit with one normal and the other jupynium file, and you close the jupynium file, I wanted to make it stop syncing the buffer.

I can use BufDelete etc. but it will almost never be triggered because apparently even with :wq the buffer is still alive in memory

@fecet
Copy link
Contributor Author

fecet commented Feb 17, 2023

As a naive user, I know very little about buffer in Vim. What would happen if there is no stop-sync mechanism? Would it affect the next sync to notebook?

@kiyoon
Copy link
Owner

kiyoon commented Feb 17, 2023

@fecet No, it won't do anything special, so I could also provide a config to disable it but I want some more general solution so people don't have too many confusing configs

I just thought people using Jupynium would want to close the tab when you close the buffer with :wq without having to go through that step manually with mouse.

@fecet
Copy link
Contributor Author

fecet commented Feb 17, 2023

For me a disable option would be awesome cause I never want to close tab...

@kiyoon
Copy link
Owner

kiyoon commented Feb 17, 2023

By the way it's not only closing the tab but it's stop syncing. Stop sync should be fired automatically if you close vim for example. So even if you disable closing the tab, goto definition will make it stop syncing suddenly which is also not ideal.

I think I will just have to relieve the condition to automatically stop syncing. Like I should just listen to BufDelete and VimLeave

@fecet
Copy link
Contributor Author

fecet commented Feb 17, 2023

I mean if there is an option that do nothing when leave buffer or close vim, would this result in some problem? Otherwise it would be good for me.

@kiyoon
Copy link
Owner

kiyoon commented Feb 17, 2023

I'll also add an option for that.

@kiyoon
Copy link
Owner

kiyoon commented Feb 17, 2023

Can you try the new version? Even if you don't set the option, you'll see that the go to definition is fixed. The tab will close on vim leave or buffer delete.
You can try auto_close_tab = false in the option table to disable closing at all.

@fecet
Copy link
Contributor Author

fecet commented Feb 18, 2023

Sorry for late, I can confirm both the fix and option work like a charm!

@fecet fecet closed this as completed Feb 18, 2023
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

No branches or pull requests

2 participants