On 29/3/2006, at 23:15, Quinn Comendant wrote:

[...] The "Search mailing list" command lets you go to other windows, copy some text, then go back to the dialog box and paste text in. It works perfect. Mind doesn't.

The difference is that the Search ML has output set as HTML. When that is the case, the command is running asynchronously. With New Document as output option, TM will stall until the command has completed.

You could make the command asynchronous by wrapping it in something like: { … } &>/dev/null &

But then the command itself should create the new document (and output should just be discard). For example one could (probably) use this:

{ res=$(CocoaDialog inputbox \ --title "Find matching lines" \ --informative-text "Regular expression to match lines:" \ --button1 "Find" --button2 "Cancel")

[[ $(head -n1 <<<"$res") == "2" ]] && exit_discard pattern=$(tail -n1 <<<"$res")

TMP="$(mktemp /tmp/tm_search_XXXXXXXX).${TM_FILENAME##*.}" perl >"$TMP" -ne "print if /$pattern/" mate "$TMP"

} &>/dev/null &

Btw: anyway to get your mailer to not enumerate the replies in the subject? it messes up the threading in Mail.

yeah, Mail messes up a lot of threads, but not this one for me.

Soryu

On 30.03.2006, at 14:34, Charilaos Skiadas wrote:

On Mar 30, 2006, at 4:35 AM, Allan Odgaard wrote:

...

Btw: anyway to get your mailer to not enumerate the replies in the subject? it messes up the threading in Mail.

It actually didn't mess it up on my system (Mail.app Version 2.0.5 (746/746.2)). His reply to your reply shows up in the same thread as both of your replies.

weird...

Haris

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

On 30/3/2006, at 21:57, Quinn Comendant wrote:

...

...

Btw: anyway to get your mailer to not enumerate the replies in the subject? it messes up the threading in Mail.

It actually didn't mess it up on my system (Mail.app Version 2.0.5 (746/746.2)). His reply to your reply shows up in the same thread as both of your replies.

Doesn't Mail.app use the In-Reply-To and References email headers to organize threads?

I think Mail mainly groups based on subjects, spiced with some fuzzy logic, as threading seems to differ slightly from machine to machine -- and it’s really grouping, not threading… :/

I'll turn off my Re: enumeration to see if that helps.

Thanks!

Allan Odgaard wrote:

On 30/3/2006, at 21:57, Quinn Comendant wrote:

...

...

...

Btw: anyway to get your mailer to not enumerate the replies in the subject? it messes up the threading in Mail.

It actually didn't mess it up on my system (Mail.app Version 2.0.5 (746/746.2)). His reply to your reply shows up in the same thread as both of your replies.

Doesn't Mail.app use the In-Reply-To and References email headers to organize threads?

I think Mail mainly groups based on subjects, spiced with some fuzzy logic, as threading seems to differ slightly from machine to machine -- and it’s really grouping, not threading… :/

This is one of the few things I really dislike about Mail.app. As far as I know, there is open-source threading code that works almost perfectly and is free for any use. For the most part, I just turn Mail.app's threading off now, which is too bad, because threading is really useful when it's done right.

On 30/3/2006, at 23:32, Charilaos Skiadas wrote:

I don't know if it was intentional, but your reply broke the threading for me now. :) Do you have some reference for this code you mention?

I think it’s because the: [TxMt] Re: «topic» turned into Re: [TxMt] «topic», which confirms that it’s just a subject grouping with one or two normalization rules.

I still find it gets it right most of the time in mailing lists, so that's mainly where I use it.

It could do better. Have a look at actual threading (the screen grab was taken by Jacob, hopefully he don’t mind my linking to it):

http://hcs.harvard.edu/~jrus/TextMate/gmane-thunderbird.png

For mailing lists this would be _so_ much better.

Where it fails miserably is in email from friends with no subject, or maybe a common one word subject. Then it ends up putting together things that have nothing to do with each other.

Imagine how much mail I get with topics such as TextMate, Suggestion, Feedback, etc. all nicely “threaded” by Mail ;)

Pre-Tiger Mail actually did use the in-reply-to header. Maybe Apple (also) had too many problems with people doing a reply to a mailing list letter when they should have selected New Letter instead.

On 31/03/2006, at 0:02, Jacob Rus wrote:

One good algorithm is described here: http://www.jwz.org/doc/threading.html I believe there are several open-source implementations of this algorithm, but it wouldn't be too hard for Apple to write one.

Even just pairing up in-reply-to with message-id would be enough, most of the time. Hardly much algorithm in that, and Mail.app used to behave this way before Tiger, as Allan also noted. It sucks that they took that out (although some people claim it till works for them).

-- Sune.

You could make the command asynchronous by wrapping it in something like: { ... } &>/dev/null &

Yep, that works great. But I had to add a "cat - | " to the beginning to pass stdin. Here is the finished command:

cat - | { if [ -f /tmp/tm_saved_regex ]; then REGEX="`cat /tmp/tm_saved_regex`"; else REGEX="^\s*\w+.*$"; fi

res=$(CocoaDialog inputbox \ --title "Find matching lines" \ --informative-text "Regular expression to match lines:" \ --text "$REGEX" \ --button1 "Find" --button2 "Cancel") [[ $(head -n1 <<<"$res") == "2" ]] && exit_discard REGEX=$(tail -n1 <<<"$res");

echo "$REGEX" > /tmp/tm_saved_regex;

TMP="$(mktemp /tmp/tm_findmatchinglines_XXXXXXXX).${TM_FILENAME##*.}"; perl -ne "print if /$REGEX/" > "$TMP"; mate "$TMP" } &>/dev/null &

Q