Addition of /editor command?

[thehunmonkgroup]

Issue

Over at https://github.com/llm-workflow-engine/llm-workflow-engine I've implemented a very handy /editor command that:

• Opens the CLI editor as specified in the $EDITOR environment variable, right within the context of the running program
• Upon close/save of the editor, pipes the final editor contents back to the program as input

As a Vim/Neovim user, this is super handy for working on more complex prompts, as I have my full editor seamlessly integrated into my workflow.

While LWE and Aider serve completely different purposes, I noticed Aider also uses Prompt Toolkit, and I bet it would be fairly easy to lift the existing /editor command code from LWE and port it to Aider.

If you think this is a worthwhile feature addition, I might be willing to work on the PR to accomplish this, but I wanted to check for interest before I did any heavy lifting.

Version and model info

N/A

[paul-gauthier]

Thanks for trying aider and filing this issue.

That does sound like a handy feature, yes. You'd have /editor open up the $EDITOR to compose the next chat message for the user?

[thehunmonkgroup]

You'd have /editor open up the $EDITOR to compose the next chat message for the user?

Correct, it opens $EDITOR in the context of the app, then pipes the saved result to the input of the app.

I default to a tempfile with an .md extension, and in my Neovim setup, this gives me some nice syntax highlighting, including for code blocks. Plus I get the full power of all my Vim/Neovim editor commands, so if feels totally familar.

Check out this video, should give you a brief idea of the workflow:

editor-command-lwe.webm

[5ocworkshop]

Is it viable to consider an option to author the prompt itself in the VSCode editor window and the pass it to aider?

[insilications]

I opened #1818, but it was a duplicate of this. I will try to write a proposal here:

Description

Enable a switch that would allow Aider to receive individual messages written in a custom text editor. We can refer to this as EXTERNAL EDITOR INPUT MODE.

• You can switch to EXTERNAL EDITOR INPUT MODE in a sticky way with the /editor command. Or you can launch Aider with the --editor-mode switch.
• You can disable EXTERNAL EDITOR INPUT MODE by entering the /editor command again.
• When EXTERNAL EDITOR INPUT MODE is active, entering /architect, /ask or /code makes Aider open a temporary text file in the text editor set by the EDITOR environment variable (in line with how git commit work).
• Once this is done, Aider waits for the user to type a custom message in the text editor, save it to the aforementioned temporary text file, and finally close the editor. When Aider detects that the user has closed the editor process, it reads the content of the temporary text file and uses it to send the chat message content.
• Aider will try to perform all necessary cleanup steps, such as deleting the temporary text file.
• The only requirement for the program to work properly is that the chosen message editor must open the temporary file in a blocking mode, which allows us to detect when the process of the editor that opened the temporary file is closed. This is true for vi, nano, etc, but we must remind the user that any other editor must support such mode. For example, to use kate, the path in the EDITOR variable must have the -b option (i.e. EDITOR="/usr/bin/kate -b").

[insilications]

Is it viable to consider an option to author the prompt itself in the VSCode editor window and the pass it to aider?

This would be viable if, when you tell vscode to open a temporary text file, vscode is able to open the temporary text file in a new subprocess that is closed when you are finished writing the message. This allows Aider to easily detect that the user has finished writing the message to the temporary text file. I don't know enough about how vscode works to know if it already works this way when you tell it to open a file.

[thehunmonkgroup]

@insilications having used the /editor command for a long time in https://github.com/llm-workflow-engine/llm-workflow-engine, I'm pretty sure you would not want to implement /editor as an on/off switch in Aider.

I think it's much cleaner to have /editor be an ad-hoc command, that, when you use it, opens an editor for that particular message to Aider. I find myself dancing back and forth between simple input mode and using /editor, and it's much more intuitive to just have /editor be an ad-hoc command, plus with tab completion it's just a few keystrokes to activate it.

[insilications]

@insilications having used the /editor command for a long time in https://github.com/llm-workflow-engine/llm-workflow-engine, I'm pretty sure you would not want to implement /editor as an on/off switch in Aider.

I think it's much cleaner to have /editor be an ad-hoc command, that, when you use it, opens an editor for that particular message to Aider. I find myself dancing back and forth between simple input mode and using /editor, and it's much more intuitive to just have /editor be an ad-hoc command, plus with tab completion it's just a few keystrokes to activate it.

Maybe you are right... I support any method, as long as we manage to add a way to open an editor for a particular /ask or /code message.

I really hate having to construct long messages in the terminal.

[fry69]

I really hate having to construct long messages in the terminal.

I nearly always construct my prompts in Obsidian (markdown note taking app) and copy/paste them into aider.
This also helps me track what I am doing and pick up where I left easily.
aider's terminal input is way too annoying with its constant autocomplete while typing, I personally cannot stand this.

[thehunmonkgroup]

I plan on submitting a PR for this feature, but there is some groundwork I have to do to make it work on Windows.