[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48579: 28.0.50; Spawning an emacs process using call-process results
From: |
Daniel Mendler |
Subject: |
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS |
Date: |
Sat, 22 May 2021 15:20:56 +0200 |
On 5/22/21 3:13 PM, Daniel Mendler wrote:
> On 5/22/21 3:04 PM, Alan Third wrote:
>> On Sat, May 22, 2021 at 02:54:26PM +0200, Daniel Mendler wrote:
>>> But this discussion here seems to be a bit off-track. My point here is
>>> that the current working directory determination on MacOS uses a
>>> heuristic, which is not correct. It incorrectly determines that Emacs
>>> has been launched from the finder or some other Mac GUI application and
>>> therefore changes the directory to the home directory. If Emacs is
>>> indeed started from the GUI, this makes all sense. But this is not the
>>> case here. The TTY heuristic, that Alan described, is insufficient.
>>
>> I can't find any other way, and we had multiple complaints when the
>> behaviour was broken whereas this is the first complaint in the other
>> direction that I've seen.
>>
>> If you find an alternative, please let us know.
>
> As I wrote, if "--batch" opts out of this, I am happy. I should have
> used "--batch" right away in my program. Since this is what I am doing -
> I am starting a batch background worker job. I just wasn't aware of the
> opt-out. Hopefully the batch setting does not have other unexpected side
> effects.
Hmm, it seems that in my use case the combination of --batch and
--daemon is not working. This means I have to keep using --chdir for the
opt-out. I guess it is expected that --daemon and --batch cannot be
combined? My use case is kind of an edge case.
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, (continued)
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Alan Third, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Alan Third, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS,
Daniel Mendler <=
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Philipp, 2021/05/23