feat: implement mode_manager plugin with enhanced state management

Signed-off-by: juliano.barbosa <julianomb@gmail.com>
This commit is contained in:
Juliano Barbosa 2025-02-18 18:44:58 -03:00
parent f8b3501df1
commit 94cd09806e
5 changed files with 68 additions and 80 deletions

View File

@ -1266,7 +1266,7 @@ end
-- This is the easiest way to modularize your config.
--
-- Uncomment the following line and add your plugins to `lua/custom/plugins/*.lua` to get going.
{ import = 'custom.plugins' },
{ import = 'custom.plugins' }
--
-- For additional information with loading, sourcing and examples see `:help lazy.nvim-🔌-plugin-spec`
-- Or use telescope!

View File

@ -7,4 +7,14 @@ return {
{ 'folke/trouble.nvim', event = 'VimEnter', dependencies = { 'nvim-tree/nvim-web-devicons' }, config = function()
require('trouble').setup {}
end },
-- Mode Manager Plugin (local)
{
dir = vim.fn.stdpath('config') .. '/lua/custom/plugins/mode_manager',
name = 'mode_manager',
event = 'VimEnter',
config = function()
require('custom.plugins.mode_manager').setup()
end,
},
}

View File

@ -94,15 +94,12 @@ end
local function restore_context(mode)
local ctx = M.state.contexts[mode]
if ctx then
-- Restore window view
if ctx.window then
vim.fn.winrestview(ctx.window)
end
-- Restore cursor position
if ctx.cursor then
vim.api.nvim_win_set_cursor(0, ctx.cursor)
end
-- Restore folding
if ctx.folding then
vim.wo.foldenable = true
vim.wo.foldmethod = ctx.folding
@ -207,7 +204,7 @@ function M.save_state()
settings = M.state.settings,
contexts = M.state.contexts,
last_updated = os.time(),
version = '1.0' -- Added versioning
version = '1.0'
}
file:write(vim.fn.json_encode(persist_state))
file:close()
@ -224,13 +221,11 @@ function M.load_state()
if content and content ~= '' then
local decoded = vim.fn.json_decode(content)
if decoded then
-- Restore state with validation
if decoded.version == '1.0' then
M.state.current_mode = decoded.current_mode
M.state.settings = decoded.settings or {act = {}, plan = {}}
M.state.contexts = decoded.contexts or {act = {}, plan = {}}
else
-- Handle older versions or invalid state
M.state.current_mode = decoded.current_mode or 'act'
M.state.settings = {act = {}, plan = {}}
M.state.contexts = {act = {}, plan = {}}
@ -250,6 +245,16 @@ function M.load_state()
end
end
-- Get mode history
function M.get_history()
return M.state.history
end
-- Clear mode history
function M.clear_history()
M.state.history = {}
end
-- Initialize the plugin
function M.setup()
-- Load saved state
@ -272,14 +277,4 @@ function M.setup()
end)
end
-- Get mode history
function M.get_history()
return M.state.history
end
-- Clear mode history
function M.clear_history()
M.state.history = {}
end
return M

View File

@ -1,27 +1,32 @@
# Current Session Context
*Last Updated: 2025-02-17 21:57*
*Last Updated: 2025-02-18 18:31*
## Current State
- Rolled back to v0.1.0 tag (commit 57f551e)
- Backup branch created for pre-rollback state
- Working on mode_manager plugin integration
- Focusing on proper plugin specification and initialization
- Implementing enhanced mode state management system
## Recent Changes
- Created backup branch of pre-rollback state
- Rolled back codebase to v0.1.0 tag
- Previous state preserved in backup branch
- Started mode_manager plugin implementation
## Active Decisions
1. Using Memory Bank for configuration documentation
2. Following Kickstart.nvim's modular approach
3. Implementing comprehensive LSP integration
4. Using mode-based workflow with persistent Plan/Act toggle
5. Implementing enhanced mode state management system
## Current Focus
- Verifying system stability after rollback
- Ensuring core functionality remains intact
- Planning next steps based on v0.1.0 state
- Implementing mode_manager plugin properly
- Resolving plugin specification issues
- Setting up proper initialization hooks
- Integrating with custom_statusline
## Open Questions
- What were the key changes between v0.1.0 and the rolled back state?
- Which features need to be reimplemented or reconsidered?
- How to prevent future need for rollbacks?
- How to best structure the mode_manager plugin initialization?

View File

@ -1,63 +1,41 @@
# Project Progress
# Progress Update
## Completed Work
- Initial Memory Bank setup
- Basic Plan/Act mode system implementation
- Mode persistence with JSON storage
- Simple event callback system
- Status line integration
- Basic mode toggling (`<leader>tm`)
## Current Status
Working on mode_manager plugin implementation with enhanced state management.
## Recent Changes
- Rolled back to v0.1.0 (commit 57f551e)
- Created backup branch of pre-rollback state
## Completed Tasks
1. System rollback to v0.1.0
- Created backup branch
- Successfully rolled back to stable version
- Preserved previous state
2. Architecture Planning
- Defined enhanced mode state management system
- Documented implementation phases
- Established integration patterns
## In Progress
- Verifying system stability post-rollback
- Reassessing implementation priorities
- Evaluating core functionality
1. Mode Manager Plugin Implementation:
- Converting mode_manager.lua into proper plugin structure
- Setting up initialization hooks
- Implementing state persistence layer
- Adding event system foundations
2. Integration Work:
- Configuring plugin specification in init.lua
- Setting up custom_statusline integration
- Implementing mode-aware functionality
## Next Steps
1. Complete core state management implementation
2. Add event system with hooks and queuing
3. Implement persistence layer with versioning
4. Set up plugin and UI integration components
### Phase 1: Post-Rollback Stabilization
- [ ] Verify core functionality
- [ ] Document differences from rolled back state
- [ ] Reassess implementation priorities
- [ ] Review backup branch for salvageable improvements
### Phase 2: Core State Management
- [ ] Implement mode-specific settings store
- [ ] Add mode context preservation
- [ ] Create mode initialization hooks
- [ ] Add state validation system
- [ ] Implement error recovery mechanisms
### Phase 3: Event System Enhancement
- [ ] Add pre-mode-change hooks
- [ ] Implement post-mode-change hooks
- [ ] Create event queueing system
- [ ] Add mode-specific event handlers
- [ ] Implement async event processing
### Phase 4: Integration Features
- [ ] Add mode-specific colorschemes
- [ ] Implement mode-specific keymaps
- [ ] Create mode-specific status line content
- [ ] Add mode-specific buffer handling
- [ ] Implement window layout persistence
## Known Issues
- Current state persistence is basic
- No validation of stored state
- Limited error recovery options
- No mode-specific settings
- Basic event handling system
## Future Considerations
- Custom mode creation system
- Mode-specific plugin configurations
- Advanced state synchronization
- Mode templates and presets
- Mode groups
- Mode transitions animations
- Mode-specific help system
## Technical Requirements
- Proper plugin specification format
- Local plugin integration
- Correct module initialization
- State persistence mechanisms
- Event handling system
- Integration interfaces