GNU bug report logs - #44824
27.1; Org export as pdf and open file does not open it

Previous Next

Packages: emacs, org-mode;

Reported by: Geraldo Biotti <gbiotti <at> gmail.com>

Date: Mon, 23 Nov 2020 17:41:02 UTC

Severity: normal

Tags: moreinfo

Found in version 27.1

Done: Kyle Meyer <kyle <at> kyleam.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Nikulin <m.a.nikulin <at> gmail.com>
Cc: 44824 <at> debbugs.gnu.org
Subject: bug#44824: 27.1; Org export as pdf and open file does not open it
Date: Sun, 31 Jan 2021 22:57:57 +0700
On 31/01/2021 22:05, Eli Zaretskii wrote:
>> From: Maxim Nikulin
>> Date: Sun, 31 Jan 2021 18:15:27 +0700
>>
>> Now I see that the problem with eshell is the same. I am not familiar
>> with eshell, but it creates new shell process for every executed
>> command. Actual handler is killed when underlying handler (kde-open5,
>> "gio open") and thus xdg-open and the main shell process exit.
> 
> What do you mean here by "actual handler" and "underlying handler"?

- actual handler: okular, evince, etc.
- underlying handler is what xdg-open actually calls: kde-open5, "gio 
open", etc. and that maps file type to particular .desktop (or mailcap) 
handler.

>> To fix the problem it is better to use (make-process :connection-type
>> 'pipe ...) that unfortunately has no higher level wrappers.
> 
> Wouldn't it work to let-bind process-connection-type to nil around the
> function that starts the async subprocess?

Sorry, for me it easier to reason how to express it in terms of system 
calls and terminal process groups than if let-bind could override a 
variable when lexical-bind is set to true.

> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system.  What am I
> missing?

On 31/01/2021 22:17, Andreas Schwab wrote:
>
> If xdg-open doesn't need to start the program itself, and sends the
> request to an already running process instead, there won't be any
> problem with the disappearing session.

I have been tempting to say that it is a race (either request is 
completed before SIGHUP or not) since Christopher Miles posted a link to 
stackexchange and I have realized the actual effect of an 
antidaemonizing cast I noticed earlier in a package related to org mode. 
On the other hand, I am not familiar with kde and gnome internals. I 
guess they could use a kind of server processes but I have no idea how 
to arrange parts for a convincing demonstration.




This bug report was last modified 4 years and 58 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.