I've been off in KDE land for a while, but Gnome 2.6 performance is much better 
on my 800MHz Transmeta, so I'm back. Unfortunately, this issue is still around, 
so I'm bumping the version up to 2.6.

*** Bug 148594 has been marked as a duplicate of this bug. ***

as noted in bug 148594, I suppose this happens when there is another instance of
gedit already open...

Hey Paolo :) I am just cruising through the open bugs marked with the usability
keyword and ran across this one. Is this bug still being actively addressed? It
was marked high priority for the 2.6 timeframe, so if it isn't closable right
now, maybe we can bump the Version to 2.10 so this could get some action in the
2.9 development timeframe? What do you think?

This bug is still to be fixed.
Please, move to "FUTURE" timeframe.
I don't think to have time to fix it in 2.10 timeframe.
Thanks.

A possible way to fix this bug could be:

- add a "--wait" parameter
- when --wait is used, a new window is opened and the console is blocked until the new window is closed.

mh, shouldn't it be the new document instead of the new window ?

Any progress? As of now gedit cannot be used for SVN_EDITOR because if you happen to have any instance of gedit running when you run svn commit (or something similar) the gedit will return immediately. I'd prefer if jEdit's behavior would be copied. jedit --help:
...
-wait: Wait until the user closes the specified buffer in the server
         instance. Does nothing if passed to the initial jEdit instance.

"gedit --wait filename" should open the filename for editing and main() shouldn't return until the buffer for "filename" has been closed. The fact that jEdit ignores the flag if passed to initial instance should be considered a bug and shouldn't be copied (if I open first file with --wait, then open an another file and the I close the first one the process that was started with --wait should return. If the --wait flag is ignored then the process will return only after all gedit windows has been closed).

I think this is pretty much in a PATCHWELCOME state :)

In other words, we would be happy to consider a patch, but I don't think it will be on our short term TODO list any time soon.

If someone wants to give it a try, you should consider that the way "single instance" apps are implemented within gnome is a bit in flux. It may be that if/when we switch to a full d-bus solution this will be fixed automatically.
Also note that running two gedit instance can potentially corrupt some metadata, so this is not as trivial as it may sound (e.g. you need to disable metadata and maybe other things).


As a quick workaround note that by running "TMPDIR=/some/dir gedit" runs a new gedit instance since it doesn't find the socket open by the running instance in /tmp. I guess you could such a trick for SVN_EDITOR, at the risk of losing some of the metadata.

*** Bug 511071 has been marked as a duplicate of this bug. ***

Just a note, I am adding support for using GEdit as an editor to the Hotwire hypershell; the way I'm currently coding this is trying to exec GEdit using a --wait option, if that returns an error code, then using an internal wrapper which does the TMPDIR trick.  

So if someone writes this patch, please name the option --wait =)

*** Bug 513433 has been marked as a duplicate of this bug. ***

*** Bug 498979 has been marked as a duplicate of this bug. ***

*** Bug 534534 has been marked as a duplicate of this bug. ***

I'm thinking of implementing this when going from bacon to DBus. I'm currently coming up with the following scheme:

---------------------------
== Modes of Operation ==
To allow control over whether gedit should run as a single instance application, or as a standalone application, and to allow proper blocking of the gedit process when waiting for files to be finished editing (like is used often with $EDITOR), the following modes of operations are suggested:

1. Single Instance (default)
  1. Instance already exists
    * Send command line arguments over DBus to existing instance
    * Use Message-Wait strategy for --wait
  2. Instance does not yet exist
    * Use default command line handling
    * Use Fork-Wait strategy for --wait
2. Standalone (--standalone}
  * Do not start DBus
  * Use default command line handling
  * Use Fork-Wait strategy for --wait

=== Fork-Wait strategy ===
The Fork-Wait strategy will fork the process. The parent process continues to run the normal mode of operation, starting up gedit etc. The child process will wait for a signal from the parent process that the wait is over (see Wait Handlers).

=== Message-Wait strategy ===
This strategy is slightly different since signalling that the wait is done has to be done over the message bus now. The process installs the wait with a certain message and then waits for a 'wait done' message to be sent by the instance process over the bus.

=== Wait Handlers ===
Wait handlers can be installed on documents or windows. If files were opened from the command line, wait handlers are installed on the documents opened by those files. In this case, the wait is done if all those documents are closed. If a new window was opened to open these documents, the window is also destroyed. If no files were specified and a new window was opened (either there was none, or with --new-window), then install a wait handler on the newly opened window. The wait done is signalled when this window is closed.
---------------------------

With regard to pbor's remark on metadata corruption, it might not be a good idea to support --standalone right away (is it even useful?).

*** Bug 592645 has been marked as a duplicate of this bug. ***

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

*** Bug 645307 has been marked as a duplicate of this bug. ***