Code refactoring plan

[sudo-tee]

Currently some aspect of the code need some love as the maintability is starting to sufffer.

I have identified a couple of acpect where we should iomprove the code

• Split state.lua in multiple smaller slices (ui, jobs, model, session, etc) with functions to update the state, this way we can manage transitions in the state rather than doing it everywhere.
• Split api.lua into commands.lua (:Opencode routing), slash_commands.lua, and api.lua (public action functions).
• Split renderer.lua -- extract event subscription setup, permission/question coordination, and message formatting into separate concerns.
• Deduplicate shared code -- extract set_win_option/set_buf_option and update_winbar_highlights into shared utility modules.
• Make file_picker.lua use base_picker.lua instead of its own parallel implementation.
• Core isn't feature-agnostic: core.lua / api.lua have feature-specific logic baked in — diff functions, markdown renderer detection (RenderMarkdown/Markview), footer mode hardcoded to only recognize build/plan.

Here is a list of the Associated PR for this

State refactor
#321

[sudo-tee]

@jensenojs @disrupted

This a small plan to modernize and stabilize this plugin, feel free to add stuff you think would help.

If there is any of these that you have interest in helping let me know.

[jensenojs]

I'm really excited that I can work on code cleanup for this project (because I've built some skills specifically for this), and I'll go through it in more detail later in a relatively thorough manner

The second approach to progress may be much slower, and I will try to gradually consolidate the code branches here

As far as I'm concerned, in terms of participating in code refactoring, I may have two types of participation approaches.

The first approach is low-hanging fruit, such as code consolidation, which doesn't require much context and can probably be merged directly.

The second approach is refactoring for certain features (such as diffview), which means it will have a certain degree of main task objectives (this is much more pragmatic than slogans like "separate strategy and mechanism as much as possible"). For the latter, I will try to break it down into several issues, and I'd like both of you to review them in combination with your agents. I think a major focus of the review here will be whether it will impact the work you currently have on hand.

But there will definitely be some gray areas here. For example, I also think state.lua needs to be refactored into a module (actually, I had a draft of this locally earlier), especially since I'm somewhat concerned that there might be some interactions between state modules internally later (if there are, they should be encapsulated within this module). However, I think this broader aspect may also require some effort to figure out how to help people and agents reach consensus. This is my main concern. Ideally, we could take turns doing relay work or work on things that won't conflict with each other.

Thank you all so much. @sudo-tee @disrupted

[sudo-tee]

@jensenojs for the state refactoring I already started
#321

You can have a look if you want. It splits the state in multiple "slice" and does not allow to directly set the state keys as a global object. For this you use the setter for it.

This way if some things like clearing a session needs to set more than one field, that transition is maintasined by the state slice itself.

Think of it a little bit like Redux but much more simple

[jensenojs]

I want to take over the work on api.lua, but I've been a bit busy lately. I'll provide a more detailed structure later.