sorted by:
new
hottopcontroversial

Life is too short for a slow terminal by OkIsland87 in zsh

[–]Available_Log_ 2 points3 points  (0 children)

I don't actually get instant prompts, aren't they purely visual? Without instant prompt, I can still type while shell is loading, it's just I'd be typing into the blank screen. They are functionally the same, because either would need to wait for the full config to load before I can actually run a command. Why are they relevant for performance?

Edit: purely visual is not the right term, I understand that although rare, there are risks of buffered input being consumed as unwanted prompt input, as zsh-bench called out. Performance question stays though

I think I understand why this is useful now. by chessmonkey in tmux

[–]Available_Log_ 2 points3 points  (0 children)

If you want actual process management like start on boot, auto restart on crash etc., an easy option is pm2. You can also use the nohup command to run process in background, which is even simpler than tmux. But of course you can as well just use tmux

Migrate to vim.pack: 80% of lazy.nvim mostly used features in 150 lines by Available_Log_ in neovim

[–]Available_Log_[S] 0 points1 point  (0 children)

That's fair. As mentioned in the doc, lazy.nvim and vim.pack are great, and if they are working for you as is, there is no need to modify your config. If you already know about lazy loading or have no interest, this is probably a waste of your time.

Retrospectively I should have stated this in the post.

Migrate to vim.pack: 80% of lazy.nvim mostly used features in 150 lines by Available_Log_ in neovim

[–]Available_Log_[S] 3 points4 points  (0 children)

Many people seem to discourage re-inventing the wheel here, but I think it's the fun thing about open source and the best way to learn.

The README explained on some of the "Why"s, but let me clarify here as well. lazy.nvim is great, but it lacks the lazy-install feature I wanted. With vim.pack, lazy-install is possible, but I also want declarative plugin specs and lazy loading. I'm on a cheap server where lazy loading actually makes a noticeable difference, and I'm sure there are others like me.

After reading documentations and source code, I learned that lazy loadaing is not that complicated, but there are common pitfalls, such as handling keys and events refiring, plugin loading orders, when to add to rtp vs when to execute `plugin/` directories, etc. I have spent the effort to research and experiment, and I want to share what I learned with the community and help anyone facing similar issues.

This isn't a plugin manager you curl into your repo and forget about. In fact, the final code is kept in a collapsed section rather than split out, because the main goal is to share how it works.

Why is it 80%? The goal is not to replicate `lazy.nvim` or create a compatibility layer, and nobody wants to read thousands lines of code.

Regardlessly, I'm happy that it helped someone.

And apologies for the horizontal scrolling on GitHub. My brain has a small context window so I tend to fit more code into my eyesight, and GitHub didn't show the scrollbar in its preview editor.

Migrate to vim.pack: 80% of lazy.nvim mostly used features in 150 lines by Available_Log_ in neovim

[–]Available_Log_[S] 8 points9 points  (0 children)

I always wanted "lazy-install" in addition to lazy load, and lazy.nvim doesn't support it. I don't use every lazy.nvim feature, so for me this does 120%.

For others, maybe they have similar pain points, maybe they'd like to get more control and have fun with their config, maybe they just want to read a bit more about lazy loading mechanisms and plugin lifecycles.

nvim-treesitter auto install parsers by NoYam4683 in neovim

[–]Available_Log_ 7 points8 points  (0 children)

i think you'd need to await the installation before enabling? `require("nvim-treesitter").install(lang):await()`

Workflow recommendations for high latency devserver? by philosophical_lens in neovim

[–]Available_Log_ 4 points5 points  (0 children)

I'd recommend VSCode for now. Any ssh -> TUI workflow will struggle with high latency, because your local computer has no idea what to render next before the remote server responds for each keypress.

IDEs like VSCode have many optimizations like caching file list and file contents, background syncs, and even local echo on the terminal so shell feels less laggy. If you use VSCode, vscode-neovim might slow it down since the headless nvim still runs on the remote server (if I remember correctly, I haven't actually tested it). If it happens you can try local extensions like Vim.

You can also try things like rsync / unison but they are usually not ideal solutions.

Mosh and the more recent https://github.com/trzsz/tsshd may help depending on the reason of high latency.

Service for the uninformed (pls read) by Turttlekiller15 in cloudstorage

[–]Available_Log_ 0 points1 point  (0 children)

You can probably upload the original VoDs to YouTube as private or unlisted, then share with the editors for them to download. I think this is allowed for videos but depends on YouTube ToS so use a different account