You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ifpcall(api.nvim_get_hl_by_name, "LeapLabel", false) then
return"LeapLabel"
else
return"LeapLabelPrimary"
end
where the deprecated function nvim_get_hl_by_name is used.
And unfortunately it seem to have some unfixed bug related to it which would return a non empty table { [true] = 6 } when calling with some highlight group, in this case LeapLabel, resulting LeapLabel being used as match.label.
Replacing use of nvim_get_hl_by_name by nvim_get_hl would fix it for me.
And I suggest nvim_get_hl_by_name should not be used in other places as well, after all it is deprecated.
The text was updated successfully, but these errors were encountered:
Reopening issue #250. Labels still are not working correctly in some colorschemes for me.
After some digging, the issue seems to stem from
LeapLabel
being used instead ofLeapLabelPrimary
when no defaults are provided by user.The problem is in
leap.nvim/lua/leap/highlight.lua
Lines 8 to 14 in c6bfb19
where the deprecated function
nvim_get_hl_by_name
is used.And unfortunately it seem to have some unfixed bug related to it which would return a non empty table
{ [true] = 6 }
when calling with some highlight group, in this caseLeapLabel
, resultingLeapLabel
being used asmatch.label
.Replacing use of
nvim_get_hl_by_name
bynvim_get_hl
would fix it for me.And I suggest
nvim_get_hl_by_name
should not be used in other places as well, after all it is deprecated.The text was updated successfully, but these errors were encountered: