[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: execute defun on reception of signal
From: |
Emanuel Berg |
Subject: |
Re: execute defun on reception of signal |
Date: |
Mon, 13 Jul 2015 04:57:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
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
- execute defun on reception of signal, Emanuel Berg, 2015/07/11
- Re: execute defun on reception of signal, Andy Moreton, 2015/07/12
- Message not available
- Re: execute defun on reception of signal, Rusi, 2015/07/12
- Re: execute defun on reception of signal,
Emanuel Berg <=
- Re: execute defun on reception of signal, Vaidheeswaran C, 2015/07/12
- Re: execute defun on reception of signal, Emanuel Berg, 2015/07/13
- Re: execute defun on reception of signal, Vaidheeswaran C, 2015/07/13
- Re: execute defun on reception of signal, Emanuel Berg, 2015/07/13
- Re: execute defun on reception of signal, Emanuel Berg, 2015/07/13
- Re: execute defun on reception of signal, Vaidheeswaran C, 2015/07/13
- Re: execute defun on reception of signal, Emanuel Berg, 2015/07/14
- Re: execute defun on reception of signal, Andy Moreton, 2015/07/13
- Re: execute defun on reception of signal, Nicolas Richard, 2015/07/13
- Re: execute defun on reception of signal, Eli Zaretskii, 2015/07/13