From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: execute defun on reception of signal
Date: Mon, 13 Jul 2015 04:57:35 +0200 [thread overview]
Message-ID: <87a8v0bw80.fsf@nl106-137-147.student.uu.se> (raw)
In-Reply-To: 7d1d1e2c-1b1d-490a-a20e-1a06c84e2c87@googlegroups.com
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
next prev parent reply other threads:[~2015-07-13 2:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-12 1:59 execute defun on reception of signal Emanuel Berg
2015-07-12 10:27 ` Andy Moreton
2015-07-12 16:56 ` Emanuel Berg
2015-07-12 18:54 ` Andy Moreton
2015-07-13 3:53 ` Vaidheeswaran C
2015-07-14 1:49 ` Emanuel Berg
[not found] ` <mailman.6808.1436727285.904.help-gnu-emacs@gnu.org>
2015-07-13 2:29 ` Rusi
2015-07-13 2:57 ` Emanuel Berg [this message]
2015-07-13 3:39 ` Vaidheeswaran C
2015-07-14 1:43 ` Emanuel Berg
2015-07-14 1:58 ` Vaidheeswaran C
2015-07-14 1:59 ` Emanuel Berg
2015-07-14 2:07 ` Emanuel Berg
2015-07-14 2:09 ` Vaidheeswaran C
2015-07-14 22:14 ` Emanuel Berg
2015-07-13 8:28 ` Andy Moreton
2015-07-13 14:49 ` Nicolas Richard
2015-07-13 15:22 ` Eli Zaretskii
2015-07-13 14:44 ` Eli Zaretskii
[not found] ` <mailman.6850.1436798656.904.help-gnu-emacs@gnu.org>
2015-07-13 14:57 ` Rusi
2015-07-13 15:18 ` Thierry Volpiatto
2015-07-13 15:28 ` Eli Zaretskii
[not found] ` <mailman.6858.1436801328.904.help-gnu-emacs@gnu.org>
2015-07-13 16:13 ` Rusi
2015-07-14 1:53 ` Emanuel Berg
[not found] ` <mailman.6892.1436840915.904.help-gnu-emacs@gnu.org>
2015-07-14 2:41 ` Pascal J. Bourguignon
2015-07-14 21:33 ` Emanuel Berg
[not found] ` <mailman.6932.1436909731.904.help-gnu-emacs@gnu.org>
2015-07-14 22:11 ` Pascal J. Bourguignon
2015-07-14 22:21 ` Emanuel Berg
[not found] ` <mailman.6936.1436912565.904.help-gnu-emacs@gnu.org>
2015-07-15 15:25 ` Rusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8v0bw80.fsf@nl106-137-147.student.uu.se \
--to=embe8573@student.uu.se \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.