refactor!: Refactor spec

[boltlessengineer]

refactor the parser following more well-known spec. This resolves most opened issues.

• change bunch of node names and fields
• make request method optionable
• disallow whitespace in front of request
• multi-line target_url by indented lines
• require blank line between URL+header & body
• require ### separator between each requests
• don't parse url scheme and stuffs (not worth it)
• support // comment
• allows whitespace in form-data
• variables are always parsed as raw string. numbers, true|false, quotes don't have any meanings
• response handler script will use {% ... %} syntax and injected language is javascript by default (unless you put # @lang=lua above)

fixed #18
fixed #19
fixed #29
fixed #30
fixed #31
fixed #33
fixed #35

I forgot to sync my local repo before I start working, I’ll rebase this manually soon.

• manual rebase from main
• update test cases

Edit: add todo

[NTBBloodbath]

Note: I'm not sure about adding rest.nvim stuff back, I've completely stopped working on the project and archived it. Unless someone is going to work on a fork or re-use some of the functionality it has, because this PR completely refactors the specs from what I understand.

@gorillamoe I'm not sure if you guys are using this http parser or reusing rest.nvim functionalities that were made possible by the parser (e.g. Lua scripting) in kulala.nvim, so I'd appreciate some input here if possible.

[gorillamoe]

We're just "relying" on the TS HTTP grammar for syntax highlighting. So it wouldn't break things for kulala ❤️

[boltlessengineer]

Unless someone is going to work on a fork or re-use some of the functionality it has

@NTBBloodbath You just discovered secret commit message. :)
Yes, I am working on rest.nvim fork since couple of days ago.

I'm rewriting most of the functionalities from v2 but it still shares same mindset (e.g. using tree-sitter for parsing, luarocks dependencies for many stuffs, same result & winbar UI)

Can I get access to rest-nvim project? If you want to keep rest.nvim archived, I can just make separate fork repo (like rest3.nvim or something) but since it heavily depends on this tree-sitter parser, it will be grateful if I can maintain both.
I was going to ask this when the fork is ready. It will take few more days to be done.

[NTBBloodbath]

Unless someone is going to work on a fork or re-use some of the functionality it has

@NTBBloodbath You just discovered secret commit message. :)
Yes, I am working on rest.nvim fork since couple of days ago.

I'm rewriting most of the functionalities from v2 but it still shares same mindset (e.g. using tree-sitter for parsing, luarocks dependencies for many stuffs, same result & winbar UI)

Oh, I didn't expect something like this to happen lol. Glad to know someone is doing it :p

Can I get access to rest-nvim project? If you want to keep rest.nvim archived, I can just make separate fork repo (like rest3.nvim or something) but since it heavily depends on this tree-sitter parser, it will be grateful if I can maintain both.
I was going to ask this when the fork is ready. It will take few more days to be done.

Sure, I don't see a problem with it. If you want to work on the existing repository, it can also be unarchived so whatever works best for you. I will send you an invitation to the organization right now, and let me know if you need anything else.

Cheers

[askfiy]

How is the current progress of this PR? looking forward.

[boltlessengineer]

@askfiy hi, as I’m also rewriting rest.nvim for v3 release in same time, I’m going to merge this PR when both plugin and the parser is ready.
Because both are having major version upgrades, I think releasing two v3.0.0 in same time makes sense.

rest.nvim rewrite is almost ready. I’ll open the v3 branch to public soon. It will be merged in a week or two.

[askfiy]

@boltlessengineer Thanks for your work, I'm also waiting for this PR to be merged to release the new plugin.