[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.
cworth at cworth.org
Fri Nov 27 21:54:11 PST 2009
On Fri, 27 Nov 2009 15:18:31 +0100, Jed Brown <jed at 59A2.org> wrote:
> On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth <cworth at cworth.org> 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.
> 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'.
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
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'."
(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)
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.
> 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
> > I think long-term, a good solution would be to switch from "id:foo" to
> > "<foo>" 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.
> Downside is that it requires shell escapes when pasting into a terminal.
Yeah, there is that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the notmuch