Not sure about 1, but 2 and 3 both have the same answer. Both TSInstall and Mason are just trying to install other software packages on your system, and you’re on NixOS, so of course they can’t do that. You don’t install your software, you declare it. Add the Treesitter parsers you need right next to your plugins (there is a sub collection under the vimPlugins collection just for Treesitter parsers), and put whatever Mason would be installing into your user packages instead.
That said, I agree with the other commenter. Even though the community has done a lot of work on rich config options for Neovim, they’re just too far away from the normal way of doing things in the Neovim world, and plenty of plugins are written in ways that assume it’s configured in “normal” ways. Plus configuring Neovim is already kinda like assembling your own car from parts in any case, so it’s honestly better to just use nix to install Lazyvim or whatever flavor of choice and let it handle the plugin management/config. And believe me, I really tried to do it all in Nix, I wanted to do it that way. But it’s just not worth the headache at this point
Thanks for this feedback, it helps me feel a little bit less stupid :) With everything setup in NixOS documentation for neovim in appearance I thought really dumb to not be able to have it worked.
Using the approach proposed by @flashgnash (i.e. using lazy.vim) let me install neovim and all my plugins.
It’s also a nightmare if you want your config to work with both nix and non nix platforms. If I’m using my config on windows or at work, I’m not going to have nix and home manager to interpret the nix version of my vim config. On my systems with home manager, I’d like be able to install my nvim config as part of home manager rebuild. If I have home manager pull my configs git repo, it causes lazy to freak out whenever I try to update my plugins. It’d be nice to have some sort of integration with lazy that exists with cargo and similar tools but it doesn’t look like anyone’s been working on it.
Have tried this myself and never had much luck trying to install nvim plugins via nix.
I’ve found the best way is to just use the plugin managers built for neovim, I’m not sure if this applies to all of them but lazy.nvim seems to be fairly declarative anyway, have home-manager map a directory to .config/nvim/ and away you go
As a side note though I think it is rather silly just how many different neovim package managers there are, which at the end of the day all do the same thing in very similar ways
Thanks for the feedback. I’m used to packer but it’s not maintained anymore so may be a good time to switch to lazy.
I’ll see if I can have it work in NixOS.
I have no idea, from what I gather there aren’t all the packages
I’m not sure what if anything installing them via nix does I’ve just come to the realisation it’s already declarative so why would people bother getting it working under nix
As other comments point out, they are usually not properly packaged through nix.
If you read the , for most plugins, the derivation just downloads the plugin, puts it to nix-store, and makes it available to the editor through environment variables. So it’s similar to the binary distributed software. Two most notable restrictions:
Nix is not aware of transient dependencies.
The plugin is not aware of the nix-store model.
So for plugins that don’t have external dependencies (or dependencies other than the “common” ones like python or sh that happen to be available), and that don’t interact with the filesystems, this approach would be fine, but the more complex ones would fail.
In your example, mason failed because of 1, home-manager wasn’t aware that the pip module is a transient dependency of this plugin; and treesitter failed because of 2, because it doesn’t know that nix-store is read-only and should be managed by nix.
There are no general solutions, but people may have nixified some plugins on a case-by-case basis. If you don’t want to spend a lot of time (and remember that it might be broken by the next plugin upgrade), as others have suggested, take the traditional plugin management approach. (Personally, I use LunarVim which uses Lazy.nvim and it’s been working fine.)
Not the installation strictly speaking, but my most “funny” fuckup was setting up xfree86. There was a configuration for crt monitor scan frequency that you had to setup. I messed up something and the monitor started to squeel like crazy and quickly hit hard reset in panic.
The monitor didn’t die, but it had a slight high pitch noise to it after.
Back then I was testing modelines to see the maximum I could push to my 14" monitor. I then backed it with a 1200x1600 virtual screen.
My girlfriend got sick from watching me scrolling around and bought me a 19" display which could do that resolution - and ended up frustrated when I added a larger virtual screen.
Yeah, monitors were somewhat dumb, just received and did what the vga output asked to do.
The noise most likely came from the semiconductors that controlled the magnet field that directed the rays onto the screen. These components are selected for a specific speed that the monitor can handle. So going under or over it’s spec can make something resonate in the audible range, and could even destroy the components if stressed too much.
The thing is that for each resolution and refresh rate you had two values to configure, one for the vertical speed in Hz, and horizontal speed in kHz. These values were usually specified in the owners manual. Typos can happen, and this was quite a risky operation.
A few years ago I was having obscure audio problems on Ubuntu so I tried replacing pulseaudio with pipewire. I was feeling pretty cocky with using the package manager so I tried
sudo apt install pipewire
Installed successfully, realized nothing changed, figured maybe I had to get rid of pulseaudio to make it stick.
sudo apt remove pulseaudio
Just two commands. Instant black screen, PC reboots into the terminal interface. No GUI. Rebooting again just brings me back to the terminal.
I fixed it eventually, but I’m really not very computer literate despite using Linux, so I was sweating bullets for a minute that I might have bricked it irreversibly or something.
I once did an apt-get upgrade in the middle of when debian testing was recompiling all packages and moving to a new gcc version. I get it, using testing invites stuff like this. But come on, there should at least be a way to warn people beforehand.
Car: Hey, your car is going at 60 mph now. Do you want to change your tire now?
Me: Is it not possible?
Car: It’s your car, anything is possible with enough effort. As per Google one guy managed to change a tire of a bullock cart while it was moving at 2 mph.
In my personal experience, these sort of things happen rarely, unless you are using some sort of rolling-release distribution. For all my mission-critical docker apps, I wait for at least a week after a major update has been pushed and check the dev website.
Edit: Note that the NixOS option puts in the full path to pam_fprintd.so. That’s necessary because NixOS doesn’t put so files in search paths.
Without doing more research I don’t know how to add arbitrary options to pam files in case you run into something that isn’t mapped to a NixOS option yet. The implementation for the pam options is here; there might be something in there that would work.
Well, if you didn’t replace grep with gnu/grep then you should call it belllabs/gnu/linux. Oh and don’t forget canonical for consistency: canonical/belllabs/gnu/linux
Keep in mind to sort the complete list by cpu cycles used by each of the projects on your specific system in ascending order. Maybe you can write a canonical/belllabs/gnu/linux script to automatically keep track and output an up to date string for easy proper nomenclature.
I generally agree with the message behind this sarcasm, but in this specific case OP really is learning the GNU utilities in particular (via Linux) so I don’t mind the extra nomenclature.
I appreciate the writeup and that you’ve taken the time to post about it here, however I am 100% leery of managing remote access or credentials using closed source software. I’ll definitely keep an eye on the project, but it’s a hard pass for me until the app is fully open source.
Back when I started using Linux, I really wanted something that was super different from windows (I used Gnome 3 for like 3 years). I decided one day to try out Fedora cause, hey, I can live on the bleeding edge.
Second day I had it installed, I was having issues with the audio. Decided to try reinstalling pulse. Apt autoremoved it and somehow completely nuked the entire GUI. Stuck in terminal mode, I found that I had no ethernet to connect to, nor could I figure out how to connect to a wifi network with a password or download packages to a USB. After a couple hours, I gave up, wiped the drive, and went back to Mint.
Same thing happened to me! I was on Ubuntu, trying to replace pulse and when it got removed instantly kicked me to the terminal. Eventually I fixed it but now I also just Mint, lol
I see an issue about providing sudo credentials that has been resolved as “implemented” but I can’t figure out where you do that for a connection that you’ve ssh’d into as a user.
It uses the sudo credentials from the SSH connection, even if you don’t need to provide a password to login. So if you set a password for a SSH connection, it should use that for the sudo elevation.
Have you considered embedding a terminal editor in the actual program? I use mRemoteNG on windows, and the integrated rdp/ssh with a sidebar full of bookmarks is the dragon I’ve been chasing on linux.
If this had remmina and vnc, and could embed terminals, it’d be a huge feature jump in my book (though it’s already great as a better way to manage my ssh sessions)
As a sole developer I have to prioritize features due to the time constraints. While I would definitely like to implement support for everything you listed, this would be a lot of work. For example with terminals in general, it can be very difficult to get one up to the standards of other comparable terminals. By delegating everything to other terminals, I can make the development easier.
So in the long term future this might be added. But that also depends on the project’s trajectory going forward
For sure for sure. What is your preferred mechanisms for feature requests? Small things, like in the browser pane, could we get buttons to launch terminals directly in the connections tree on the left, so I can launch the terminal without having to open the file browser for that connection, or likewise, adding a link in the connections pane to jump straight into the file browser? I envision a workflow where I keep 1 view open and can launch into file browsing or terminal directly from that view.
You can send me feature requests either on GitHub, Discord, or mail, whatever you like.
Your proposed enhancements make sense, I can already think about how to add this the best way. And if you want to open a proper feature request and elaborate more on that, we can make that happen for sure.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.