Hi there,

A minor problem that comes up a lot when I use Geany is wanting to open additional documents in a particular window. Opening a file with Geany via command line will open it in the first available Geany process—ostensibly the first process to try to create the socket file. This instance's editor window usually isn't the one I want and is typically in another workspace. As a result, my "main" Geany window has over thirty open documents in it right now.

I can often mitigate this problem using the `--new-instance` flag to just pop open a new editor, but this leads to lots of Geany windows, quickly.

It would be good if Geany could organize its sockets so that more than the first open instance could be communicated with. Ideally, the most recently focused editor would accept document open commands.

If that isn't an option, I often find myself poking around in the Geany Terminal for files I want to edit (usually with `grep` or `find`). Once I have a list, though, I have no good way of opening those documents. Simply calling ``` geany `find . -name 'foo.bar'` ``` will open them in the first process. What would be cool is if I could type `open` or `edit` instead, to open them in the current instance.

I think the terminal feature might actually be more difficult to implement than proper IPC. I've considered implementing it myself, but didn't want to just drop that feature on you as a big pull request. My thoughts: - We could tackle multiple-instance communication by allowing successive instances to listen on the existing socket, or just having them create sequential new sockets. I prefer the former. - However we handle that, we will want to add a `socket_get_focus_time` (or similar) to look up how recently the editor was used. - If we put multiple listeners on a socket, we'll need to tag their responses with a UID (eg, their PID). - In this case, I'd probably just call the routine something like `socket_identify_instances`. - Tracking the focus timestamp is as simple as updating a global in each process's `set-focus` or `notify::is-topmost` event. - Once we've iterated all sockets or all responses, we would request the one with the latest (highest) timestamp to open the given files. - Again, if we had multiple instance on one socket, we'd need to tag the request with a PID or other UID from the timestamp call.

I believe this change isn't all that complicated, and might be interested in making it if the team doesn't have any other plans. Let me know.