Re: [PATCH/RFC] Add support for the google-chrome web browser
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Jan 5, 2010, 18:56 UTC
- 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:
Show 17 quoted lines
> 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