From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ed L Cashin Newsgroups: gmane.emacs.help Subject: Re: signal-USR1-hook woes Date: Sun, 29 Feb 2004 00:50:01 -0500 Organization: Posted via Supernews, http://www.supernews.com Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <87n072fn92.fsf@cs.uga.edu> References: <3f5bd95c$0$49102$e4fe514c@news.xs4all.nl> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1078034526 22025 80.91.224.253 (29 Feb 2004 06:02:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 Feb 2004 06:02:06 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Feb 29 07:02:01 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AxK1Y-00089C-00 for ; Sun, 29 Feb 2004 07:02:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1AxK0U-0003vV-84 for geh-help-gnu-emacs@m.gmane.org; Sun, 29 Feb 2004 01:00:54 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-02!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:Vd8gn04YTbvPF2n16Lj87Pnmi1Q= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 83 Original-Xref: shelby.stanford.edu gnu.emacs.help:121359 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:17313 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:17313 I would like to run something like the function below on receiving a SIGUSR1. It would help me close gnus cleanly on my work machine before launching a new emacs remotely for using gnus. (defun elc-exit-gnus () "go to the group buffer (if it's there) and exit gnus" (interactive) (save-excursion (let ((g (get-buffer "*Group*")) (gnus-interactive-exit nil)) (if g (gnus-group-exit))))) I went looking for an emacs feature that lets the user associate actions with SIGUSR1 and SIGUSR2. The emacs info docs didn't turn up anything, but I found some old articles using Google groups, including the one this post is responding to. (Link provided below.) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=mailman.344.1062998727.18171.help-gnu-emacs%40gnu.org&rnum=3&prev=/groups%3Fq%3Dsignal-USR1-hook%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch On 08 Sep 2003 08:27:09 +0200 Eli Zaretskii writes: >> Newsgroups: gnu.emacs.help >> From: bjdouma@xs2.xs4all.nl (Bauke Jan Douma) >> >> (message "list-emacs-open-files: done") >> (let ( >> (buf_list (buffer-list)) >> ) > > Yikes! Why do you insist on formatting Lisp code as if it were C or > (God forbid) Pascal? It makes it very hard to read and comprehend. > >> Alas, it doesn't work. It does work from within emacs by >> calling M-x list-emacs-open-files or by eval'ing >> (signal-process (emacs-pid) 10). >> When doing kill -USR1 , all that happens is I get a >> visual bell, the file is not written. >> An strace reveals that the signal is sent allright. >> >> I am doing something wrong, but what? > > Well, is your function at all called? Does the message you produce at > the beginning of your function gets inserted into the *Messages* > buffer? > > In other words, the first question you should answer is: is the > signal delivered to Emacs and handled, but your function has a bug, > or is the signal itself handled incorrectly by Emacs? > > And it will help immensely if you tell what version of Emacs is that > and on what platform. > There is also a gnu.emacs.bug post from Robert Spier on Dec 14, 1997 with the subject "patch for USR1 and USR2 signal handling". Spier's patch contains code that shows the hooks being run when emacs receives a SIGUSR1 or SIGUSR2. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=199712141954.OAA28984%40blue.seas.upenn.edu&rnum=2&prev=/groups%3Fq%3Dsignal-USR1-hook%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch The code that runs the hooks inside the signal handler is no longer in src/emacs.c. That makes sense, from what I know about signal handlers. In emacs-21.3, the ChangeLog files show some references to the feature, it looks like instead of running the user-specified hooks, an event is created for src/keyboard.c to handle later. However, the example usage in Spier's patch email no longer works. Here's my SIGUSR1 handler test case, based on Spier's example: (add-hook 'signal-USR1-hook (function (lambda () (message "HI!!!")))) After launching emacs 21.2.1 from debian with "emacs -q" and evaluating the above code, when a SIGUSR1 is sent to the emacs process, emacs just beeps. No message appears in the *Messages* buffer. -- --Ed L Cashin PGP public key: http://noserose.net/e/pgp/