On 31/01/2021 23:33, Eli Zaretskii wrote:
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?
...
> From: Maxim Nikulin
> Date: Sun, 31 Jan 2021 22:57:57 +0700
> Cc: 44...@debbugs.gnu.org
>
> >> 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
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 (kd
> From: Andreas Schwab
> Cc: Maxim Nikulin , 44...@debbugs.gnu.org,
> gbio...@gmail.com
> Date: Sun, 31 Jan 2021 16:17:46 +0100
>
> On Jan 31 2021, Eli Zaretskii wrote:
>
> > And I still don't understand why some people (like Lars) cannot
> > reproduce the problem at all -- the issue sounds l
Eli Zaretskii writes:
> 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?
The recipe said to start with `M-x shell' -- I wasn't able
On Jan 31 2021, Eli Zaretskii wrote:
> 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?
If xdg-open doesn't need to start the progra
> From: Maxim Nikulin
> Cc: Eli Zaretskii , gbio...@gmail.com
> 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
On Sun, Jan 31, 2021 at 06:15:27PM +0700, Maxim Nikulin wrote:
> Bhavin, thank you very much for your clear report. I have tried once
> more with eshell session and this time I was lucky enough to
> reproduce the problem in both gnome and kde sessions on Ubuntu-20.04
> focal
[...]
> 2221 16:59:4
Bhavin, thank you very much for your clear report. I have tried once
more with eshell session and this time I was lucky enough to reproduce
the problem in both gnome and kde sessions on Ubuntu-20.04 focal
On 30/01/2021 23:28, Eli Zaretskii wrote:
From: Maxim Nikulin
Date: Sat, 30 Jan 2021 22:5
On Sun, Jan 31, 2021 at 06:39:40PM +1100, Tim Cross wrote:
>
> Lars Ingebrigtsen writes:
>
> > Eli Zaretskii writes:
> >
> >>> This doesn't work:
> >>> M-x shell RET xdg-open /tmp/test.pdf RET
> >>
> >> How about asking the xdg-open developers to help us figure out the
> >> reason? Or, failing
Lars Ingebrigtsen writes:
> Eli Zaretskii writes:
>
>>> This doesn't work:
>>> M-x shell RET xdg-open /tmp/test.pdf RET
>>
>> 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
Eli Zaretskii writes:
>> This doesn't work:
>> M-x shell RET xdg-open /tmp/test.pdf RET
>
> 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
> tha
On Sat, 30 Jan 2021 at 19:04, Maxim Nikulin wrote:
> […]
>
> 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
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
> From: Maxim Nikulin
> Date: Sat, 30 Jan 2021 22:58:06 +0700
> Cc: 44...@debbugs.gnu.org
>
> The problem is that emacs does not expect that kde-open5 and thus
> xdg-open exits instantly.
Why is that a problem, and how does it cause the invocation to fail,
i.e. not show the file in question?
>
On 30/01/2021 20:49, Eli Zaretskii wrote:
How about asking the xdg-open developers to help us figure out the
reason?
I do not think, it is xdg-open problem. It just calls kde-open5 that
spawns actual handler and immediately exits.
I didn't say it was their problem, I suggested to ask them t
> From: Maxim Nikulin
> Date: Sat, 30 Jan 2021 20:31:53 +0700
> Cc: gbio...@gmail.com
>
> > 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
>
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 wi
> From: Lars Ingebrigtsen
> Date: Sat, 30 Jan 2021 07:09:50 +0100
> Cc: 44...@debbugs.gnu.org
>
> 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
How about asking the xdg-open
Il sab 30 gen 2021, 07:09 Lars Ingebrigtsen ha scritto:
> Geraldo Biotti writes:
>
> > I get the same results reported in bug 25234. 'M-! xdg-open
> /tmp/test.pdf' works
> > fine. I apologise for my english but it's not my mother language.
>
> So:
>
> This works:
> M-! xdg-open /tmp/test.pdf RET
Geraldo Biotti writes:
> I get the same results reported in bug 25234. 'M-! xdg-open /tmp/test.pdf'
> works
> fine. I apologise for my english but it's not my mother language.
So:
This works:
M-! xdg-open /tmp/test.pdf RET
This doesn't work:
M-& xdg-open /tmp/test.pdf RET
This doesn't work:
Il ven 29 gen 2021, 05:51 Lars Ingebrigtsen writes:
> "gbio...@gmail.com" writes:
>
> >> 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 25
"gbio...@gmail.com" writes:
>> 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'
On 28/01/2021 18:31, gbio...@gmail.com wrote:
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.
If I correctly get what you describe as "blinks", it could last for some
time after process failure.
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
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 shel
I hope, the following link to another emacs-orgmode mail list archive
will not be mangled by the debbugs web interface, unlike the previous one:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00327.html
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
"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.
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.
On 27/01/2021 10:36, Lars Ingebrigtsen wrote:
Executing the command "xdg-open /path/to/file.pdf" in a terminal
(Konsole) works.
The problem may be related to SIGHUP sent to children due to pty created
by emacs and closed as soon as the handler exits:
https://orgmode.org/list/ru4d75$11sc$1.
"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?
--
(domestic pets only, the antidote for overdose, m
32 matches
Mail list logo
