After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749068 - --wait option doesn't work when opening files
--wait option doesn't work when opening files
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: file loading and saving
3.16.x
Other Linux
: High normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-07 13:55 UTC by nullie
Modified: 2015-05-10 17:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.72 KB, patch)
2015-05-07 13:58 UTC, nullie
needs-work Details | Review
Fixed patch (1.25 KB, patch)
2015-05-09 12:13 UTC, nullie
committed Details | Review

Description nullie 2015-05-07 13:55:33 UTC
What I do: gedit --wait filename
What it should do: open new tab for file and wait until it is closed in editor
What it does: new tab with file is opened, but command exits immediately.
Comment 1 nullie 2015-05-07 13:58:41 UTC
Created attachment 303032 [details] [review]
Proposed patch

Proposed patch for current master. Should apply on 3.16.1 too.
Comment 2 nullie 2015-05-07 14:27:32 UTC
Applies and works on 3.16.1
Comment 3 Sébastien Wilmet 2015-05-09 10:20:41 UTC
Review of attachment 303032 [details] [review]:

We prefer a patch created with the git format-patch command, to have the commit message, author etc.

Did you check in gedit-commands-file.c that it doesn't change the API of public functions? (for gedit plugins).

In the commit message, can you explain why it fixes the bug?

::: gedit/gedit-app.c
@@ +409,3 @@
+                             GeditApp *app)
+{
+	set_command_line_wait(app, tab);

nitpick: a space is missing before the opening parenthesis.
Comment 4 nullie 2015-05-09 11:56:01 UTC
You right, I've broken gedit_commands_load_locations
Comment 5 nullie 2015-05-09 12:13:38 UTC
Created attachment 303122 [details] [review]
Fixed patch
Comment 6 Sébastien Wilmet 2015-05-10 10:19:12 UTC
Commit pushed:
https://git.gnome.org/browse/gedit/commit/?id=2e3b5aea0e8810e6946ce4daf64fceea9a9f47a9

With slight modifications:
- for set_command_line_wait_doc(), have the 'doc' and 'app' parameters aligned (gnome convention).
- add the URL of this bug at the end of the commit message.

However the bug is not completely fixed.

What is fixed:
- launch gedit instance
- $ gedit --wait <file>

What is not fixed:
- $ gedit --wait <file>

So when the --wait option is used directly when launching the gedit app instance, it doesn't work, the command returns immediately.
Comment 7 Sébastien Wilmet 2015-05-10 10:20:12 UTC
The commit is also backported to the gnome-3-16 branch.
Comment 8 nullie 2015-05-10 13:40:08 UTC
In my case running gedit --wait without development gedit running runs system gedit, which can still contain bug.

When I remove gedit from system, I get: Failed to register: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.gedit was not provided by any .service files
Comment 9 nullie 2015-05-10 13:59:14 UTC
I've ran dedicated dbus-daemon inside jhbuild shell with dbus-launch --exit-with-session bash.

gedit --wait <file> works properly there, because dbus daemon registers development gedit service file and runs proper gedit.
Comment 10 Sébastien Wilmet 2015-05-10 17:27:51 UTC
Oh indeed with 'gedit --wait <file>', the gedit instance is launched with dbus, so it launched the gedit version installed on my system. Good catch.

So this bug can be closed I guess. Thanks!