On Fri, 27 Nov 2009 15:18:31 +0100, Jed Brown <jed@59A2.org> wrote:
> On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth <cworth@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'.

    (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.
> 
> 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
> > "<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.

-Carl