#3453 jEdit fails to load text-file under Mac OS X

[dushanm]

For the last several versions of jEdit, opening a text-file from a file manager
(such as Path Finder or muCommander) will start jEdit (assuming it's not already
started) with a blank window, but the text-file itself will not be loaded. But if
jEdit was already open, the invoked text-file will load into jEdit. This behavior
is entirely repeatable - in fact I haven't found a way to avoid it.

[Dac Chartrand]

I can confirm this. I was going to post the following bug report as a new ticket, but instead will append it as a comment to this one.

[OSX] Can't open files unless jEdit is already active

OSX 10.6.4
jEdit 4.3.2

I use jEdit as an external editor in other programs (example, SmartSVN). When I do an open from the other program, jEdit doesn't open the file unless it's already active.

A more basic case follows:

0) The jEdit icon is in your dock, no buffers from previous sessions when launching.
1) Make sure jEdit is inactive (not running)
2) Drag a file onto the jEdit icon in the dock

Expected:
File opens

Actual:
Buffer is empty.
if I drag again a second time, it works.

This also fails, but sometimes it works?

0) The jEdit icon is in your dock, no buffers from previous sessions when launching.
1) Make sure jEdit is inactive (not running)
2) At the prompt do: `open -a /Applications/jEdit.app /path/to/file`

Expected:
File opens

Actual:
Sometimes it works, sometimes it doesn't?

[Townsfolk]

Fixed by patch:
https://sourceforge.net/tracker/?func=detail&aid=3161330&group_id=588&atid=300588

[Anonymous]

Attempted with the latest nightly. Not only has this regressed (files don't open properly when jEdit is closed), but it appears that things are worse in that files now fail to open properly even when jEdit is already open.

[Evan Wright]

The latest nightly works for me. Do you have the Mac OSX plugin loaded? What version of OS X are you using?

[Anonymous]

I do have the Mac OSX plugin loaded, and all my plugins (except Character Map) are at their latest versions. This is on MacOS X Lion 10.7.1.

[Evan Wright]

Are you using Apple's JRE or a different one?

[Anonymous]

Apple's JRE. The only odd thing I'm doing is adding the following property to Info.plist:

apple.awt.graphics.UseQuartz=true

[Evan Wright]

If you go to the jEdit menu (not the help menu), and click on "About jEdit", do you get a dialog box?

[Björn Kautler]

Daniel, what nightly do you use? 4.4 or 4.5?

[Anonymous]

I had to roll back to 4.4.1 since certain plugins don't work properly on the nightly (most notably SuperAbrevs). I installed from the 4.5pre1 download, built 09/26/2011.

[Björn Kautler]

Could you also try the 4.4 nightly?

@evanpw I'm not investigating, just giving additional thoughts. You are welcome to fix this. :-)

[Anonymous]

Where do I get the 4.4 nightly?

[Evan Wright]

It's at the same place, but listed under jEdit-stable: http://www.tellurianring.com/projects/jedit-daily/index.php?dir=jEdit_stable

[Anonymous]

Tried with the 4.4.2 daily (from 09/20/2011). Looks like it behaves exactly like 4.4.1 in this area. Opening a file when jEdit is open works fine (unlike 4.5pre1), but opening a file when jEdit is *not* open results in the blank editor + full application hang behavior that we know and love.

[Anonymous]

Might be worth noting that even when jEdit is open, I can produce the blank editor + hang behavior by opening a file using the following script:

#!/bin/sh
open /Applications/jEdit.app
exec java -jar /Applications/jEdit.app/Contents/Resources/Java/jedit.jar -reuseview "$@"

(note: open -a jEdit doesn't work if you have deactivated local backups in Lion, which is something I highly recommend for anyone who values their battery life)

[Björn Kautler]

Just as a note to you evanpw, That script Daniel mentioned was given to him by me. The open call will open jEdit.app or bring it to foreground and then the java call executes normally, sending what to do to the running jEdit instance. This is intended for jEdit command line usage as each one alone will not work. The open alone doesn't handle command line arguments nice. The java command alone will not inject the properties defined in the Info.plist and will not appear as running jEdit.app in the dockbar. This combination though with first opening or bringing to front the jEdit.app and then send what to do to the jEdit server works like a charm and supports all command line arguments of jEdit.

[Evan Wright]

@Daniel: I think this may be a Lion-specific problem (there have been some other bugs reported on Lion that I can't reproduce on Snow Leopard), but just to verify: 1) you are using the Mac OS X plugin version 1.2, and 2) you get the bad behavior when dragging a file to the jEdit dock icon when it is not open, right? I plan on upgrading to Lion in the next week or so, and I'll try reproducing this bug again then.

@Vampire: That script works fine if jEdit is already running, but if it's not, then it involves a race condition. Sometimes it works correctly, and sometimes it opens two independent copies. I use "open -a jEdit --args whatever", but I guess that's not available in some cases (as Daniel points out), and it doesn't support relative paths.

[Anonymous]

Just a note on the script: it's easy enough to canonicalize paths in a shell script. So, not supporting relative paths is not a big deal. open -a definition doesn't work all the time though. Ideally, we should just be able to pass arguments using open /Applications/jEdit.app, but I don't know how well that interacts with the way that open works.

MacOS X Support plugin is indeed 1.2. I hadn't actually tried dragging onto the dock icon until just now. That does something even more dramatic, where the *entire* jEdit window ends up blank and everything hangs. I had simply been using Finder's Open With... incantation.

[Björn Kautler]

"open -a jEdit --args whatever" doesn't work anyway, independently of the topic Daniel mentioned.
At least in my quick tests.
If I had jEdit running already, then "open -a jEdit --args whatever" did not open "whatever" in the running jEdit instance, but just brought the running jEdit instance in front.
Because of that I did the two-liner.
I didn't test that script much, just some tries and there I wasn't able to produce unwanted behaviour as you describe.
What is the problem there?
I guess the "open" call resumes too fast or startup needs too long, so that if the second line is executed the jEdit server is not yet listening. To work around this, you could add a sleep between the two lines then it should work better, shouldn't it?

[Evan Wright]

1) You are right that "open -a jEdit --args whatever" won't work if jEdit is already open. If you're just trying to open a file and not send some other command, then open -a jEdit filename" should work in either case (it's supposed to be equivalent to dragging a file to the dock icon).

2) You also are right about the problem with the script: it's possible for the second instance to try to connect before the first instance starts listening. A sleep in between does help.

3) In any case, if the script produces a hang / blank window, then there is a separate problem. The bug referred to by this tracker item is a problem with the OS X plugin, and your script goes through the regular command-line argument route instead.

[Björn Kautler]

The thing about this script was just a sidenote of Daniel.
He had problems before I gave it to him and he still has problems like he described when using the Finder or dragging to the dockbar which does not use the script.