bug#44824: 27.1; Org export as pdf and open file does not open it
Il 27/01/2021 04:36, Lars Ingebrigtsen writes: "gbio...@gmail.com" writes: Executing the command "xdg-open /path/to/file.pdf" in a terminal (Konsole) works. Executing the same command in Emacs via eshell DOES NOT WORK. What happens if you execute that command in Emacs via eshell? The same as using C-c C-e l o "The default PDF program (okular) appears to open (i see the icon, but not the window) and closes without showing anything."
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 28/01/2021 04:02, Lars Ingebrigtsen writes: "gbio...@gmail.com" writes: The same as using C-c C-e l o "The default PDF program (okular) appears to open (i see the icon, but not the window) and closes without showing anything." If I do $ xdg-open ./doc/lispintro/cons-2.pdf after `M-x shell', "Document Viewer" is opened as normal. You don't get any output from xdg-open or anything in the shell buffer? Glenn Morris writes: Ref eg https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25234#8 https://bugzilla.gnome.org/show_bug.cgi?id=652262 https://gitlab.gnome.org/GNOME/glib/-/issues/1208 and others going back over a decade. I think Emacs should have a PROBLEMS entry about this. Yeah, calling xdg-open (and expecting it not to exit) is a known problem, but here it seems that xdg-open doesn't even work from *shell*, which is very odd. More info: As per bug 25234, using 'M-! xdg-open /tmp/test.pdf', 'M-& xdg-open /tmp/test.pdf' and 'M-& xdg-open /tmp/test.pdf && sleep 3' I get same results as reported. If I try in eshell buffer 'xdg-open /tmp/test.pdf && sleep 3' my cursor blinks with the Okular icon for a few seconds and then nothing happens.
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 28/01/2021 04:02, Lars Ingebrigtsen ha scritto: "gbio...@gmail.com" writes: The same as using C-c C-e l o "The default PDF program (okular) appears to open (i see the icon, but not the window) and closes without showing anything." If I do $ xdg-open ./doc/lispintro/cons-2.pdf after `M-x shell', "Document Viewer" is opened as normal. You don't get any output from xdg-open or anything in the shell buffer? Glenn Morris writes: Ref eg https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25234#8 https://bugzilla.gnome.org/show_bug.cgi?id=652262 https://gitlab.gnome.org/GNOME/glib/-/issues/1208 and others going back over a decade. I think Emacs should have a PROBLEMS entry about this. Yeah, calling xdg-open (and expecting it not to exit) is a known problem, but here it seems that xdg-open doesn't even work from *shell*, which is very odd. I have no more ideas. The problem arise even exporting and opening html, so it's not the file type. Doing a better search I found this: https://forum.manjaro.org/t/xdg-open-or-kde-open-doesnt-work-when-called-from-emacs/39918 Same problem, but without an answer. If needed I can make a video of what happen (if so please explain where to upload it).
bug#44824: 27.1; Org export as pdf and open file does not open it
Il 30/01/2021 14:31, Maxim Nikulin ha wrote: On 30/01/2021 15:42, Eli Zaretskii wrote: This works: M-! xdg-open /tmp/test.pdf RET This doesn't work: M-& xdg-open /tmp/test.pdf RET This doesn't work: M-x shell RET xdg-open /tmp/test.pdf RET Geraldo, "M-x shell" case is rather strange. Could you, please, confirm ones more that okular window with the file content does not appear if you call xdg-open from an *interactive* emacs shell buffer? The link to an emacs-orgmode list message, that I have posted earlier, explains why async-shell-command *may* fail while shell-command should work reliably. I am really surprised by failure when command is executed in a [e]shell buffer. I confirm. I can see the Okular icon appear and disappear immediately in the panel. As mentioned I can make a video of everything, but I have no idea where to upload it. If it is okay to make the video and you think it is useful please tell me which commands to execute for more information on the operating environment How about asking the xdg-open developers to help us figure out the reason? Or, failing that, debug xdg-open in the problematic situations to find out what fails there and why? E.g., could it be that it fails because stdin/stdout is a PTY? what happens if you bind process-connection-type to nil when starting the async subprocess? I do not think, it is xdg-open problem. It just calls kde-open5 that spawns actual handler and immediately exits.
