emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Cc: 44824@debbugs.gnu.org
Subject: Re: bug#44824: [PATCH] org.el: Avoid xdg-open silent failure
Date: Fri, 19 Feb 2021 23:45:55 +0700	[thread overview]
Message-ID: <e8766920-ab32-0519-3cda-6dfd5108e166@gmail.com> (raw)
In-Reply-To: <83blcg2jn0.fsf@gnu.org>

On 19/02/2021 21:54, Eli Zaretskii wrote:
>> From: Maxim Nikulin
>> Date: Fri, 19 Feb 2021 19:29:49 +0700
>>
>>> On Windows Emacs always uses pipes, because we don't have PTYs there.
>>> And there's no xdg-open on MS-Windows anyway, so it's a moot point.
>>
>> Should I consider your response as a suggestion to remove the `if'
>> related to `system-type'?
> 
> Yes, that 'if' isn't necessary.

Let's wait for comments comments from org developers. I do not mind to 
remove the `if' but they could ask for other changes.

>> If I remember correctly, on windows it is possible to communicate with a
>> process through stdin and stdout only if the application is compiled as
>> a *console* one.
> 
> That's true.  But in this case we don't really want to communicate
> with the sub-process, do we?  We just want to invoke it and let it
> run.  So the fact that there's no way of communicating with the
> sub-process is not important here, as the pipes will not be used.  We
> just need to specify pipes because that works around the problem with
> xdg-open.

The reason to switch to pipe process here is to avoid side effects of 
*terminal session*. PTY is redundant here. Pipe process is the only 
alternative available in emacs. Currently there is no data exchange with 
subprocess.

Reading of stderr and stdout from the handler and its descendants could 
be useful to realize a cause of a problem when it happens. At least on 
linux it is enough to specify some buffer instead of `nil' or add a 
:filter function. The reason why I did not make such change is that Gtk 
applications tends to report significant number of failed asserts. I do 
not like to pollute the "*Messages*" buffer. I am in doubts if a 
dedicated buffer should be created for such purpose.

Reading of stdout could be useful in mailcap handlers e.g. to display 
text from PDF file when only text terminal is available (no X11 or 
wayland). Currently emacs ignores "needsterminal" and "copiousoutput" 
flags in mailcap. Example of an entry for PDF:

application/pdf; pdftotext -layout %s -; test=test -z "$DISPLAY"; 
copiousoutput

Likely only a small part of users could benefit from such feature.

>> "start file.pdf" executed in cmd.exe launches an application that does
>> not block command prompt. In this sense it similar to background
>> processes launched by kde-open5 or "gio open". However I am unaware if
>> there is something similar to process groups on windows that leads to
>> termination of all group members when leader process finishes.
> 
> Things are fairly similar on Windows.  But is this really relevant to
> the issue at hand?  There's no xdg-open on Windows, so whatever
> problems you had with xdg-open will never happen on Windows.  the
> proposed patch fixes the problem only on systems where org.el invokes
> the PDF viewer via xdg-open.  Right?

1. It is not a problem of namely xdg-open. It is (mostly reasonable but 
with some caveats however) specific of DE-specific handlers as "gio 
open" and kde-open5. They exit just after spawning of a process with 
actual handler. (Just like "start file.pdf" on windows.) I am afraid 
that I could break something on windows, so I would prefer that somebody 
will test the changes on non-linux systems.

2. It is not specific to PDF files, the problem could happen with any 
format if wrapper handler such as "gio open" is invoked instead of e.g. 
direct execution of eog.



  reply	other threads:[~2021-02-19 16:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFbX=UpDN9XtTr3osTC6B=V0trvatayw5WF0gMjGWAWfQQkAXg@mail.gmail.com>
     [not found] ` <f395c79a-c3e3-52c7-3fbb-608e94868e8e@gmail.com>
2021-01-27  3:36   ` bug#44824: 27.1; Org export as pdf and open file does not open it Lars Ingebrigtsen
2021-01-27  8:33     ` gbiotti
2021-01-28  3:02       ` Lars Ingebrigtsen
2021-01-28 11:20         ` gbiotti
2021-01-28 11:31         ` gbiotti
2021-01-29  4:51           ` Lars Ingebrigtsen
2021-01-29  6:59             ` Geraldo Biotti
2021-01-30  6:09               ` Lars Ingebrigtsen
2021-01-30  7:50                 ` Geraldo Biotti
2021-01-30  8:42                 ` Eli Zaretskii
2021-01-30 13:31                   ` Maxim Nikulin
2021-01-30 13:49                     ` Eli Zaretskii
2021-01-30 15:58                       ` Maxim Nikulin
2021-01-30 16:28                         ` Eli Zaretskii
2021-01-31 11:15                           ` Maxim Nikulin
2021-01-31 11:37                             ` tomas
2021-01-31 15:05                             ` Eli Zaretskii
2021-01-31 15:17                               ` Andreas Schwab
2021-01-31 15:34                                 ` Eli Zaretskii
2021-01-31 15:21                               ` Lars Ingebrigtsen
2021-01-31 15:57                               ` Maxim Nikulin
2021-01-31 16:33                                 ` Eli Zaretskii
2021-01-31 17:07                                   ` Maxim Nikulin
     [not found]                                 ` <83o8h56p7o.fsf__8661.17158891342$1612110869$gmane$org@gnu.org>
2021-02-18 12:56                                   ` [PATCH] org.el: Avoid xdg-open silent failure Maxim Nikulin
2021-02-18 14:48                                     ` bug#44824: " Eli Zaretskii
     [not found]                                     ` <83a6s15t51.fsf__31631.6350990505$1613659778$gmane$org@gnu.org>
2021-02-19 12:29                                       ` Maxim Nikulin
2021-02-19 14:54                                         ` Eli Zaretskii
2021-02-19 16:45                                           ` Maxim Nikulin [this message]
2021-03-19  3:50                                     ` Kyle Meyer
2021-03-20 15:45                                       ` Maxim Nikulin
2021-03-21 15:01                                         ` Kyle Meyer
2021-01-30 16:39                     ` bug#44824: 27.1; Org export as pdf and open file does not open it gbiotti
2021-01-30 18:50                       ` Bhavin Gandhi
2021-01-31  7:17                   ` Lars Ingebrigtsen
2021-01-31  7:39                     ` Tim Cross
2021-01-31  9:09                       ` tomas
     [not found]         ` <108399a5-66ad-eee6-572b-b3f2181e4e6c__47986.5006914892$1611843550$gmane$org@gmail.com>
2021-01-28 16:10           ` Maxim Nikulin
     [not found]   ` <87y2gfcape.fsf_-___1545.58022493205$1611718675$gmane$org@gnus.org>
2021-01-27 12:14     ` Maxim Nikulin
2021-01-27 13:33       ` Maxim Nikulin
     [not found]     ` <0f4437bc-3e40-fe47-d6e7-d33c2fb7965a__46427.8968678386$1611759102$gmane$org@gmail.com>
2021-01-27 16:21       ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8766920-ab32-0519-3cda-6dfd5108e166@gmail.com \
    --to=manikulin@gmail.com \
    --cc=44824@debbugs.gnu.org \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).