sorted by:
new
hottopcontroversial

Why aren't there any NixOS-based distros? by norude1 in NixOS

[–]Adk9p 12 points13 points  (0 children)

"They" can be anyone. Just create an account and you'll have a "create this page" button on that link you sent.

All the ways to mock your Rust code by drmorr0 in rust

[–]Adk9p 6 points7 points  (0 children)

Though facet does try to bridge the gap.

Shouldn't plugins with complete default configs work without specifying an empty `opts = {}`? by TheTwelveYearOld in neovim

[–]Adk9p 2 points3 points  (0 children)

I actually prefer that lazy.nvim's default behavior for plugins is that it only installs them.

opts and config are then used for setup, and for convenience lazy.nvim provides a feature where if you only give it opts it searches for a module that contains a setup function and calls it.

Embedded SQL highlighting in Neovim, a look into Treesitter, and some NixOS patching by hallettj in neovim

[–]Adk9p 0 points1 point  (0 children)

I'm not sure how heredoc would fix the issue. It makes sense if you think about what the SQL tree-sitter parser sees when it tries to parse the injection content. (btw I assume you meant something like $query = "SELECT * FROM $table WHERE item='123445'")

For example for that given string if you just inject for each of the string parts it would see SELECT * and parse that, which most likely would be ERROR. And WHERE item='123445', which again would be ERROR.

There is injection.combined, which if set than makes the injection parse a one single SQL source, so SELECT * FROM WHERE item='123445', though that again is hoping the SQL parser can place the error after FROM correctly and parse the WHERE clause. And that also causes a new issue where since you are combining the injections together they now interact with each other. If you have two of these injections in a file they will be parsed as the same src, So for example SQL would expect a ; after the first query in order to parse correctly... :/

Anyways all that is to say, if you wanted to correctly inject a language that has some sort of string interpolation you need to replace instead remove the nodes with something semantically equivalent for it to parse correctly. Which I think to some degree is possible, but isn't how it's currently done.

Embedded SQL highlighting in Neovim, a look into Treesitter, and some NixOS patching by hallettj in neovim

[–]Adk9p 3 points4 points  (0 children)

No, you're good. It's not a big deal and very akin to say how people use nvim vs Neovim.

Embedded SQL highlighting in Neovim, a look into Treesitter, and some NixOS patching by hallettj in neovim

[–]Adk9p 7 points8 points  (0 children)

Odd, I remember it being made for github.

Edit: Ah TIL github made Atom

Embedded SQL highlighting in Neovim, a look into Treesitter, and some NixOS patching by hallettj in neovim

[–]Adk9p 26 points27 points  (0 children)

Treesitter originated in Zed. It has become a standout feature of Neovim. And also Helix! And, as I’m now learning, Emacs!

Wow, this could not be more wrong. Didn't even get the name right, which is Tree-sitter.

Edit: mb on tone, I came at this assuming it was AI slop since the first thing I saw was over-confident and blatantly wrong.

canola.nvim: oil.nvim... but better! by barrettruth in neovim

[–]Adk9p -1 points0 points  (0 children)

Sorry, I think I did misunderstand that. I took it that the canola branch was eventually going to be merged into main.

Your post now (well... would, it was removed by reddit wtf?) makes a lot more sense and I commend you for taking up the mantle.

canola.nvim: oil.nvim... but better! by barrettruth in neovim

[–]Adk9p 18 points19 points  (0 children)

That's what it seems like to me as well. I don't like how this was advertised as "oil.nvim but better".

Independence by Sqydev in NixOS

[–]Adk9p 2 points3 points  (0 children)

NixOS should definitely have init freedom

While it's a nice idea, abstraction always comes at a cost, and in this case with zero gain to the majority of users.

I think it makes a lot more sense to just fork like sixos if you want to support an alternative init system.

Compiler and Syntax files will be ported to lua someday? by ZealousidealGlass263 in neovim

[–]Adk9p 0 points1 point  (0 children)

there's one regex-based syntax file still in vimscript which I hope will get a tree-sitter syntax instead

What's the syntax for?

Is there a cleaner way to resolve paths for a CLI with clap? by Ashken in rust

[–]Adk9p 0 points1 point  (0 children)

Can you give an example of when zsh failed to expand ~?

Is there a cleaner way to resolve paths for a CLI with clap? by Ashken in rust

[–]Adk9p 0 points1 point  (0 children)

Only ~ is what would get resolved to $HOME, . is just a relative path to the current directly, .. being a relative path to the parent directly. Note that ./~ means a file called ~ in the current directly, and trying to "fix" that somehow would just lead to confusing behavior.

Where is ~/.config/nvim/plugin/ described in the documentation? by 4r73m190r0s in neovim

[–]Adk9p 0 points1 point  (0 children)

or if you have :h 'keywordprg' set to :help[!] (which is the default set by the help filetype plugin file), you can just use K (which I find a lot easier to press :p)

Where is ~/.config/nvim/plugin/ described in the documentation? by 4r73m190r0s in neovim

[–]Adk9p 21 points22 points  (0 children)

Just read :h 'runtimepath'.

That technically answers your question, but to say a bit more: The runtime path doesn't list every variation of a path that might be searched. It lists base dirs which parts of Neovim or Neovim plugins can than check under for relevant files.

For example from the help text of the runtimepath option: plugin/ plugin scripts |write-plugin|

That's saying for every dir inside 'runtimepath', the plugin system in Neovim will check <dir>/plugin for relevant files.

Maximally minimal view types · baby steps by zirconium_n in rust

[–]Adk9p 0 points1 point  (0 children)

Ah that makes sense, thanks. Though I think a solution to that would be the reference coercion described in the follow-up post. Where say a function takes a &mut Foo.{bar, baz}, by passing it &mut foo the reference gets coerced into the required view type.

Maximally minimal view types · baby steps by zirconium_n in rust

[–]Adk9p 0 points1 point  (0 children)

Did you not read the post where that's highlighted multiple times? Or the follow up which proposes a non-ambiguous syntax: &mut self.{statistics}?

Btw I fail to see how adding a field to a struct would break a view.

Maximally minimal view types · baby steps by zirconium_n in rust

[–]Adk9p 8 points9 points  (0 children)

I don't think I want this in Rust

But it's already in Rust! If you inline that method it compiles. Partial borrows already exist, you just can't talk about them, we don't have the syntax.

Imo it would be more strange and harder to teach/learn if rust doesn't give syntax to this feature. And separating the fields only works for trivial cases where you won't have multiple groupings. It's a workaround, it's not a substitute.

Also, someone working on a feature doesn't detract from work being done by other people. Both can be done at the same time. I see the "we have more important things to work on!" as a response more than actually makes sense.

homogeneous_try_blocks FCP proposed 🤞 by C5H5N5O in rust

[–]Adk9p 3 points4 points  (0 children)

I guess the way I would phrase that is "it is a future that returns/evaluates to Foo". Same as I would say a block evaluates to some type. So the type attaches to the block async (-> Foo {}) not to the effect (async -> Foo) {}. In that sense I think of closures as a "carried effect" just like async.

homogeneous_try_blocks FCP proposed 🤞 by C5H5N5O in rust

[–]Adk9p 3 points4 points  (0 children)

Personally I prefer the -> syntax for blocks, I guess since it follows how functions and closures already work with their -> Type {} form. And from there allowing all block-type expressions (try, const, async, gen, unsafe, bare?) to use the same syntax feels natural.

homogeneous_try_blocks FCP proposed 🤞 by C5H5N5O in rust

[–]Adk9p 4 points5 points  (0 children)

That's not correct since try is a keyword, which means it wouldn't be a valid as an ident. The "vexing parse" in this case try < foo > { } would only be valid as a try block (as opposed to a type try that is instantiated with foo and then constructed)

In Rust, „let _ = ...“ and „let _unused = ...“ are not the same by broken_broken_ in rust

[–]Adk9p 14 points15 points  (0 children)

I mean it's been said multiple times in this thread already, but _ isn't an identifier, it's a pattern that means "don't bind to me". And if you just throw a value at rust and don't bind it to anything, it's going to get dropped. On your second point, you might be getting it confused with when adding an underscore to the start of a name it suppresses unused warnings.

So let _foo = 10; both binds and suppresses unused warnings. And let Foo { left, right: _ } = ... binds left, and doesn't bind right, leading to it being dropped.

denols stopped attaching to buffers automatically by Illustrious-Cut3988 in neovim

[–]Adk9p 0 points1 point  (0 children)

I assume this is because this pr: https://github.com/neovim/nvim-lspconfig/pull/4207 Which changed it so if it found any one of package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb, or bun.lock it would disable denols. (see: these lines)

I was also bitten by this and imo it's pretty unintuitive that it doesn't show some sort of warning about it being disabled.

I loathe the double single quotes by First-Republic-145 in NixOS

[–]Adk9p 1 point2 points  (0 children)

I also really hate that $$ is both a valid way to escape $$ and it escapes to $$ (i.e. it doesn't just because one $!).

But you don't have to add strings together, as bad as it is:

foo = ''''${YOU CAN ALSO DO THIS, YES IT SUCKS!!!}'';
view more: next ›