From: Carl Worth Date: Sat, 28 Nov 2009 05:54:11 +0000 (+1600) Subject: Re: [notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id. X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=aec4b8986f4630c09d0e75b17ff74d7ed6fd956d;p=notmuch-archives.git Re: [notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id. --- diff --git a/1f/c54f5c30bd96772d51a2725e8923076635f5bb b/1f/c54f5c30bd96772d51a2725e8923076635f5bb new file mode 100644 index 000000000..8ea280528 --- /dev/null +++ b/1f/c54f5c30bd96772d51a2725e8923076635f5bb @@ -0,0 +1,129 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 8C930431FBC; + Fri, 27 Nov 2009 21:54:27 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 3Nfo-u+gAxl2; Fri, 27 Nov 2009 21:54:26 -0800 (PST) +Received: from cworth.org (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 46638431FAE; + Fri, 27 Nov 2009 21:54:26 -0800 (PST) +From: Carl Worth +To: Jed Brown , notmuch@notmuchmail.org +In-Reply-To: <87tywgdpag.fsf@59A2.org> +References: <1259094131-32405-1-git-send-email-jed@59A2.org> + <1259087712-18844-1-git-send-email-jed@59A2.org> + <87my2bfyyj.fsf@59A2.org> + <87bpioqe3r.fsf@yoom.home.cworth.org> <87tywgdpag.fsf@59A2.org> +Date: Fri, 27 Nov 2009 21:54:11 -0800 +Message-ID: <87638vtcsc.fsf@yoom.home.cworth.org> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha1; protocol="application/pgp-signature" +Subject: Re: [notmuch] [PATCH] New function + notmuch-show-kill-ring-save-message-id. +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 28 Nov 2009 05:54:27 -0000 + +--=-=-= +Content-Transfer-Encoding: quoted-printable + +On Fri, 27 Nov 2009 15:18:31 +0100, Jed Brown wrote: +> On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth wrote: +> > Thanks for the patch, Jed, I almost pushed it, but noticed that it's +> > calling `called-interactively-p' with an argument even though that +> > function does not accept an argument. +>=20 +> My docs say it does take an argument: + +Ah. So we have our first case of emacs-lisp portability issues. This is +what I get: + + called-interactively-p is a built-in function in `C source code'. + + (called-interactively-p) + + Return t if the function using this was called with + `call-interactively'. This is used for implementing advice and + other function-modifying features of Emacs. + + The cleanest way to test whether your function was called with + `call-interactively' is by adding an extra optional argument, and + making the `interactive' spec specify non-nil unconditionally for + that argument. (`p' is a good way to do this.) + +> I thought my usage fell precisely under "in deciding whether to display +> a helpful message, or how to display it". This message is just noise if +> executed inside a macro. As further evidence, see copy-region-as-kill +> (simple.el): + +Here's what I see for that: + +(defun copy-region-as-kill (beg end) + "Save the region as if killed, but don't kill it. +In Transient Mark mode, deactivate the mark. +If `interprogram-cut-function' is non-nil, also save the text for a window +system cut and paste. + +This command's old key binding has been given to `kill-ring-save'." + (interactive "r") + (if (eq last-command 'kill-region) + (kill-append (filter-buffer-substring beg end) (< end beg)) + (kill-new (filter-buffer-substring beg end))) + (setq deactivate-mark t) + nil) + +No called-interactively anywhere. + +> Let me know if you still want me to change it. + +I can't apply the patch as it since it just results in an error. + +I'm using "GNU emacs 23.1.1" currently, for what it's worth. + +> > So for passing the thread ID to notmuch users, the "id:" prefix is +> > convenient. For passing it not non-notmuch-based consumers it won't be +> > desired. And that's hard to fix. +>=20 +> I'm thinking of having a prefix determine whether it is stripped or not. +> Do you have a preference about which is the non-prefix behavior? + +Not a strong preference either way. It's just a few characters after +all. + +> > I think long-term, a good solution would be to switch from "id:foo" to +> > "" as the syntax for message-ID-based search strings. That's then a +> > syntax that almost any consumer of a message ID should be prepared to +> > accept. +>=20 +> Downside is that it requires shell escapes when pasting into a terminal. + +Yeah, there is that. + +=2DCarl + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.10 (GNU/Linux) + +iD8DBQFLELsD6JDdNq8qSWgRArhFAJ9YMNIHAl9rFi2rwOGZym+91IcjlQCgixBc +2pRE78eAZGGSnw04TVKj3/g= +=+vSS +-----END PGP SIGNATURE----- +--=-=-=--