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: called-interactively-p is a built-in function in `C source code'. (called-interactively-p KIND) Return t if the containing function was called by `call-interactively'. If KIND is `interactive', then only return t if the call was made interactively by the user, i.e. not in `noninteractive' mode nor when `executing-kbd-macro'. If KIND is `any', on the other hand, it will return t for any kind of interactive call, including being called as the binding of a key, or from a keyboard macro, or in `noninteractive' mode. The only known proper use of `interactive' for KIND is in deciding whether to display a helpful message, or how to display it. If you're thinking of using it for any other purpose, it is quite likely that you're making a mistake. Think: what do you want to do when the command is called from a keyboard macro? This function is meant for implementing advice and other function-modifying features. Instead of using this, it is sometimes cleaner to give your function an extra optional argument whose `interactive' spec specifies non-nil unconditionally ("p" is a good way to do this), or via (not (or executing-kbd-macro noninteractive)). > Meanwhile, the documentation of called-interactively-p suggests that > using (interactive "p") is an easier way to check whether the function > is called interactively. 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): ;; This use of called-interactively-p is correct ;; because the code it controls just gives the user visual feedback. (if (called-interactively-p 'interactive) Let me know if you still want me to change it. > No, "git send-email" wouldn't strip that since it's a custom thing for > notmuch. Of course, I was just sloppy when pasting it into my shell, which rubbed this issue in my face: > 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? > 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. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091127/04e3f594/attachment.pgp>