New feature: /save and /load saves and restores the edited-files list

[jerzydziewierz]

Frequently used feature: store and load the list of editable and read-only workspace file names.

[jerzydziewierz]

• Added the save/load commands
• Re-arranged the list to list frequently used commands first
• all other commands left as-is

[jerzydziewierz]

@paul-gauthier may I ask for an indication -- can this be merged, or should I drop it?

[paul-gauthier]

Thanks for your interest in aider and for taking the time to work on this PR. Unfortunately, I don't think I'll be able to merge this it. I like the concept and I know other users are interested in something like this. But the UX and implementation details in this PR probably aren't appropriate to merge.

[jerzydziewierz]

I appreciate the time you took to look at it.

Being a recent pro dev on a large legacy project, I also appreciate that my implementation may be not suitable for this particular code base.

Still, you did not say to "just drop it" -- may I ask for a word of a guidance, what can I improve about it, to make it compatible with your code, please?

[jbellis]

I also think this would be useful. How about if we narrowed the scope to simplify the UX? I think we get 90% of the benefit with 10% of the complexity.

1. Modify the no-argument drop to save the state in memory before clearing the active state
2. Add a new command (undrop?) to load the most recently dropped context

This addresses the most common use case (I have a complex context but I need to narrow it temporarily so I don't confuse the LLM for a surgical edit, before continuing with the bigger project) without adding complexity around marshaling to files etc.

[CLAassistant]

All committers have signed the CLA.

[wladimiiir]

What about something like /session mysession command? Aider would remember open files in the current session. You can return to your previous session (would solve the save/load request) and you could also switch between the sessions when working with aider /session myothersession (which would solve @jbellis's use case).

[jerzydziewierz]

I also think this would be useful. How about if we narrowed the scope to simplify the UX? I think we get 90% of the benefit with 10% of the complexity.

1. Modify the no-argument `drop` to save the state in memory before clearing the active state

Sorry mate, but it seems to me that overloading an existing clear-purpose command with more functionality would only worse the learning curve

and what if one wanted to drop one file but accidentally did not specify a file? I know I would be annoyed by the undesired behaviour

@wladimiiir I take your point of naming the save-point,

but regarding /session {name} there still would be a need to know if it means "please load" or "please save" or "please clear"

at this time, load/save/drop has the simplest functionality and UX, in my humble opinion

[jbellis]

and what if one wanted to drop one file but accidentally did not specify a file

then you undrop, and then re-drop the one you intended

(actually I would recommend using a bare add to instead of adding undrop which is nicely symmetrical)

[wladimiiir]

My idea is just this simple:

/session {name}

• in case session {name} does not exist, create a new session and set it as the active one
• in case the session {name} exists, load the stored files and set the session as the active one

While in active session /read-only, /add, /drop will automatically update the active session files, you don't need to save them manually.

[jbellis]

Good thinking, I like the session proposal.