Closed Aonodensetsu closed 4 months ago
I'm working on fully lazy-loading neo-tree, which is why I found this to be a thing.
on BufEnter:
Ahh ya looks like you got bit with the shitty documentation bug :) Try switching out
vim.defer_fn(function() require'netman':read(f) end, 0)
with
vim.defer_fn(function() require'netman'.read(f) end, 0)
It looks like the documentation still refers to using :
instead of .
when making function calls. That is bad and wrong. Lemme know if that works :)
cool, but as I said the same applies to :Nmread
, so that does not fix my issue
they seem to work under specific circumstances:
:Nmread
or .read
is executedthe file list does not open for folders, and trying to do as i'm doing even with defer, does not work
Huh, I will investigate further. I remember thinking that opening directories with :Nmread
would be an issue with the most recent update but I thought I pushed some code up to allow that (sorta), though that might still be in my local working branch and not in v1.15 (or main, you should stop using v1.15).
Thanks for the issue open! I will poke some this afternoon and see what I can figure out for you.
As we discussed in my previous ticket, I can't move to main because it crashes neovim on load. https://github.com/miversen33/netman.nvim/issues/174
Are you saying that my proposed fix didn't work? I asked if it did and didn't hear anything back so I assumed it did. Getting you on main is important
the v1.15 branch as well as commenting the line worked, i didn't get to the testing branch before it was 404, but assumed it was the same fix
i think lazy cached the main branch from before the fix as a clean install off main now works, but did not in my test right before posting this issue
Perfect :) I don't suppose getting you on main
fixed this issue though, correct?
no, still on the second attempt it also seems to not set the filetype sometimes
also :e
seems to never work
the 'fetching file' alert shows up every time, even if it doesn't actually open the file
:e
most certainly should be working, at least on a file level :(
Can you (for the sake of my sanity) show me an :e
command that doesn't work?
:e scp://self/.bashrc
before
after, the buffer name changes and no file is opened
:Nmread scp://self/.bashrc
after first time, same as :e
but shows alert
after subsequent times
running :e
multiple times doesn't do anything different
:Nmread
is equivalent to .read
but mixing them does not make the other work immediately
:Nmread
-> :Nmread
(works)
.read
-> .read
(works)
:Nmread
-> .read
(does not work) -> :Nmread
/.read
(either works)
also it seems like they prepend content to the buffer, if something is in it both contents remain - and the filetype is not updated
That's a whole lot of weirdness going on. I really appreciate the screenshots :)
Just a note, I am able to reproduce this issue. So that's fun. I will be creating another branch and seeing what I can figure out
Ok so I have figured out what is happening here. The issue you are seeing is related to the addition of async support for providers. This support is relatively robust but it seems there is a bug in how non-async requests work with providers that support async calls. I thought I had that figured out but I guess not.
For those who are curious, the problem line is api.lua:1003
This line is a problem because the by including this callback, it informs everything under it that it needs to be asynchronous if possible. That works for 90% of calls as async is the standard/default way of interacting with stuff.
The reason this is falling over is because we are not providing a callback to read but the rest of read is assuming async if possible. Thus the result is basically "lost". That also explains why it "works" after multiple attempts. This is a lucky coincidence due to the api's file read caching system. It sees the file is already downloaded and thus escapes and returns the file contents to open.
I am not sure the best way to handle this. Its likely a 2 pronged approach. I need to fix the actual API logic so it doesn't just assume async at all times. But I should also get :Nmread
to work asynchronously as well.
Another fun bug I have uncovered, multiple Nmread
calls just overwrite the same buffer. So that's fun :upside_down_face: I suspect that bug has been around for a while and just not noticed.
@Aonodensetsu can you try out Branch 204-bug-nmread-does-not-work and see if it fixes the issues you outlined?
This doesn't implement async handling for Nmread (something I still want to do) nor does it address the buffer overwriting bug I mentioned above. But I think it fixes the whole "having run the command twice" issue
.ssh/config
Host self
HostName 127.0.0.1
User <username>
not lazy:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
:lua require'netman'.read('ssh://self/.bashrc')
✅
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
❌
:lua require'netman'.read('ssh://self/.bashrc')
❌
my lazy config:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅❌ does not load file properties
lua require'netman'.read('ssh://self/.bashrc')
✅❌ does not load file properties
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
❌
:lua require'netman'.read('ssh://self/.bashrc')
❌
the lazy results also apply after manually loaded with Lazy load netman.nvim
from the results, it looks like e
is fixed, both Nmread
and .read
are not fixed in folder view, nor does the plugin load them correctly after VimStart
as before, remote folders don't open at all, i will probably botch a bypass to netrw for them unless you plan to add that feature
Ya opening folders is going to be a bit of a mess and I am not including that in this branch. That's my next stream of work though after this and getting Nmread
to play nice with async.
You have a test about "File properties", can I ask what you mean by that?
file type, buffer name eg the file content is set, the properties not
tbh i don't really understand why e
works in folder view but not commands directly, are you sending events correctly? (i'm hooked into BufEnter
)
The properties not
This doesn't explain anything lol what properties are you expecting to be set? This is likely an oversite on my part as I have absolutely no idea what you are talking about here.
tbh i don't really understand why e works in folder view but not commands directly, are you sending events correctly? (i'm hooked into BufEnter)
Folder view (in Neo-tree I assume you mean) handles opening files slightly differently than Nmread. This is mostly an artifact of the Neo-tree consumer supporting asynchronous reading of files and native "netman.read" not. Also Neo-tree does some help in creating buffers and opening files which I have to do myself when using "netman.read". Its definitely possible that I am doing something "incorrect" there.
the properties that i listed in that message, file type and buffer name only the content of the file is put into the buffer
Well, that is very strange. I will keep poking. Thank you so much for your help with this :)
@Aonodensetsu can you re-pull branch 204-bug-nmread-does-not-work and see if the issues you listed are still present?
I added some better buffer creation logic (this needed to be done anyway) and fixed the issue with the file name not being set.
I still have not retrofitted Nmread to support async yet and I will not be adding directory support with Nmread in this branch (that is a different set of work I need to do), but I hope to have cleared up the issues you have uncovered here
Error executing vim.schedule lua callback: Vim:E21: Cannot make changes, 'modifiable' is off
stack traceback:
[C]: in function 'deletebufline'
...local/share/nvim/lazy/netman.nvim/lua/netman/ui/init.lua:288: in function 'render_command_and_clean_buffer'
...o/.local/share/nvim/lazy/netman.nvim/lua/netman/init.lua:63: in function 'read'
/home/ao/.config/nvim/init.lua:706: in function ''
vim/_editor.lua: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
.read was changed?
ah wait my bad, this is in the lazy code, but i am testing without lazy now
That's an odd error, there should never be a point where netman is trying to write to an unmodifiable buffer. I'm sure the process you followed wasn't convoluted but can you provide the logs from Nmlogs
when you executed Nmread
there?
And yes, .read
was slightly modified. Nmread
is literally just a vim function that passes everything to .read
so any work being done on Nmread
will happen in .read
or further down the call stack
not lazy:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅❌ shows error 1 but opens
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅❌ shows error 1 but opens
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
:lua require'netman'.read('ssh://self/.bashrc')
✅
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
:lua require'netman'.read('ssh://self/.bashrc')
✅
my lazy config:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅❌ shows error 2 then 1 but opens
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅❌ shows error 1 twice but opens
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
lua require'netman'.read('ssh://self/.bashrc')
✅
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅❌shows error 1 but opens
:lua require'netman'.read('ssh://self/.bashrc')
✅❌shows error 1 but opens
error 1:
E5108: Error executing lua Vim:E21: Cannot make changes, 'modifiable' is off
stack traceback:
[C]: in function 'deletebufline'
...local/share/nvim/lazy/netman.nvim/lua/netman/ui/init.lua:288: in function 'render_command_and_clean_buffer'
...o/.local/share/nvim/lazy/netman.nvim/lua/netman/init.lua:63: in function 'read'
[string ":lua"]:1: in main chunk
error 2:
Error executing Lua callback: .../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:48: command line: Vim(lua):E5108: Error executing lua Vim:E21: Cannot make changes, 'modifiable' is off
stack traceback:
[C]: in function 'deletebufline'
...local/share/nvim/lazy/netman.nvim/lua/netman/ui/init.lua:288: in function 'render_command_and_clean_buffer'
...o/.local/share/nvim/lazy/netman.nvim/lua/netman/init.lua:63: in function 'read'
[string ":lua"]:1: in main chunk
[C]: in function 'cmd'
.../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:48: in function <.../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:16>
stack traceback:
[C]: in function 'cmd'
.../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:48: in function <.../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:16>
https://h.00t.in/m/netman.log -c '.read'
with lazy disabled
I just pushed up another change, try pulling that down and then trying again.
Also something interesting I am seeing in your logs, it seems that .read
is being called twice
If you look at line 224, you see a second "Reading ssh://self/.bashrc".
Which of your tests did this log come from?
For reference, here is a log file from my machine when I do the same exact test netman2.log
not lazy:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
:lua require'netman'.read('ssh://self/.bashrc')
✅
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
:lua require'netman'.read('ssh://self/.bashrc')
✅
my lazy config:
term:
nvim -c 'e ssh://self/.bashrc'
== nvim ssh://self/.bashrc
✅
nvim -c 'Nmread ssh://self/.bashrc'
✅
nvim -c 'lua require"netman".read("ssh://self/.bashrc")'
✅
nvim file view (nvim .bashrc
):
:e ssh://self/.bashrc
✅
:Nmread ssh://self/.bashrc
✅
lua require'netman'.read('ssh://self/.bashrc')
✅
neo-tree folder view (nvim .
):
:e ssh://self/.bashrc
✅❌loads content twice
:Nmread ssh://self/.bashrc
✅❌loads content twice
:lua require'netman'.read('ssh://self/.bashrc')
✅❌loads content twice
yeah i have no idea why it gets called twice
this is my lazy load code in netman's (neo-tree's actually) init
vim.api.nvim_create_autocmd('BufEnter', {
group = vim.api.nvim_create_augroup('RemoteFileInit', {clear = true}),
callback = function()
local f = vim.fn.expand('%:p')
for _, v in ipairs{'sftp', 'ssh', 'scp', 'docker'} do
local p = v .. '://'
if string.sub(f, 1, #p) == p then
vim.api.nvim_clear_autocmds{group = 'RemoteFileInit'}
vim.defer_fn(function()
require'netman'.read(f)
end, 0)
break
end
end
-- omitted: similar netrw clause for dav, fetch, ftp, http, rcp, rsync
})
if i run the command again to reopen the file it loads once and works
So interestingly, I am noticing that when I execute Nmread
after opening a directory with nvim .
(which loads up neo-tree), Neovim closes instead of doing anything.
You are not seeing that behavior which now has me wondering what is different between our 2 setups. Can you provide me a minimal replication config?
i am unable to replicate nvim closing https://h.00t.in/m/min.lua
It's likely my neotree configuration. What would be most beneficial to me is to isolate your issue in a minimal reproducible configuration. Can you provide me one with just the bare minimum needed to recreate your issue you're seeing when you open up a directory and then execute Nmread
?
my lazy config is somehow the issue but i have no idea how since it just calls .read, i'm assuming events are fired in a weird order and the call interrupts an already opening copy of Nmread
when netman is set to lazy, -c .read
works fine, but -c Nm
not, despite lazy.nvim supposedly loading the plugin before running the command
this only happens from the commandline, and the plugin loads correctly when either get ran after vim enters
Ya that makes sense. If you are lazy loading Netman, it can't define the vim commands (since you are never loading Netman). Thus, :Nmread
literally doesn't exist and therefore nothing happens when you call it.
There is really no reason to lazy load Netman.
lazy.nvim can be set up to catch commands that will exist after a plugin loads, and the plugin does load, just doesn't load correctly
netman is currently not loaded, lazy.nvim is creating fake commands that will load the plugin then run the real one:
this works when ran after
VimEnter
it loads the file twice when ran as nvim -c 'Nmread ssh://self/.bashrc'
it isn't that big of a deal to not lazyload netman, but it would be nice if it was possible to do so
it isn't that big of a deal to not lazyload netman, but it would be nice if it was possible to do so
While I can respect your specific usecase, lazyloading Netman is not something I will be supporting. Netman is a framework and part of its framework is doing exactly what you have coded in your lazy configuration.
If you remove lazy loading of netman, can you confirm that things work 'as expected'? in this new branch?
after a clean install i'm having the same issue without my lazy load code with both -c
options (e
works)
really weird
Please provide me a minimal reproducible configuration so I can replicate and test on my local system.
'doing the same thing and expecting different results' is called crazy, but that's what i'm experiencing, literally every time i do a clean reinstall something else happens lol
When using the netman GUI integrated into neo-tree, remote files can be opened. When using Nmread however (and netman:read), they do not open.
Log: https://h.00t.in/m/netman.log
I'm the person on Debian, running the v1.15 branch.