patchgit-gui: Added support for OS X right click

OS X sends Button-2 on a "real" right click, such as with a three button mouse, or by using the two-finger trackpad click.

Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
git-gui.sh |    3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

V??in?? J??rvel?? <v@pp.inet.fi> wrote:

Thanks, this will be in 0.8.1.  I'm pushing it out shortly.

I had a devil of a time applying your patch though. git-am choked because the patch was whitespace damaged, and then after hand-correction and resuming it horribly munged your name's encoding in the commit. I think there's a bug in there in git-am; I'll have to try to track it down. I managed to get the patch applied correctly by editing the mbox file directly, so that git-am did not need to stop and ask me to resolve the patch.

It seems that Apple's Mail.app just doesn't like to send patches without destroying them. If you do wind up sending another patch in the future it may just be easier if you attach the mbox that format-patch creates, instead of trying to inline it in the message body.

On Sat, Aug 04, 2007 at 02:55:16AM -0400, Shawn O. Pearce wrote:

Your mailer claims this message is in us-ascii, but I think it isn't...

I tried reproducing the encoding breakage and it ended up fine. I just edited the patch in the .dotest directory (looks like the leading spaces were all stripped) and it applied fine when I re-ran "git-am".

Are you sure it didn't get munged by your editor when you hand-edited the mbox file?

-Peff

Jeff King <peff@peff.net> wrote:

My mutt-foo isn't very good. I tried to tell it utf-8, but I think its ignoring me:

  set allow_8bit=yes
  set charset=utf8

:-/
 

I just tried to reproduce it myself and I can't do whatever I did before again now; it Just Works(tm). *sigh* No idea how I messed the patch application up earlier, but I did.

It wasn't my patch editing. My vi clone only works on bytes, so it doesn't care about character encodings and won't mangle them unless I edit a utf-8 multibyte sequence by hand. Which I'm sure I didn't do. And the first time I messed up the apply I was fixing up only .dotest/patch, which was most certainly just us-ascii.

I'm actually pretty good about making sure I don't munge people's non-ASCII names, but my mutt seems to think us-ascii is the only character encoding in the world.

On Sat, Aug 04, 2007 at 03:33:21AM -0400, Shawn O. Pearce wrote:

Try looking at the send_charset config option; by default mutt will try to send us-ascii if possible. Also, should it be "utf-8"?

OK, given that I couldn't reproduce it either, we should perhaps chalk it up to cosmic rays.

-Peff

Jeff King <peff@peff.net> wrote:

Thanks, that actually did the trick.  This message might actually
arrive to you encoded in UTF-8.  Not that it matters.  ;-)
 

Or more likely the gap between the keyboard and the chair (aka me). I may have actually done something at one point to damage that mbox. git-am ran anyway, but gave me a garbled author name. Always blame the user, it probably really is his fault. ;-)

On Sat, 4 Aug 2007, Jeff King wrote:

Actually, the email claims it was iso-latin1, at least here. Which the *body* of the email apparently really was.

However (and this is a pretty common thing), the *headers* are unspecified, and a lot of email clients seem to think that if that happens, they default to US-ASCII and think that those iso-latin1 characters are crud.

Which is a damn shame. "alpine" does this, and it irritates me no end. I see emails where I can read the body fine, but it shows '????' for subject lines and authors even though it's the exact same character set.

Stupid, stupid, stupid.

Dammit, if the thing says

	Content-type: text/plain; charset=ISO-8859-1; format=flowed

(which it did), then yes, by some idiotic reading of the RFC's that probably only affects the body of the email. But those headers (and the "From:" line in particular) were *also* in ISO-8859-1, and email clients should default to using the same character set unless something else is said.

Btw, I suspect git "mailsplit" gets this wrong too. I rant and rave, but in the end, I solved it by just having the code guess sanely (commit b59d398beab604e577846ef8393735478c1ca3c2 makes things come out right in practice, regardless) instead of trying to do something "technically correct".

			Linus

On Sat, Aug 04, 2007 at 09:37:17AM -0700, Linus Torvalds wrote:

I think something is munging along the way for at least one of us. My copy of the mail clearly says:

  Content-type: text/plain; charset=us-ascii

and it has been through nothing between vger and my disk except qmail (and there tends to be no munging there, since qmail accepts 8bit smtp).

The "from" header, on the other hand, is encoded in rfc2047-style iso-8859-1.

-Peff

On Sat, Aug 04, 2007 at 09:37:17AM -0700, Linus Torvalds wrote:

Well, that _is_ what the standard says, I believe. I agree with you that practice is more important than a standard, and if there are high-bit characters in the 'From' field, I think that using the body charset is a reasonable guess (although keep in mind that the "body" could be hidden below a multipart/mixed, multipart/alternative, or some other arcane structure).

But I really have no idea why fully mime-aware mailers refuse to use rfc2047 encoding of the headers. In fact, my copy of the message you sent (to which I am replying) has munged Väinö's name in the cc header, because it failed to use rfc2047 encoding. I'm surprised that alpine would fail to get that right.

-Peff

On Aug 4, 2007, at 09:55, Shawn O. Pearce wrote:

You are right in that Mail.app seems to eat up the whitespaces in the patch. I emailed the patch first to myself, and everything seemed fine, should have tested it with git-am rather than eyeballing it, sorry.

About the name-munging, that didn't happen for me, after i fixed the spacing with Vim, the name shows up correctly in Git log. It seems that the email is ISO-8859-1 encoded, I'll enforce UTF-8 encoding next time if it helps, and I'll see if I can send an inlined patch which works.

-- Väinö