From: Avery Pennarun <apenwarr@gmail.com>
Date: Tue, 05 Jan 2010 18:56:13 GMT
Subject: Re: [PATCH/RFC] Add support for the google-chrome web browser
Message-ID: <32541b131001051056o5853b1d2xd57d75d9a62f9f1a@mail.gmail.com>
In-Reply-To: <7v8wccz99g.fsf@alter.siamese.dyndns.org>

On Tue, Jan 5, 2010 at 1:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> On Tue, Jan 5, 2010 at 12:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Then we don't even have to add any specific support for "google-chrome" or
>>> anything that takes "$command $path..." and opens the documents.
>>>
>>> Is there a downside in this approach?
>>
>> If someone has another firefox-derived browser installed with a
>> different name and tries to use it, this default wouldn't do the right
>> "firefoxy" thing, and would instead fail strangely.  On the other
>> hand, right now it'll fail anyway, just not strangely.
>
> You probably didn't notice/understand why I singled out w3m/links/open and
> excluded firefox from the set.  There is no question that the ones that
> need custom command line need custom support.  But to support a new
> browser that takes a bog standard "command then args" command line, there
> is no reason to add cruft, every time somebody comes up with a new browser.

Yes, I'm probably missing something, that would be normal :)

My point is that, given a random browser name, you don't know whether
it's an easy one *or* if it needs to work more like firefox.

The current behaviour will barf right away (I think) because it
doesn't know.  If it instead had a default case that just assumed
non-firefox behaviour, then it would fail *strangely* (instead of
predictably) on browsers that needed special workarounds, such as an
as-yet-unknown firefox derivative.

Maybe this isn't important though.

Avery