execute defun on reception of signal

execute defun on reception of signal

[Emanuel Berg]

I read somewhere you can do it like this:

    (defun usr1-handler ()
      (interactive)
      (message "Got usr1 signal."))
      
    (global-set-key [signal usr1] 'usr1-handler)

However if the Emacs PID is 2592,

    $ kill -s usr1 2592

doesn't do it.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Andy Moreton]

On Sun 12 Jul 2015, Emanuel Berg wrote:

> I read somewhere you can do it like this:
>
>     (defun usr1-handler ()
>       (interactive)
>       (message "Got usr1 signal."))
>       
>     (global-set-key [signal usr1] 'usr1-handler)
>
> However if the Emacs PID is 2592,
>
>     $ kill -s usr1 2592
>
> doesn't do it.

This is documented in the info "(elisp) Misc Events" node, which you
could have easily found yourself. The documentation includes an example
which shows you are using the wrong keymap.

    AndyM

Re: execute defun on reception of signal

[Emanuel Berg]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> This is documented in the info "(elisp) Misc Events"
> node, which you could have easily found yourself.

Ridiculous. Go fly I kite - if you know how.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Andy Moreton]

On Sun 12 Jul 2015, Emanuel Berg wrote:

> Andy Moreton <andrewjmoreton@gmail.com> writes:
>
>> This is documented in the info "(elisp) Misc Events"
>> node, which you could have easily found yourself.
>
> Ridiculous. Go fly I kite - if you know how.

There is no need to be rude.

The elisp manual includes full documentation with example code, at the
location I pointed out. There is no need to repeat that information
here.

If you are too lazy to read the docs then you will struggle to find
people willing to help you.

    AndyM

Re: execute defun on reception of signal

[Rusi]

On Monday, July 13, 2015 at 12:24:48 AM UTC+5:30, Andy Moreton wrote:
> On Sun 12 Jul 2015, Emanuel Berg wrote:
> 
> > Andy Moreton writes:
> >
> >> This is documented in the info "(elisp) Misc Events"
> >> node, which you could have easily found yourself.
> >
> > Ridiculous. Go fly I kite - if you know how.
> 
> There is no need to be rude.
> 
> The elisp manual includes full documentation with example code, at the
> location I pointed out. There is no need to repeat that information
> here.
> 
> If you are too lazy to read the docs then you will struggle to find
> people willing to help you.

In all fairness, I thought the question interesting and spent some 10-15 minutes
searching an answer.... to no avail.
OTOH I generally find google usually gives a more pointed answer quicker than 
manually searching the docs. This may well be some kind of exception....

Re: execute defun on reception of signal

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> I generally find google usually gives a more pointed
> answer quicker than manually searching the docs.
> This may well be some kind of exception....

Try my 'cid' tool - it searches the RFCs, the man
pages, and the jargon file - and ranks results
neatly :) You only need the material organized in
a certain way - my way, but I don't think it is
too unorthodox. "CID" - common interface to
documentation, and the airship mechanic in the
Final Fantasy games. Pretty clever, ey?

    http://user.it.uu.se/~embe8573/conf/.zsh/cid

I didn't add support for the info files but those are
what I remember in some text/markup format which
should work exactly like the man pages' groff for
this purpose, or the jargon's plain text for
that matter. It is all an orchestra of strings - doing
unbelievable things!

The reason Google is not good is it is changing, both
the search results and what is searchable (actually
"findable"). You want your documentation static (save
for bugfixes) so you know what you expect and learn
how to navigate it. With bookmarks, each time you find
what you look for, something to this end can be
achieved with a browser and Google, but not really -
you'd have to save the webpages each time to really
get it.

Also, on-disk documentation is less distracting and
more to the point. You can access it with the familiar
shell tools (find, grep, sort, etc.). Obviously, you
do not rely on the Internet if you only access the
files on your computer.

Sometimes, Google is good tho, especially for error
messages which for whatever reason are seldom found in
the "on-line" documentation (i.e., not on paper -
remember "Sierra On-Line"?). Google speaks like you do
- "how do I...", "why..." - which the RFCs etc.
certainly don't.

Anyway, here is the solution to the original problem,
as described in (info "(elisp) Misc Events"), line 79:

    (defun sigusr-handler ()
       (interactive)
       (message "Caught signal %S" last-input-event))

    (define-key special-event-map [sigusr1] 'sigusr-handler)

    (signal-process (emacs-pid) 'sigusr1)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Vaidheeswaran C]

On Monday 13 July 2015 08:27 AM, Emanuel Berg wrote:

> Try my 'cid' tool - it searches the RFCs, the man
> pages, and the jargon file - and ranks results
> neatly :)

Do you have a tool that searches brains -- the vast network of
undocumented documentation that is easily searchable and accessible.

Re: execute defun on reception of signal

[Vaidheeswaran C]

Emanuel has the knack to keep people talking on this list.  That is a
trait that I wish I had.

By listening to people talk or forcing them to talk, I learn what is
relevant and important more quickly than I could possibly learn from
documentation.

Re: execute defun on reception of signal

[Andy Moreton]

On Sun 12 Jul 2015, Rusi wrote:

> On Monday, July 13, 2015 at 12:24:48 AM UTC+5:30, Andy Moreton wrote:
>> On Sun 12 Jul 2015, Emanuel Berg wrote:
>> 
>> > Andy Moreton writes:
>> >
>> >> This is documented in the info "(elisp) Misc Events"
>> >> node, which you could have easily found yourself.
>> >
>> > Ridiculous. Go fly I kite - if you know how.
>> 
>> There is no need to be rude.
>> 
>> The elisp manual includes full documentation with example code, at the
>> location I pointed out. There is no need to repeat that information
>> here.
>> 
>> If you are too lazy to read the docs then you will struggle to find
>> people willing to help you.
>
> In all fairness, I thought the question interesting and spent some 10-15 minutes
> searching an answer.... to no avail.

Google finds the right page if you search for "emacs SIGUSR1"

In emacs, you can find the info page with:
     C-h i d m elisp RET i SIGUSR1 RET

> OTOH I generally find google usually gives a more pointed answer quicker than 
> manually searching the docs. This may well be some kind of exception....

Both can be useful. The info pages have good indexes that are usually a
quick way of finding the answer.

    AndyM

Re: execute defun on reception of signal

[Eli Zaretskii]

> Date: Sun, 12 Jul 2015 19:29:45 -0700 (PDT)
> From: Rusi <rustompmody@gmail.com>
> 
> In all fairness, I thought the question interesting and spent some 10-15 minutes
> searching an answer.... to no avail.

How did you search?  Perhaps the indexing in the manuals could be
improved, if you provide the details about the words and phrases you
tried to look up.

Re: execute defun on reception of signal

[Nicolas Richard]

Andy Moreton <andrewjmoreton@gmail.com> writes:
> In emacs, you can find the info page with:
>      C-h i d m elisp RET i SIGUSR1 RET

FWIW I usually replace
    C-h i d m elisp RET
by
    C-h r TAB RET

(This uses the fact that the first link of the emacs manual is a link to
the elisp manual.)


-- 
Nico.

Re: execute defun on reception of signal

[Rusi]

On Monday, July 13, 2015 at 8:14:18 PM UTC+5:30, Eli Zaretskii wrote:
> > Date: Sun, 12 Jul 2015 19:29:45 -0700 (PDT)
> > From: Rusi 
> > 
> > In all fairness, I thought the question interesting and spent some 10-15 minutes
> > searching an answer.... to no avail.
> 
> How did you search?  Perhaps the indexing in the manuals could be
> improved, if you provide the details about the words and phrases you
> tried to look up.

As I said:
| In all fairness, I thought the question interesting and spent some 10-15 
| minutes searching an answer.... to no avail.
| OTOH I generally find google usually gives a more pointed answer quicker than
| manually searching the docs. This may well be some kind of exception....

ie I started with google (which was not useful) and didnt really try info.
[And for some strange reason didnt look for SIGUSR but SIGINT SIGQUIT etc]

However on a docs-improving note here's this little titbit:
[On other thread]
There was this claim "letrec is nice" or some such.
Since I know letrec from scheme etc but never seen in elisp I was curious.
I find:
 describe-function tells nothing about the recursion
 the elisp info pages (index) seems to not have it at all

Re: execute defun on reception of signal

[Thierry Volpiatto]

Rusi <rustompmody@gmail.com> writes:

> On Monday, July 13, 2015 at 8:14:18 PM UTC+5:30, Eli Zaretskii wrote:
>> > Date: Sun, 12 Jul 2015 19:29:45 -0700 (PDT)
>> > From: Rusi 
>> > 
>> > In all fairness, I thought the question interesting and spent some 10-15 minutes
>> > searching an answer.... to no avail.
>> 
>> How did you search?  Perhaps the indexing in the manuals could be
>> improved, if you provide the details about the words and phrases you
>> tried to look up.
>
> As I said:
> | In all fairness, I thought the question interesting and spent some 10-15 
> | minutes searching an answer.... to no avail.
> | OTOH I generally find google usually gives a more pointed answer quicker than
> | manually searching the docs. This may well be some kind of exception....
>
> ie I started with google (which was not useful) and didnt really try info.
> [And for some strange reason didnt look for SIGUSR but SIGINT SIGQUIT etc]
>
> However on a docs-improving note here's this little titbit:
> [On other thread]
> There was this claim "letrec is nice" or some such.
> Since I know letrec from scheme etc but never seen in elisp I was curious.
> I find:
>  describe-function tells nothing about the recursion
>  the elisp info pages (index) seems to not have it at all

With helm, assuming C-h i is bound to helm-info-at-point:

C-h i sigusr

and you have immediately 2 results.


-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: execute defun on reception of signal

[Eli Zaretskii]

> From: Nicolas Richard <youngfrog@members.fsf.org>
> Date: Mon, 13 Jul 2015 16:49:42 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> FWIW I usually replace
>     C-h i d m elisp RET
> by
>     C-h r TAB RET
> 
> (This uses the fact that the first link of the emacs manual is a link to
> the elisp manual.)

Why not "M-x info-apropos RET SIGUSR1 RET"?

Re: execute defun on reception of signal

[Eli Zaretskii]

> Date: Mon, 13 Jul 2015 07:57:04 -0700 (PDT)
> From: Rusi <rustompmody@gmail.com>
> 
> ie I started with google (which was not useful) and didnt really try info.

Then we will get back to you when the FSF has completed taking over
Google, and we can influence its search capabilities.

> There was this claim "letrec is nice" or some such.
> Since I know letrec from scheme etc but never seen in elisp I was curious.
> I find:
>  describe-function tells nothing about the recursion
>  the elisp info pages (index) seems to not have it at all

Please submit a documentation bug report, if you think the
documentation is incomplete.

Re: execute defun on reception of signal

[Rusi]

On Monday, July 13, 2015 at 8:58:50 PM UTC+5:30, Eli Zaretskii wrote:
> > Date: Mon, 13 Jul 2015 07:57:04 -0700 (PDT)
> > From: Rusi 
> > 
> > ie I started with google (which was not useful) and didnt really try info.
> 
> Then we will get back to you when the FSF has completed taking over
> Google, and we can influence its search capabilities.
> 
> > There was this claim "letrec is nice" or some such.
> > Since I know letrec from scheme etc but never seen in elisp I was curious.
> > I find:
> >  describe-function tells nothing about the recursion
> >  the elisp info pages (index) seems to not have it at all
> 
> Please submit a documentation bug report, if you think the
> documentation is incomplete.

Done

Re: execute defun on reception of signal

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

>> Try my 'cid' tool - it searches the RFCs, the man
>> pages, and the jargon file - and ranks results
>> neatly :)
>
> Do you have a tool that searches brains ...

I do, or once had I should say, because once while
under the influence I recklessly applied it to my own
brain, and alas, the tool instantly overheated and
disintegrated due to the vast amount of razor-sharp
data and active processes... But before that it
managed to transmit a video to get me a clue what is
going on:

    https://youtube.com/watch?v=4T0T_LBOhus

Anyway, I updated my cid tool [1] so that in includes
the Emacs documentation in /usr/share/info/emacs-24 -
applied to this problem, here is the output:

  $ cid usr1
  4   emacs     /usr/share/info/emacs-24/elisp.info
  2   manpage   /usr/share/man/man3/Log::Log4perl::FAQ.3pm
  2   manpage   /usr/share/man/man1/dd.1
  1   manpage   /usr/share/man/man8/smartd.8
  1   manpage   /usr/share/man/man8/rsyslogd.8
  1   manpage   /usr/share/man/man8/openvpn.8
  1   manpage   /usr/share/man/man8/mount.fuse.8
  1   manpage   /usr/share/man/man8/fwlogwatch.8
  1   manpage   /usr/share/man/man3/pthread_sigmask.3
  1   manpage   /usr/share/man/man1/rlwrap.1
  1   manpage   /usr/share/man/man1/procmail.1
  1   manpage   /usr/share/man/man1/parallel.1
  1   manpage   /usr/share/man/man1/dash.1
  1   manpage   /usr/share/man/man1/busybox.1

As seen, it points to the right place (the number one
hit), however the one-file approach of elisp.info
(75671 lines) makes the tool better suited for the
manpages (granted, some of which are long as well).
But once in the right file, you are just a couple
(max 4) searches away from what you look for. So it is
pretty good actually.

[1] http://user.it.uu.se/~embe8573/conf/.zsh/cid

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

> By listening to people talk or forcing them to talk,
> I learn what is relevant and important more quickly
> than I could possibly learn from documentation.

You bet! Doing things and talking about things is the
best way to do anything. You can read all you want how
to true a wheel but nothing beats seeing a guy do it
in a workshop and then do it yourself over and over.
This doesn't mean books and documentation are
worthless, far from it, they are there to give depth
and culture to your activity, and to be hands-on field
manuals...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> However on a docs-improving note here's this little
> titbit: [On other thread] There was this claim
> "letrec is nice" or some such. Since I know letrec
> from scheme etc but never seen in elisp I was
> curious. I find: describe-function tells nothing
> about the recursion the elisp info pages (index)
> seems to not have it at all

There is no mention of "letrec" in

    /usr/share/info/emacs-24/elisp.info

I don't know the policy. Are *all* functions, macros,
etc. supposed to be in the Elisp manual?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Vaidheeswaran C]

On Tuesday 14 July 2015 07:13 AM, Emanuel Berg wrote:
> Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
> writes:
> 
>>> >> Try my 'cid' tool - it searches the RFCs, the man
>>> >> pages, and the jargon file - and ranks results
>>> >> neatly :)
>> >
>> > Do you have a tool that searches brains ...

> I do, or once had I should say, because once while
> under the influence I recklessly applied it to my own
> brain, and alas, the tool instantly overheated and
> disintegrated due to the vast amount of razor-sharp
> data and active processes...

The tool that searches others brain (or other brains) is called a
discussion list.  Fire a query and let others do the work for you.  It
is asynchronous, efficient and it is way cooler than your poor tool.

Re: execute defun on reception of signal

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

> The tool that searches others brain (or other
> brains) is called a discussion list. Fire a query
> and let others do the work for you.

Oh, yeah? And what is the ratio for questions asked
and replies bounced back on this list?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Oh, yeah? And what is the ratio for questions asked
> and replies bounced back on this list?

Regardless of whatever, here is the code (and some
testers) to solve the original problem, mentioned in
the original post, by the original poster (yours
truly):

    (defun signal-usr1-f ()
      (interactive)
      (message "Got signal: USR1") )

    (define-key special-event-map [sigusr1] 'signal-usr1-f)

    ;; test:   (signal-process (emacs-pid) 'sigusr1)
    ;;
    ;; shell:  kill -s usr1 `ps -e | grep emacs | cut -d " " -f 2`

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Vaidheeswaran C]

On Tuesday 14 July 2015 07:29 AM, Emanuel Berg wrote:
> Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
> writes:
> 
>> > The tool that searches others brain (or other
>> > brains) is called a discussion list. Fire a query
>> > and let others do the work for you.
> Oh, yeah? And what is the ratio for questions asked
> and replies bounced back on this list?

The problem with my tool is that you need to prime those other brains
before sending queries to it.  They are mostly dormant.

Some brains go to sleep if they perceive you as rude for example.

Re: execute defun on reception of signal

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Rusi <rustompmody@gmail.com> writes:
>
>> However on a docs-improving note here's this little
>> titbit: [On other thread] There was this claim
>> "letrec is nice" or some such. Since I know letrec
>> from scheme etc but never seen in elisp I was
>> curious. I find: describe-function tells nothing
>> about the recursion the elisp info pages (index)
>> seems to not have it at all
>
> There is no mention of "letrec" in
>
>     /usr/share/info/emacs-24/elisp.info
>
> I don't know the policy. Are *all* functions, macros,
> etc. supposed to be in the Elisp manual?

letrec is not emacs lisp, it's scheme.

In Common Lisp, one would use labels, so in emacs lisp you can write:

    (require 'cl)
    (defun fact (n)
      (labels ((f (n f)
                 (if (plusp n)
                     (f (- n 1) (* n f))
                     f)))
        (f n 1)))

provides a nice tail-recursive factorial implementation.

    (fact 10) --> 3628800
    (fact 41) --> 1716706262231547904


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: execute defun on reception of signal

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> Rusi <rustompmody@gmail.com> writes:
>>
>>> However on a docs-improving note here's this little titbit: [On other thread] There was this claim "letrec is nice" or some such. Since I know letrec from scheme etc but never seen in elisp I was curious. I find: describe-function tells nothing about the recursion the elisp info pages (index) seems to not have it at all
>> There is no mention of "letrec" in
>> /usr/share/info/emacs-24/elisp.info I don't know the
>> policy. Are *all* functions, macros, etc.
>> supposed to be in the Elisp manual?
>
> letrec is not emacs lisp, it's scheme.

OK, but it is here as well:

    letrec is a Lisp macro in `subr.el'.

    (letrec BINDERS &rest BODY)

    Bind variables according to BINDERS then eval BODY.
    The value of the last form in BODY is returned.
    Each element of BINDERS is a list (SYMBOL VALUEFORM) which binds
    SYMBOL to the value of VALUEFORM.
    All symbols are bound before the VALUEFORMs are evalled.

> In Common Lisp, one would use labels, so in emacs
> lisp you can write:
>
>     (require 'cl) (defun fact (n) (labels ((f (n f)
> (if (plusp n) (f (- n 1) (* n f)) f))) (f n 1)))
>
> provides a nice tail-recursive
> factorial implementation.

I know about labels - I don't use them myself as I'm
happy to have everything on the same level.
Functions do things - they are like tools, and you
never now when you need them or in what context.
Variables, the other way around, they should be
encapsulated in all but exceptional cases. But anyway,
why do you bring this up? With letrec, can you do both
variables and setup local functions or something
like that?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> Emanuel Berg <embe8573@student.uu.se> writes:
>>
>>> Rusi <rustompmody@gmail.com> writes:
>>>
>>>> However on a docs-improving note here's this little titbit: [On
>>>> other thread] There was this claim "letrec is nice" or some
>>>> such. Since I know letrec from scheme etc but never seen in elisp
>>>> I was curious. I find: describe-function tells nothing about the
>>>> recursion the elisp info pages (index) seems to not have it at all
>>> There is no mention of "letrec" in
>>> /usr/share/info/emacs-24/elisp.info I don't know the
>>> policy. Are *all* functions, macros, etc.
>>> supposed to be in the Elisp manual?
>>
>> letrec is not emacs lisp, it's scheme.
>
> OK, but it is here as well:
>
>     letrec is a Lisp macro in `subr.el'.

Ain't emacs nice?!

I've never seen or tried that :-)

Is there a (require 'scheme) somewhere?

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: execute defun on reception of signal

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

> The problem with my tool is that you need to prime
> those other brains before sending queries to it.
> They are mostly dormant.
>
> Some brains go to sleep if they perceive you as rude
> for example.

There was no attempt at being rude to you.

Still: a mailing list (newsgroup) is *not* a place
where people who don't use their brains can get help
by people who do. Writing a question is not indicative
of a person who isn't using his or her brain, and it
isn't lazy - on the contrary, on both accounts!

The people who answer questions should thank those who
post them just as much as the other way around.
Eventually, the person who just wrote his (her) first
question can gradually mix the subsequent questions
with a couple of replies or comments here and there,
and we can all grow together.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> OK, but it is here as well: letrec is a Lisp macro
>> in `subr.el'.
>
> Ain't emacs nice?!
>
> I've never seen or tried that :-)

Cred to Rusi, not me, for finding it (and the lack of
mention in the manual), but yeah, Emacs is
a bottomless pit, no doubt. Compared to Emacs,
Mount Erebus is child's play. Only sad thing is you
don't find *big* things anymore, like Gnus, Emacs-w3m,
the man pages, ... Those were fun days :')

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: execute defun on reception of signal

[Rusi]

On Wednesday, July 15, 2015 at 3:52:47 AM UTC+5:30, Emanuel Berg wrote:
> "Pascal J. Bourguignon" 
> writes:
> 
> >> OK, but it is here as well: letrec is a Lisp macro
> >> in `subr.el'.
> >
> > Ain't emacs nice?!
> >
> > I've never seen or tried that :-)
> 
> Cred to Rusi, not me, for finding

Cred?!?! 
You just have to give me points and we are with the full ridiculousness
of SO.
Anyhow... The `cred' for letrec is Fillip Gunbin in "lacks a prefix" thread.

Personally Ive been brought up to be suspicious of letrec in non-lazy languages:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (letrec ((x (cons 1 x))) x)
(1)