ref: granularize imports#451
Conversation
Iron-E
force-pushed
the
ref/module-naming
branch
6 times, most recently
from
01e6709 to
cb2e720
Compare
Iron-E
force-pushed
the
ref/module-naming
branch
from
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. |
Iron-E
force-pushed
the
ref/module-naming
branch
from
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. |
Iron-E
force-pushed
the
ref/module-naming
branch
from
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 |
Iron-E
force-pushed
the
ref/module-naming
branch
4 times, most recently
from
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`
Iron-E
force-pushed
the
ref/module-naming
branch
from
b3d3efc to
c3431aa
Compare
2 participants
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.hlhas been moved to a new module,utils.Hl.utils.utilsmethods operating onany[]were moved toutils.List.utilsto accessList.index_of, orList.slice_from_end, and there were imports inutilsonly existing to implement these functions.utilsmethods operating on{[string]: any}were moved toutils.Tablefor the same reason as theutils.Listsplit.utils.basename, etc were moved tobarbar.Fs.utilsjust for implementing these methods.)Foo, but only uses it forFoo.bar, importbarinstead.Fooforbarwhen possiblebaris a table, sinceFoomight reassignbarand the import would become stale.requires as per Formatting rules #430