Open Chainfire opened 1 day ago
So changing the scrollMode in MarkdownDialog.kt:49 to viewport.scrollMode = JViewport.SIMPLE_SCROLL_MODE
fixes the problem. The scrolling in the window doesn't work at that point though.
Opening the shell window also does not work. Which may or may not have something to do with this error:
2024-11-15 16:49:38,410 [6772819] SEVERE - Projected Logger - Illegal scheduler for current action, must be: com.jetbrains.rd.platform.protocol.EdtScheduler@4c4e7f86, current thread: 275:Thread-85, debug info: RdOptionalProperty: `CodeWithMe-Wire-A54787FBF8518D7C108A62B63BC5FB87E4539958D646ABA7466DF3BCF593E17D-1731679006664.LuxModel.components.[13].cursor`
[backend] java.lang.Exception
at com.jetbrains.rd.platform.util.IdeaRdLoggerFactor$getLogger$1.log(IdeaRdLoggerFactor.kt:28)
at com.jetbrains.rd.util.SwitchLogger.log(Logger.kt:38)
at com.jetbrains.rd.util.reactive.IScheduler$DefaultImpls.assertThread(Scheduler.kt:75)
at com.jetbrains.rd.util.reactive.ISchedulerWithBackground$DefaultImpls.assertThread(Scheduler.kt:35)
at com.jetbrains.rd.platform.protocol.IRdDispatcher$DefaultImpls.assertThread(IRdDispatcher.kt:8)
at com.jetbrains.rd.platform.protocol.EdtScheduler.assertThread(EdtScheduler.kt:14)
at com.jetbrains.rd.framework.base.RdReactiveBase.assertThreading(RdReactiveBase.kt:28)
at com.jetbrains.rd.framework.base.RdReactiveBase.localChange$rd_framework(RdReactiveBase.kt:43)
at com.jetbrains.rd.framework.impl.RdOptionalProperty.set(RdProperty.kt:201)
at com.jetbrains.rdserver.lux.adapter.LuxComponentAdapter.updateCursor(LuxComponentAdapter.kt:342)
at com.jetbrains.rdserver.lux.awt.peer.LuxComponentPeer.updateCursorImmediately(LuxComponentPeer.kt:75)
at java.desktop/java.awt.Component.updateCursorImmediately(Component.java:3259)
at java.desktop/java.awt.Component.show(Component.java:1720)
at java.desktop/java.awt.Component.show(Component.java:1750)
at java.desktop/java.awt.Component.setVisible(Component.java:1697)
at java.desktop/javax.swing.JComponent.setVisible(JComponent.java:2716)
at de.andrena.codingaider.outputview.MarkdownDialog.startAutoCloseTimer(MarkdownDialog.kt:188)
at de.andrena.codingaider.executors.api.IDEBasedExecutor.onCommandComplete(IDEBasedExecutor.kt:145)
at de.andrena.codingaider.executors.CommandExecutor$handleProcessCompletion$2.invoke(CommandExecutor.kt:101)
at de.andrena.codingaider.executors.CommandExecutor$handleProcessCompletion$2.invoke(CommandExecutor.kt:101)
at de.andrena.codingaider.executors.GenericCommandSubject.notifyObservers(GenericCommandSubject.kt:14)
at de.andrena.codingaider.executors.CommandExecutor.notifyObservers(CommandExecutor.kt)
at de.andrena.codingaider.executors.CommandExecutor.handleProcessCompletion(CommandExecutor.kt:101)
at de.andrena.codingaider.executors.CommandExecutor.executeCommand(CommandExecutor.kt:76)
at de.andrena.codingaider.executors.api.IDEBasedExecutor.executeAiderCommand(IDEBasedExecutor.kt:75)
at de.andrena.codingaider.executors.api.IDEBasedExecutor.access$executeAiderCommand(IDEBasedExecutor.kt:25)
at de.andrena.codingaider.executors.api.IDEBasedExecutor$execute$3.invoke(IDEBasedExecutor.kt:61)
at de.andrena.codingaider.executors.api.IDEBasedExecutor$execute$3.invoke(IDEBasedExecutor.kt:60)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
Thank you for giving the plugin a try and providing feedback. Lets start with your general questions:
I have many projects with many different CVS roots attached to a single workspace. If I add persistent files, those will be used for all projects? If so, can these be split per project, or can we use individual project-root aider config files to /read them instead?
Currently persistent files are managed in a single .aider.context.yaml
in your workspace root and managed in https://github.com/p-wegner/coding-aider/blob/4687967a819ec20353d578fa2b442812aac8a9fe/src/main/kotlin/de/andrena/codingaider/services/PersistentFileService.kt#L19
I was thinking about either making use of aiders /load and /save commands that were added lately https://github.com/Aider-AI/aider/releases/tag/v0.61.0 or building my own context session management, where you can easily switch between multiple context yamls. In general, the plugin will execute aider in the root of your IDEs project and all aider configuration options and locations https://aider.chat/docs/config/aider_conf.html will apply. So if you can open a PyCharm instance for every CVS root, this will work better with aider as well, since aider assumes to be run (afaik) within the scope of only one git repo.
Perhaps I have overlooked, but there doesn't seem to be an equivalent to /ask in the UI ?
The main "Aider Action" (as most other Actions) with the Aider Command Dialog will call a variant of aider -m "Your Prompt"
, which executes the prompt and terminates the process once done. So you are free to use any of aiders In-Chat commands https://aider.chat/docs/usage/commands.html like /ask
With the current startup delay of aider and the transactional nature of the interaction with it in the plugin (vs. chat interfaces), i wouldn't suggest using the plugin for those usecases yet and there are better plugins for this. I'm currently working on a way to keep a running Aider process to talk to, which will make these cases more ux friendly.
Concerning your remote setup, i have little experience how jetbrains handles the server/client plugin communication. In general there are two aspects where this could break
Test Aider Installation
works, this seems to be no issue.I will try to find the time to test the remote IDE case myself and see what i can find out.
So if you can open a PyCharm instance for every CVS root, this will work better with aider as well, since aider assumes to be run (afaik) within the scope of only one git repo.
Opening a new instance for each root/subproject is unworkable. This is certainly not a unique case, IDEA (and before that, Eclipse) have spent significant effort to support multiple subprojects and CVS roots in a single instance (window, even) because that's how large and interrelated projects tend to turn out.
Ideally, when using this plugin, it would restrict context to and use the working directory of the closest CVS root to the file that the Aider command is started on, and also load config from there. If no CVS root is inside the project, use the project root path instead.
Aider itself does seem to figure this out most of the time, even though the plugin's working directory is wrong.
So you are free to use any of aiders In-Chat commands
Doh, I guess I could've tried that.
When calling aider as a subprocess of the host
I don't think anything is wrong there
All UI interaction in the client, when opening custom dialogs and other widgets. Your logs suggest that these locations where custom widgets are rendered, will cause errors. This could mean that the plugins simply needs to be installed in client and host and there is a setting for this when configuring the plugin build
It looks to me like the problems I've encountered are all restricted to Swing UI stuff, something I have zero experience with (nor plugin building, to be fair). From what ChatGPT and Claude tell me the errors I'm running into are timing/scheduling issues and in theory (even if not in practice) could occur in local development under high latency as well, as strictly speaking the UI code is wrong. Pushing updates before first render, scheduling an update on the wrong thread, etc. A large part of your UI works fine.
I don't think a client plugin is needed for this functionality at all, I don't have any plugins installed client side, they're all host side, and some are far more complex than this one.
Besides, it would be very inconvenient to have this be a client side plugin. The beauty of remote development is that there's a box somewhere in the cloud or in the company server room that is beefy enough to do all development, runs the right OS on the right architecture, has all the CPU, RAM, GPU you need, is automatically backupped, etc. Then you can connect to it (through secure channels, of course) from any cheap old laptop from all over the world and work. If this became a client side plugin that would also mean all the configuration is stored locally, and you have to setup/configure it again for all of your client machines rather than the single host.
I will try to find the time to test the remote IDE case myself and see what i can find out.
🙏
EDIT:
Concerning your remote setup, i have little experience how jetbrains handles the server/client plugin communication. In general there are two aspects where this could break
I don't know how a split plugin would communicate, but remote development mode (I use it over SSH) basically has the IDE running on the backend, then shims all UI calls which are replayed on the client, and input is send back to the host. The latency just floats edge cases to the top you would normally not encounter. It has become surprisingly mature in only a relatively short amount of time, and many plugins work fine with it. Of course, some parts are more advanced, for instance, the editor itself renders locally and processes input locally on the client as well, but for most plugins such advanced behavior is not needed at all.
I like your ideas and strongly agree that multi vcs root support would be great. I started collecting the necessary steps for this in https://github.com/p-wegner/coding-aider/discussions/35, since i will likely want to implement https://github.com/p-wegner/coding-aider/discussions/6 before and multi vcs root support will need some more adjustments for existing actions and features to still work properly.
Using remote development over SSH (JetBrains Gateway, PyCharm), how is this supposed to be setup?
I installed the plugin on the host, I can get the windows to appear, but actually executing any actions doesn't do anything, nothing shows up in "Running Commands" either.
"Test Aider Installation" works. Anthropic keys setup, model options all set to sonnet. I have included perhaps a relevant part of the logs at the bottom.
Some unrelated questions:
I have many projects with many different CVS roots attached to a single workspace. If I add persistent files, those will be used for all projects? If so, can these be split per project, or can we use individual project-root aider config files to /read them instead?
Perhaps I have overlooked, but there doesn't seem to be an equivalent to /ask in the UI ?