languages/http: init

[snoweuph]

Adds support for the JetBrains HTTP Language/Format

Closes: #1663
Closes: #1641

Needs: #1744

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from 8ec79d5

View it here:

Debug Information

Triggered by: snoweuph

HEAD at: http

Reruns: 3803

[snoweuph]

Currently doesn't work, due to missing CLI deps from PATH.
opened an Upstream Feature Request for the new config options.
mistweaverco/kulala.nvim#961

[snoweuph]

Required Compat was added Upstream, works as expected :3

[gorillamoe]

DISCLAIMER: As I'm not familiar with nix, I could be totally wrong reading what this PR does.

I just wanted to mention that if it's true that nix ships with kulala-fmt (+ the required kulala-core version by kulala-fmt) and you use the same version (of kulala-core) in kulala.nvim and kulala-fmt, that is probably going to break things.

The whole reason I made it this modular, is that not every update needs to exist in all tools. Some things that we fix (like the oauth browser flow) in Core, don't need to be pushed to the formatter. The formatter never touches anything oauth related.

So the formatter is sometimes quite a bit behind when it comes to the core version it requires.

But we also already had it the other way around, there were things added to core to support certain features in kulala-fmt and then kulala-fmt had a newer kulala-core dependency than kulala-cli, kulala.vscode and kulala.nvim and kulala for desktop 🤷🏾

So: There is no guarantee that version xy of core will work in all tools at the same time.

That's why all tools have a specific version constrained attached to them.

[snoweuph]

DISCLAIMER: As I'm not familiar with nix, I could be totally wrong reading what this PR does.

I just wanted to mention that if it's true that nix ships with kulala-fmt (+ the required kulala-core version by kulala-fmt) and you use the same version (of kulala-core) in kulala.nvim and kulala-fmt, that is probably going to break things.

The whole reason I made it this modular, is that not every update needs to exist in all tools. Some things that we fix (like the oauth browser flow) in Core, don't need to be pushed to the formatter. The formatter never touches anything oauth related.

So the formatter is sometimes quite a bit behind when it comes to the core version it requires.

But we also already had it the other way around, there were things added to core to support certain features in kulala-fmt and then kulala-fmt had a newer kulala-core dependency than kulala-cli, kulala.vscode and kulala.nvim and kulala for desktop 🤷🏾

So: There is no guarantee that version xy of core will work in all tools at the same time.

That's why all tools have a specific version constrained attached to them.

The Formatter (which is handeled by conform) is independent of the plugin.
So a user can just enable the formatter but not the plugin.

thanks to the way linking works in nix, there is no kind of conflict between formatter and extensions.

and you use the same version (of kulala-core) in kulala.nvim and kulala-fmt

We dont use the same. kulala-fmt from nixpkgs, is activly linked against its version of core,
and for the plugin we currently rely on the download mechanism.

[gorillamoe]

Yes, could be still me not knowing nix but all kulala tools have a core dependency (Kulala-Core). They don't ship with it, but download it on demand. This version differs per tool. They download the dependency in the platforms cache location though in a structure like .my-platforms-cache-dir/kulala-fmt/bin/kulala-core/. They put a version.txt and the binary there. If the version.txt contents don't match the actual requirements and you don't force a core path via env var KULALA_CORE_PATH or something like setup opts in kulala.nvim they'll try to update.

I'm not sure how that is handled by nix, since I heard that nix says it's immutable.

With tools like kulala that isn't the case anymore, if you don't download the core yourself build it and then set at least the env var.

Sorry, if this is totally wrong and already covered by nix.

Or my definition of immutable is different than what nix offers. Downloading a dependency during runtime isn't immutable to me.

[snoweuph]

the kulala fmt in nixpkgts is actually pretty old, its at 1.4.0, so it still has everything bundled lmfao.

I feel like we should package the whole thing from scratch for NVF 🤔

[snoweuph]

Noticed another problem,
By updating to Npins isntead of outdate plugin version from nixpkgs, I see that the LSP now also needs to be packaged separately.

[snoweuph]

TODO: package myself

[snoweuph]

rebased

[snoweuph]

rebased

[snoweuph]

rebased

[snoweuph]

rebased

[snoweuph]

cool github closes MRs when you rename a branch :/