emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behavior with 25.2 on macOS


From: Charles A. Roelli
Subject: Re: Strange behavior with 25.2 on macOS
Date: Sat, 5 Aug 2017 21:21:09 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Can you reproduce this behavior from emacs -q (i.e., without any
personal configuration)?

I tried the following to see if I could reproduce it:

src/emacs -q
M-x shell RET
yes RET ; some command that spews a lot of output
C-x 5 2 ; create a new frame
C-x b *scratch* RET

Followed by these steps:

* Hitting ESC-x or ESC-:
* `C-x 5 o` to switch from the window displaying the code buffer to the
window displaying the shell buffer.

But the issue did not occur (the amount of lines in the *shell* buffer
keeps on increasing without pause).



On 03/08/2017 18:49, Barry Warsaw wrote:
I have two Macs, both of which run macOS 10.12.6, and both of which have
Emacs 25.2 installed from source via homebrew.  Both are up-to-date in
brew and in installed packages.  On one machine, Emacs is working great,
but on the other, I'm seeing some very strange behavior with subprocess
output hanging.  I'm wondering if anybody has seen similar issues, or
has any suggestions for debugging.

Here's the most visible symptom:

In a shell buffer, I run the `tox` command to run the test suite for GNU
Mailman 3, which is a Python project.  This spews a lot of output to
stdout.  If I have that running in one window and go to another window
with some code in it, and hit C-g in that window, the stdout spew from
tox just stops.  It'll sit there forever until I hit any other key than
C-g.  As soon as I do, all the buffered output gets printed and tox
continues its progress.  It's pretty consistent behavior, and isn't
really related to tox (it'll happen with anything that streams out lots
of text in a shell).

Other things that stop output include:

* Going to the beginning of the code buffer and hitting C-p.
* Hitting ESC-x or ESC-: - in both cases the prompt appears in the
minibuffer, but shell output stops.
* `C-x 5 o` to switch from the window displaying the code buffer to the
window displaying the shell buffer.
* Going into the shell buffer and using either the `pushd` or `popd`
bash commands.  I see the minibuffer echo the dir stack, but the shell
prompt doesn't come back until I hit another key.  However, if the dir
stack is empty and I popd, it comes back immediately.  cd to another
directory can also hang the shell buffer.

I don't think it's just the shell though because I can also see a hang
when invoking git commit through magit.  I see 'Running git commit --'
in the minibuffer, but it's not until I hit another key or something
that the commit buffer actually comes up.  I generally `git commit -a
-v` but I don't know if that's relevant.

Other things that restart output include:

* Going to Activity Monitor, selecting the Emacs process and hitting
Sample to collect process details.  When the shell buffer is stopped, it
doesn't seem particularly hungry with CPU, disk, memory, or any other
system resource.

The two machines are setup nearly identically.  One difference between
them is that on the problematic machine I have the gnutls brew package
installed (for gnupg), but I uninstalled that and reinstalled Emacs and
verified that it makes no difference.  So yes, reinstalling Emacs
doesn't solve the problem.  I haven't noticed any other weirdness with
the machine exhibiting the Emacs problems.  I haven't completely
verified that they both have the same packages installed, although what
is installed are all up-to-date.

Any suggestions will be greatly appreciated!  The problem is so
frustrating. ;)

Cheers,
-Barry






reply via email to

[Prev in Thread] Current Thread [Next in Thread]