Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crux-open-with silently fails #37

Closed
justbur opened this issue Dec 19, 2016 · 6 comments
Closed

crux-open-with silently fails #37

justbur opened this issue Dec 19, 2016 · 6 comments

Comments

@justbur
Copy link
Contributor

justbur commented Dec 19, 2016

I'm switching some of my own functions over to crux ones. I was wondering if you knew the answer to this problem I've had with opening files externally.

crux-open-with does nothing for me in dired on a pdf for example. If I switch the start-process line to

    (call-process program nil 0 nil current-file-name)

then it works fine, meaning something is failing in start-process. I did some debugging but wasn't able to find anything. It just seems to silently fail.

My version string is
GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.22.4) of 2016-12-15

If you have any ideas, I'd appreciate it. xdg-open works fine from the command line and using call-process as above.

By the way, I don't think there is any downside to using call-process here, but I'd like to know why start-process is failing for me.

@justbur justbur changed the title crux-open-with crux-open-with silently fails Dec 19, 2016
@justbur
Copy link
Contributor Author

justbur commented Dec 19, 2016

Dug into this a little more. I see what's happening I think, but I don't understand why this is different behavior on my computer since I assume it's working for others.

The behavior with call-process vs start-process is the same as the behavior with shell-command vs async-shell-command.

  1. If I do M-! xdg-open test.pdf, test.pdf opens fine.
  2. If I do M-& xdg-open test.pdf, I get a message that "xdg-open test.pdf" finished with no program opening.
  3. If I do M-& xdg-open test.pdf && sleep 3, the pdf opens for 3 seconds and closes.

So clearly emacs is killing evince (the pdf program) for me. This is logical if it's killing a whole process tree and evince is a subprocess, but it does not seem consistent with how xdg-open works in a shell for example.

Running xdg-open test.pdf in a shell does not make evince a subprocess of the shell so killing the shell does not kill evince.

I will file an emacs bug for this and see what they say, since this doesn't seem specific to crux anymore.

@justbur
Copy link
Contributor Author

justbur commented Dec 19, 2016

@bbatsov
Copy link
Owner

bbatsov commented Dec 20, 2016

ОК, thanks for bringing this up. Let me know when you figure out the best course of action.

@justbur
Copy link
Contributor Author

justbur commented Dec 20, 2016

@bbatsov I'm out of ideas for the moment. I'm not sure it's an emacs bug, but at the same time I can't set up an environment on my computer in which crux-open-with actually works. I'm on fedora 25 with gnome right now. I've tried xfce and ubuntu unity in a vm (with emacs 24.5), and all had the same behavior. Presumably it works for you. What is your setup?

Plus in your blog post you don't use an async command. Can we just switch to call-process? This works in all of the cases I've tried. It's the async versions that fail for me.

@bbatsov
Copy link
Owner

bbatsov commented Dec 20, 2016

What is your setup?

OS X. There it works just fine.

justbur added a commit to justbur/crux that referenced this issue Dec 20, 2016
Since the system open command appears to fork immediately there shouldn't be any
real performance penalty to doing this.

Fixes bbatsov#37
@justbur
Copy link
Contributor Author

justbur commented Dec 20, 2016

From the emacs bug report, I think it's an underlying problem with gvfs-open (which xdg-open uses). see here

Using a synchronous call as I did in PR #38 seems like the best option to me (at least for xdg-open).

bbatsov pushed a commit that referenced this issue Jun 26, 2017
Since the system open command appears to fork immediately there shouldn't be any
real performance penalty to doing this.

Fixes #37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants