[Bug] Nmread does not work

[Aonodensetsu]

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.

[Aonodensetsu]

I'm working on fully lazy-loading neo-tree, which is why I found this to be a thing.

on BufEnter:

[miversen33]

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 :)

[Aonodensetsu]

cool, but as I said the same applies to :Nmread, so that does not fix my issue

they seem to work under specific circumstances:

• the second or later time :Nmread or .read is executed
• for files

the file list does not open for folders, and trying to do as i'm doing even with defer, does not work

[miversen33]

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.

[Aonodensetsu]

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

[miversen33]

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

[Aonodensetsu]

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

[Aonodensetsu]

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

[miversen33]

Perfect :) I don't suppose getting you on main fixed this issue though, correct?

[Aonodensetsu]

no, still on the second attempt it also seems to not set the filetype sometimes

also :e seems to never work

[Aonodensetsu]

the 'fetching file' alert shows up every time, even if it doesn't actually open the file

[miversen33]

: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?

[Aonodensetsu]

: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

[Aonodensetsu]

: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

[miversen33]

That's a whole lot of weirdness going on. I really appreciate the screenshots :)

[miversen33]

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

[miversen33]

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.

[miversen33]

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.

[miversen33]

@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

[Aonodensetsu]

.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

[Aonodensetsu]

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

[miversen33]

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?

[Aonodensetsu]

file type, buffer name eg the file content is set, the properties not

[Aonodensetsu]

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)

[miversen33]

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.

[Aonodensetsu]

the properties that i listed in that message, file type and buffer name only the content of the file is put into the buffer

[miversen33]

Well, that is very strange. I will keep poking. Thank you so much for your help with this :)

[miversen33]

@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

[Aonodensetsu]

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>

[Aonodensetsu]

.read was changed?

[Aonodensetsu]

ah wait my bad, this is in the lazy code, but i am testing without lazy now

[miversen33]

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

[Aonodensetsu]

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>

[Aonodensetsu]

https://h.00t.in/m/netman.log -c '.read' with lazy disabled

[miversen33]

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

[Aonodensetsu]

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

[Aonodensetsu]

yeah i have no idea why it gets called twice

[Aonodensetsu]

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
})

[Aonodensetsu]

if i run the command again to reopen the file it loads once and works

[miversen33]

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?

[Aonodensetsu]

i am unable to replicate nvim closing https://h.00t.in/m/min.lua

[miversen33]

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?

[Aonodensetsu]

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

[Aonodensetsu]

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

[miversen33]

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.

[Aonodensetsu]

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

[miversen33]

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?

[Aonodensetsu]

after a clean install i'm having the same issue without my lazy load code with both -c options (e works) really weird

[miversen33]

Please provide me a minimal reproducible configuration so I can replicate and test on my local system.

[Aonodensetsu]

'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