Skip to content

New requests added to http file are not detected until reload #508

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

Closed
2 tasks done
YouRik opened this issue Jan 12, 2025 · 9 comments · Fixed by #521
Closed
2 tasks done

New requests added to http file are not detected until reload #508

YouRik opened this issue Jan 12, 2025 · 9 comments · Fixed by #521
Assignees
Labels
bug Something isn't working

Comments

@YouRik
Copy link

YouRik commented Jan 12, 2025

Prerequisites

  • I am using the latest stable release of Neovim
  • I am using the latest version of the plugin

Neovim Version

v0.10.3

Operating system/version

macOS 15.2

Actual behavior

rest.nvim does not detect new requests added to an http file. It only detects requests that were present when the file was opened, therefore, when adding a new request to a new file or an existing http file, one has to manually reload it before executing new requests.

Expected behavior

rest.nvim should detect new requests added to http files before trying to find them in the file.

Steps to reproduce

  1. Open a new http file
  2. Add a new http request
  3. Save the file
  4. Run Rest run
  5. Observe that rest.nvim was unable to locate the request at cursor position
  6. Run :e! to reload the file
  7. Run Rest run
  8. Observe that rest.nvim is now able to detect the request in the file correctly

Other information

No response

Repro (lazy.nvim)

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
    spec = {
        "rest-nvim/rest.nvim",
        {
            "nvim-treesitter/nvim-treesitter",
            build = ":TSUpdate",
            main = "nvim-treesitter.configs",
            opts = {
                ensure_installed = { "http" },
                sync_install = false,
                highlight = { enable = true },
                indent = { enable = true },
            },
        },
    },
})
@YouRik YouRik added the bug Something isn't working label Jan 12, 2025
@boltlessengineer
Copy link
Contributor

You mean that rest.nvim can't detect the file update outside of neovim?

@YouRik
Copy link
Author

YouRik commented Jan 13, 2025

No, I mean inside of neovim. Changes to existing requests are read correctly. But adding new requests into an http file, without reloading the file, has rest.nvim not detect the newly added request until reloading/reopening the file.

@boltlessengineer
Copy link
Contributor

That's weird. My usual workflow is to open a http file, write new request, run it and delete it and it totally works fine.

I think you are writing wrong syntax or there is a parser bug. Can you try with these steps?

  1. open a http file with this content
    ### request 1
    GET https://example.com
  2. set cursor position to line 1~2 and try :Rest run. It should work fine
  3. modify the file in same neovim session
    ### request 1
    GET https://example.com
    
    ### request 2
    GET https://github.com
  4. set cursor position to line 4~5 and try :Rest run. It should work fine either.

@YouRik
Copy link
Author

YouRik commented Jan 13, 2025

rest.nvim.mov

I have created a small video here to showcase the issue.

  1. I run the query in a new file without saving.
  2. I run again after saving.
  3. I run the query after reloading, only then it works

@YouRik
Copy link
Author

YouRik commented Jan 13, 2025

rest.nvim.mov

Here is another video showing adding a new request. Again, it is only correctly detected after file save + reload/reopen

@boltlessengineer
Copy link
Contributor

That's strange. Maybe tree-sitter parser is not attached to the buffer before reloading..?

Can you reproduce it with minimal config above?

Save this code as repro.lua and open neovim with nvim -u repro.lua. It will create .repro/ folder in current directory for isolation.

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
    spec = {
        "rest-nvim/rest.nvim",
        {
            "nvim-treesitter/nvim-treesitter",
            build = ":TSUpdate",
            main = "nvim-treesitter.configs",
            opts = {
                ensure_installed = { "http" },
                sync_install = false,
                highlight = { enable = true },
                indent = { enable = true },
            },
        },
    },
})

@YouRik
Copy link
Author

YouRik commented Jan 13, 2025

It works fine with that minimal repro config.
So yes it seems something else must be the cause, though I can't imagine what it might be. I don't think tree sitter is not attached before reloading, because it works if I open a file that already as requests in it. Only newly added ones are not detected, until reload

@boltlessengineer
Copy link
Contributor

boltlessengineer commented Jan 13, 2025

I'm pretty sure that this is tree-sitter configuration issue but can't really tell without your config.

It seems you don't have any highlights in http file format.
I tried with disabling tree-sitter highlighting with highlight = { enabled = false } and found that I can reproduce your issue.

You try these steps:

  1. open some http file
  2. run :lua vim.treesitter.start()
  3. test if bug still exists

If running :lua vim.treesitter.start() before everything fixes your issue, I guess you didn't enabled tree-sitter highlighting. It can be enabled via plugins like nvim-treesitter and rocks-treesitter.nvim or by adding this autocommand to your config:

vim.api.nvim_create_autocmd("FileType", {
  pattern = "http",
  callback = function(ev)
    vim.treesitter.start(ev.buf, "http")
  end,
})

Please tell me if this fix your issue!

Edit: done

@YouRik
Copy link
Author

YouRik commented Jan 14, 2025

Thank you very much @boltlessengineer for the support and time investigating this issue for me, this did in fact fix the problem!

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

Successfully merging a pull request may close this issue.

2 participants