andersevenrud
u/andersevenrud
If you want that pcall to work you have to change it to:
local ok, treesitter = pcall(require, "nvim-treesitter.configs")
The comma is important because pcall expects a function followed by the arguments you want to use, and not a regular require statement :)
Also, you don't really need to do this since you're lazy-loading. It should be available when you do the require from the config
callback.
AFAIK there's no common interface for adding something to cover all of the status bar plugins. It's usually something like lua/<statusbar-plugin/<component-name>.lua
that gets discovered and loaded so that the user can simply put a string with the <component-name>
in their configuration.
However, most of these status bar plugins supports referencing a function that returns some arbitrary text. So if you export this from your module and have appropriate documentation for this, it should be fairly easy on the end-user.
The solutions in this post should have what you need to create some conditions in your config based on os: https://www.reddit.com/r/neovim/comments/pc7in0/detect_os_in_lua/
In your case vim.fn.has('macunix')
would suffice if you're using Lua.
The equivalent of v:count
in Lua should be vim.v.count
.
Ah. The installer uses the language package manager behind the scenes. So it effectively runs the npm, etc. commands for you.
If you wanna automate the installation of language servers then check out:
https://github.com/williamboman/nvim-lsp-installer
This one installs them locally and sets the paths for you with a wrapper.
Someone might find this handy. I have this set up as an alias so I can get immediate output with nvim-startuptime
:
alias nvim-startuptime='rm /tmp/vim.log; vi --startuptime /tmp/vim.log -c "quit" && cat /tmp/vim.log'
I think you might be reading this wrong. The second column is the elapsed time for the given entry, so the sysinit script is loaded in <0.1ms.
Edit: Also, 100ms is just fine. It's literally the blink of an eye :)
Not all that much if you ignore the Lua part. It's based off the same palette, just different picks in some places.
Might just be the order you've assigned.
Maybe you could share your config ?
Eh... I somehow managed to paste the link to saga, and not the project I was thinking of. This one has preview windows:
Out of curiosity, have you tried https://github.com/wincent/terminus ? I haven't experienced this scrolling issue using tmux before, but this plugin helped with some other minor annoyances.
It's a pile of something alright :)
Just thought I'd leave an issue that discusses the topic of tsserver LSP implementation:
From the docs:
-
2021-07-28:
packer
will now highlight commits/plugin names with potentially breaking changes(determined by looking forbreaking change
orbreaking_change
, case insensitive, in the update
Well, the problem is that that would only work if the language used was something that actually used `require` for modules and that it happens outside any kind of abstraction. And the user would have to know this.
If the commit message simply explained this, then you would not even have to do a search in the first place. This is the point of commit messages, it should give you the abstract of what happened and some kind of reasoning/explanation if required.
Some sort of "dry run" function surely would be great. But imo this only works if the commit messages contains the information you need in order not to hit some kind of wall.
Having to review and understand the physical changes of commits of all your plugins now turns into code reviews, and not updates :(
This brings up a good point. Most of the plugins (at least that I use) doesn't really have any release cycle. Everything mostly goes into the main branch, which requires quite some attention on the end-user to catch everything.
AFAIK any of the vim package managers don't really use semver or anything like that either.
But in the cases where dependencies is not the breaking change, having some sort of leeway / migration path for users and a warning message is definitely a big help.
> I've never encountered issues that couldn't be fixed in less than 5 minutes
Those 5 minutes can be a bit of a pain though... I'd rather it be close to nothing :D
Just wanna add that to notify end-users about breaking changes is as simple as adding "breaking change" in the commit message.
In the case of packer users (or maybe others ?!) this will even highlight the plugin with a (orange in my case) color in the update log which makes it very easy to spot.
Commit messages in general is a mixed bag. In a perfect world everyone would use something like https://www.conventionalcommits.org/en/v1.0.0/ (which has the breaking changes stuff in the spec).
Going to try this one immediately. Thanks!
I've been looking for something like this. Works like a dream.
Thanks!
Don't wanna install another plugin for this, so I just ran with --startuptime
, and apparently 202.976ms.
Full log: https://gist.github.com/andersevenrud/a02b2917f2ead93f07344c3e3da49351
The colorschemes you linked does not seem to have highlighting for the latest neovim specific features. You'll have to look for alternatives like https://github.com/shaunsingh/solarized.nvim and https://github.com/ishan9299/nvim-solarized-lua.
Also, I'm not sure what you mean by "but why does it work with vim-plug then" because you didn't mention what colorscheme you originally used before you tried the ones that you linked.