Skip to content
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

breaking!: rewrite fidget.nvim #143

Merged
merged 19 commits into from
Nov 10, 2023
Merged

breaking!: rewrite fidget.nvim #143

merged 19 commits into from
Nov 10, 2023

Conversation

j-hui
Copy link
Owner

@j-hui j-hui commented Nov 10, 2023

Gone is the old, single-file mess of a state machine. Here's some new features:

  • Plays nice with Neovim's built-in LSP progress handler
    • No longer overriding the ["$/progress"] handler like the old implementation did
    • Compatible with both the 0.8.0-0.9.X handler and the one currently on nightly (i.e., to appear in 0.10.0)
  • Support for vim.notify()-like interface
    • Support "notification groups", which can each have a separate configuration for things like highlights and icons (still supports animations, of course). Sorted according to priority.
    • Notification groups and items are indexed by user-specified keys, so updating/overwriting them is really easy.
    • Each LSP server can be configured with its own notification group.
  • Explicit DOM/model for notifications subsystem
    • I can advance the state of the notifications model without worrying about rendering/textlock
    • Makes debugging and testing much easier (though a thorough test suite has yet to be implemented)
    • Should make cacheing renders easier, to avoid redrawing the terminal (though this is unimplemented so far)
  • Synchronous execution model, i.e., "tick-driven"
    • The LSP progress and notification subsystems are running at independent rates and communicate asynchronously
    • Only poll when work needs to be done
    • Animations are much more stable (i.e., frames are always computed wrt synchronized wall clock time)
    • Rate-limiting/deliberate frame-dropping is theoretically possible
  • Implementation is much more modular, configurable, and hackable
    • Options are now declarative, with the setup() function being constructed programmatically.
    • The structure of the options follows the structure of the implementations' modules; the two will hopefully keep each other sane and navigable.
    • A lot of modules have their members exposed publicly, so many more things beyond the setup options are technically overridable.

Yeah, some of these implementation decisions are questionable or over-engineered, but at least the code feels much more flexible and hackable now. I've added several features in the last couple of days that took little effort with the current design/organization.

@j-hui
Copy link
Owner Author

j-hui commented Nov 10, 2023

lol I can only link 10 issues at a time. software development practices at an all time low...

@j-hui
Copy link
Owner Author

j-hui commented Nov 10, 2023

Closes #99

@j-hui j-hui marked this pull request as ready for review November 10, 2023 01:09
@j-hui j-hui merged commit 50dc5bb into main Nov 10, 2023
@j-hui j-hui deleted the dev branch November 10, 2023 01:15
fitrh added a commit to fitrh/init.nvim that referenced this pull request Nov 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment