quickly edit doesn't open GEdit as a background process

[Jono Bacon]

In the new release of Quickly (0.2.2), running 'quickly edit' does not return to the prompt when running gedit, not running it as a background process. Shell output:

jono@forge:~/source/flarebook$ quickly edit
gedit ./flarebook/PreferencesFlarebookDialog.py ./flarebook/Kindle.py ./flarebook/AboutFlarebookDialog.py ./flarebook/flarebookconfig.py bin/flarebook

Pressing enter does not bring back a prompt, and Ctrl-C kills GEdit.

I am running this on a up to date Karmic system.

[Jono Bacon (jonobacon)]

One other note, 'quickly glade' works as normal - running glade as a background process.

[Rick Spencer (rick-rickspencer3)]

Confirmed for me as well.

Quickly 0.2.2

[Rick Spencer (rick-rickspencer3)]

didrocks ... looks like the fix you made to support default editors caused this to regress.

Perhaps we should consider gedit is *the* editor to use for quickly? Would sure simplify things.

[Didier Roche-Tolomelli (didrocks)]

Hum, remembered that you bump "Medium" a bug to enable vim to use in Quickly? ;)
It may not be possible to support interactive editor with sending software in background, though.

Well, also, not launching gedit in background enables us to add some post-treatment to cleanup some files. For instance, we can imagine that we change every <tab> by 4 spaces once gedit is closed.

Reminder: we already launch glade as a background process.

So, I'm not sure if we should do something on this (understand: not sure we should consider it as a bug)

[Didier Roche-Tolomelli (didrocks)]

(See bug 421810)

[Didier Roche-Tolomelli (didrocks)]

Ok, so, after having talked with Rick, we launch gedit in background (not other editors specified with EDITOR or sensible-editor) and invalidate bug 42810.

[Michael Terry (mterry)]

I got pointed to this bug by Tony, when I questioned why we had this block of code. I don't think that this bug is fixed like we think it is. Both subprocess.call and os.system block on program exit. The difference is actually on the gedit side.

If a gedit process is already running, the new process will return immediately. But if it's the first to be run, the gedit process will stay running until the window is closed.

So we'd need some extra logic to guarantee special behavior for gedit. Do we still care about doing this? (i.e. should we re-open this?)

[Rick Spencer (rick-rickspencer3)]

I'm seeing this on maverick now. I work around it by doing $quickly edit &

I think when I originally wrote $quickly edit, I used "&", fwiw.

[Tony Byrne (tony-badwolf)]

This "bug" is not real (or fixable). All gui editors, there is nothing special about gedit, *might* like "&" and all non-gui editors, e.g. vim, don't want it. The comparison with $quickly glade is bogus, the "&" backgrounding seems to have disappeared, perhaps when $quickly design was introduced.

$quickly edit and $quickly design are currently consistent, the user needs to use & if he needs to reuse the terminal. What is the "high" priority use case here? Anyone can type &, if you forget and need a terminal, gnome-terminal can provide another one. I vote to kill the "bug" (even though I don't have a vote). One bug report in 18 months looks like nobody is bothered by this.

It can be fixed of course, query the deb where the editor came from, look for X window dependency, use & for gui editor. repeat for design, and maintain this pointless complexity.

[Rick Spencer (rick-rickspencer3)]

I don't think the complexity is pointless. In Quickly, we design for the experience of our users, not for ourselves as maintainers and authors.

It's quite annoying for users when you do $quickly edit, and you can no longer use the $ to do $quickly run and such. I think we should check to see if Gedit is the configured editor (which it is by default) and launch it in the background. I think it's also a bug that $quickly design does not launch with &, so we should fix that as well.

[Tony Byrne (tony-badwolf)]

I suppose anyone who uses gedit as an IDE needs all the help they can get !

Another couple of defaults, consistent with this choice, could be to turn on debug logging while running from source i.e. $quickly run -v and something similar for $quickly create. I routinely $quickly create, then close immediately in order to $quickly run -v. The merge of preferences-dialog2 automatically turns on logging, at default warn level, via couchdb anyway.

[Tony Byrne (tony-badwolf)]

The gedit solution supports gedit users and command line editor users but does not support most IDE users. My preferred partial solution is attached. **Note** this patch needs fixing because gedit tries to open a file called &

[Tony Byrne (tony-badwolf)]

Here is the fix. Bug introduced in revision 519 enhance API with a real case usage: nautilus extension (still experimental)

[Tony Byrne (tony-badwolf)]

Here is the background design fix. Bug introduced in revision 519 enhance API with a real case usage: nautilus extension (still experimental)

[Michael Terry (mterry)]

Tony, I merged your design patch and used its same logic for edit. Thanks!