-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ref: granularize imports #451
Conversation
01e6709
to
cb2e720
Compare
cb2e720
to
f501e48
Compare
I am going to work on the pin animation, we might have conflicts, try to focus this PR on the essentials. |
f501e48
to
b9ef94b
Compare
I still see some imports with the
imho this PR has a lot of noise for the benefits that it provides. The only changes I'm happy to see are the highlight split and the fs functions. I'd rather do linting changes after we're done with the more complex ongoing changes. |
b9ef94b
to
dab0819
Compare
Oops, forgot to force push my last change. Done :)
Can you elaborate on why this seems like noise? It's all for the sake of trying to make things more consistent:
We do have a precedent of making maintenance changes before shaking things up (e.g. #418), because it makes further changes easier to make |
As I mentionned in formatting rules, I'd rather we incrementally do linting changes as we touch the code but it's really not a priority. The noise also comes from things like For now, could you revert the changes in |
68840d1
to
b3d3efc
Compare
Unfortunately the render code is tied in with it, because it also uses the split Either way, I've been using this for a bit so we can merge if you give the OK. If you want to wait until after your PR that's understandable, though I think applying #455 after this one is probably better since you're more familiar with the fixes that need to get patched in. Just let me know— don't want to mess up what you're working on :) |
If you do: ```lua require'barbar'.setup { icons = { diagnostics = { [vim.diagnostic.ERROR] = {enabled = true}, [vim.diagnostic.HINT] = {enabled = true}, }, }, } ``` …it will not work. This is because a function in `Buffer` was using `ipairs`, which stops upon reaching the first `nil` numerical index in a `table`. However, upon fixing this, I discovered another bug: `icons` was not being fully merged. We had a snippet of code to "deep extend" `icons.diagnostics`, but since we were only using `vim.tbl_deep_extend` on the other `icons` options, they did not inherit the diagnostics. I extracted this snippet to a function and called it on all `icons.modified`, `icons.current`, etc.
We reference distinct sides of the barbar often enough that it probably deserves its own alias.
We already had a `current_buffer_index` variable in `get_bufferline_containers`, so we can use that instead of storing all the activities of each buffer in their containers and looping over the buffers in each container looking for the current buffer, Apologies for the style changes; I was debugging something else, and had a really hard time reading this particular section. While reading through to understand the changes I discovered this performance improvement.
Removes unecessary `deepcopy`
b3d3efc
to
c3431aa
Compare
This PR is based on #446, so its diff will look better after that merges.
A few things here, which I think will help maintenance in the long term:
utils
. It was a large module with several distinct groups of functions, all put together.utils.hl
has been moved to a new module,utils.Hl
.utils
.utils
methods operating onany[]
were moved toutils.List
.utils
to accessList.index_of
, orList.slice_from_end
, and there were imports inutils
only existing to implement these functions.utils
methods operating on{[string]: any}
were moved toutils.Table
for the same reason as theutils.List
split.utils.basename
, etc were moved tobarbar.Fs
.utils
just for implementing these methods.)Foo
, but only uses it forFoo.bar
, importbar
instead.Foo
forbar
when possiblebar
is a table, sinceFoo
might reassignbar
and the import would become stale.require
s as per Formatting rules #430