Bug 90837 - emacs-21.3-3 is having weird problems with process sentinels
Summary: emacs-21.3-3 is having weird problems with process sentinels
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: emacs (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-14 15:40 UTC by Jonathan Kamens
Modified: 2015-01-08 00:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 13:13:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jonathan Kamens 2003-05-14 15:40:51 UTC
I have an emacs-lisp function which calls an external process in a comint 
buffer and installs a sentinel to finish up the task when the external process 
exits (it's a spam parser and complaint generator).

I recently upgraded from emacs-21.3-1 to emacs-21.3-3.  After doing so, the 
sentinel sometimes exhibits new, broken behavior -- when the process is 
finished and the sentinel is called, (current-buffer) returns the rmail buffer 
I was in before calling the spam parser when it SHOULD return the comint buffer 
in which the parser was running.  I did not change anything in my code to cause 
this new behavior -- it's definitely something that changed either between 
emacs-21.3-1 and emacs-21.3-3 or (less likely) in glibc or something else that 
Emacs uses.

Furthermore, sometimes after the spam parser exits and my sentinel restores my 
previous window configuration, the next character I type in the rmail buffer 
isn't interpreted as an rmail command as it should be -- instead I get a beep 
and a message in the minibuffer telling me that the buffer is read-only.  If I 
hit the same key again, the second time it's interpreted correctly as an Rmail 
command.  M-x view-lossage doesn't show anything that might explain this 

I've tried to create a test case of this problem but I've been unable to do 
so.  I feel a little silly filing a bug report about a weird problem like this 
with no associated test case, but I wanted to give you a heads up that there 
may be something in emacs-21.3-3 that "isn't quite right."

Comment 1 Jens Petersen 2003-05-14 20:59:14 UTC
What locale are you using?  (Most of the changes made between -1 and -3
relate to utf-8 support.)

Can you reproduce the problem in a vanilla Emacs session (ie
"emacs -q --no-site-file")?

Comment 2 Jonathan Kamens 2003-05-18 16:46:08 UTC
I have LANG=en_US and LC_COLLATE=C.  Both of these problems manifest themselves
when I run emacs -q --no-site-file and then load my .emacs file manually (which
I need to do to get the spam-bouncing functions defined there).

Comment 3 Jens Petersen 2004-09-29 05:53:18 UTC
I don't think we have any process related patches -
so I suggested taking this upstream.

Have you tried with cvs emacs?

Comment 4 Jens Petersen 2004-09-29 05:56:08 UTC
Wait.  The only major change between -1 and -3 was the addition
of MuleUCS for utf-8 support...

What happens when you run emacs with --no-site-file?

Comment 5 Jonathan Kamens 2004-09-29 13:13:46 UTC
I no longer use the emacs-lisp functions that exhibit this behavior, 
and I don't have time to resurrect them to attempt to duplicate this, 
so I'm going to close this with WORKSFORME.  Perhaps it'll happen to 
someone else and they'll be able to come up with a good test case, in 
which case they can file a new bug or reopen this one.

Note You need to log in before you can comment on or make changes to this bug.