1 Return-Path: <cworth@cworth.org>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id 8C930431FBC;
\r
6 Fri, 27 Nov 2009 21:54:27 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
8 Received: from olra.theworths.org ([127.0.0.1])
\r
9 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
10 with ESMTP id 3Nfo-u+gAxl2; Fri, 27 Nov 2009 21:54:26 -0800 (PST)
\r
11 Received: from cworth.org (localhost [127.0.0.1])
\r
12 by olra.theworths.org (Postfix) with ESMTP id 46638431FAE;
\r
13 Fri, 27 Nov 2009 21:54:26 -0800 (PST)
\r
14 From: Carl Worth <cworth@cworth.org>
\r
15 To: Jed Brown <jed@59A2.org>, notmuch@notmuchmail.org
\r
16 In-Reply-To: <87tywgdpag.fsf@59A2.org>
\r
17 References: <1259094131-32405-1-git-send-email-jed@59A2.org>
\r
18 <1259087712-18844-1-git-send-email-jed@59A2.org>
\r
19 <87my2bfyyj.fsf@59A2.org>
\r
20 <87bpioqe3r.fsf@yoom.home.cworth.org> <87tywgdpag.fsf@59A2.org>
\r
21 Date: Fri, 27 Nov 2009 21:54:11 -0800
\r
22 Message-ID: <87638vtcsc.fsf@yoom.home.cworth.org>
\r
24 Content-Type: multipart/signed; boundary="=-=-=";
\r
25 micalg=pgp-sha1; protocol="application/pgp-signature"
\r
26 Subject: Re: [notmuch] [PATCH] New function
\r
27 notmuch-show-kill-ring-save-message-id.
\r
28 X-BeenThere: notmuch@notmuchmail.org
\r
29 X-Mailman-Version: 2.1.12
\r
31 List-Id: "Use and development of the notmuch mail system."
\r
32 <notmuch.notmuchmail.org>
\r
33 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
34 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
35 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
36 List-Post: <mailto:notmuch@notmuchmail.org>
\r
37 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
38 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
39 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
40 X-List-Received-Date: Sat, 28 Nov 2009 05:54:27 -0000
\r
43 Content-Transfer-Encoding: quoted-printable
\r
45 On Fri, 27 Nov 2009 15:18:31 +0100, Jed Brown <jed@59A2.org> wrote:
\r
46 > On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth <cworth@cworth.org> wrote:
\r
47 > > Thanks for the patch, Jed, I almost pushed it, but noticed that it's
\r
48 > > calling `called-interactively-p' with an argument even though that
\r
49 > > function does not accept an argument.
\r
51 > My docs say it does take an argument:
\r
53 Ah. So we have our first case of emacs-lisp portability issues. This is
\r
56 called-interactively-p is a built-in function in `C source code'.
\r
58 (called-interactively-p)
\r
60 Return t if the function using this was called with
\r
61 `call-interactively'. This is used for implementing advice and
\r
62 other function-modifying features of Emacs.
\r
64 The cleanest way to test whether your function was called with
\r
65 `call-interactively' is by adding an extra optional argument, and
\r
66 making the `interactive' spec specify non-nil unconditionally for
\r
67 that argument. (`p' is a good way to do this.)
\r
69 > I thought my usage fell precisely under "in deciding whether to display
\r
70 > a helpful message, or how to display it". This message is just noise if
\r
71 > executed inside a macro. As further evidence, see copy-region-as-kill
\r
74 Here's what I see for that:
\r
76 (defun copy-region-as-kill (beg end)
\r
77 "Save the region as if killed, but don't kill it.
\r
78 In Transient Mark mode, deactivate the mark.
\r
79 If `interprogram-cut-function' is non-nil, also save the text for a window
\r
80 system cut and paste.
\r
82 This command's old key binding has been given to `kill-ring-save'."
\r
84 (if (eq last-command 'kill-region)
\r
85 (kill-append (filter-buffer-substring beg end) (< end beg))
\r
86 (kill-new (filter-buffer-substring beg end)))
\r
87 (setq deactivate-mark t)
\r
90 No called-interactively anywhere.
\r
92 > Let me know if you still want me to change it.
\r
94 I can't apply the patch as it since it just results in an error.
\r
96 I'm using "GNU emacs 23.1.1" currently, for what it's worth.
\r
98 > > So for passing the thread ID to notmuch users, the "id:" prefix is
\r
99 > > convenient. For passing it not non-notmuch-based consumers it won't be
\r
100 > > desired. And that's hard to fix.
\r
102 > I'm thinking of having a prefix determine whether it is stripped or not.
\r
103 > Do you have a preference about which is the non-prefix behavior?
\r
105 Not a strong preference either way. It's just a few characters after
\r
108 > > I think long-term, a good solution would be to switch from "id:foo" to
\r
109 > > "<foo>" as the syntax for message-ID-based search strings. That's then a
\r
110 > > syntax that almost any consumer of a message ID should be prepared to
\r
113 > Downside is that it requires shell escapes when pasting into a terminal.
\r
115 Yeah, there is that.
\r
120 Content-Type: application/pgp-signature
\r
122 -----BEGIN PGP SIGNATURE-----
\r
123 Version: GnuPG v1.4.10 (GNU/Linux)
\r
125 iD8DBQFLELsD6JDdNq8qSWgRArhFAJ9YMNIHAl9rFi2rwOGZym+91IcjlQCgixBc
\r
126 2pRE78eAZGGSnw04TVKj3/g=
\r
128 -----END PGP SIGNATURE-----
\r