git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 5/6] web--browse: use (x-)www-browser if available
Date: Wed, 1 Dec 2010 11:59:13 +0100	[thread overview]
Message-ID: <AANLkTinzCeaiFoL4a-+c6wuJoUQ68zC9vE8AoHfmvN-F@mail.gmail.com> (raw)
In-Reply-To: <AANLkTik-OKsUK2aJCDR0Q-FyQM=rrFQmx=Hwdyr5NzYt@mail.gmail.com>

On Tue, Nov 30, 2010 at 9:22 AM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> On Tue, Nov 30, 2010 at 5:02 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Mon, Nov 29, 2010 at 8:05 PM, Giuseppe Bilotta
>> <giuseppe.bilotta@gmail.com> wrote:
>>> We allow valid_tool to be false in the x-www-browser case, in which
>>> case we test www-browser, and if it's still not valid we go on and use
>>> the previous paths. So we cannot die in case of an invalid
>>> (x-)www-browser.
>>
>> Yeah, you are right, but we could die after the "for i in $wwwbrowser"
>> loop if both are invalid.
>
> Why? If both are invalid, proceeding with the previous strategy of
> looking for a browser we _should_ be looking for any browser we know
> about, even if it's not set as the default system browser.

Currently we have:

97     if test -n "$browser" && ! valid_tool "$browser"; then
98         echo >&2 "git config option $opt set to unknown browser: $browser"
99         echo >&2 "Resetting to default..."
100         unset browser
101     fi

So if we want to be consistent with that behavior, we should probably do the
same thing if (x-)www-browser is set but we don't support it.

>>> But there's a bug in the www-brower testing, it needs
>>> an else that resets browser to the empty string.
>>
>> I thought it was by design that you did not reset it...
>> So yeah it is clearer and nicer for the user if you either reset
>> browser or just die if both (x-)www-browser are invalid. If you decide
>> to reset browser, perhaps a warning or an information message telling
>> that both are unknown would be nice.
>
> I can do that. Should it be a warning about reporting the lack of
> support to us, or just a warning that we are not going to use it even
> if it's defined?

I think it should be a warning that we are not going to use it even
if it's defined, to be consistent with the code pasted above.

If you think of something better or want to remove the warnings, please do
it in another patch.

> While we're at it: I was considering adding support for the BROWSER
> env var (a colon-separated list of browsers executables or "browser
> %s" strings).
>
> All of this is going to make the web--browse script very similar to
> the sensible-browser script in Debian, with the difference that we go
> at length to ensure that stuff is opened in a new tab, whereas
> Debian's sensible-browser doesn't. Should we just support
> sensible-browser instead of (x-)www-browser/BROWSER, and let it open
> anything?

I think most users prefer to open stuff in a new tab if possible.

Thanks,
Christian.

  reply	other threads:[~2010-12-01 10:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-29 14:47 [PATCH 0/6] web--browse cleanups and extensions Giuseppe Bilotta
2010-11-29 14:47 ` [PATCH 1/6] CodingGuidelines: mention whitespace preferences for shell scripts Giuseppe Bilotta
2010-11-30  0:30   ` Junio C Hamano
2010-11-30  8:11     ` Giuseppe Bilotta
2010-11-29 14:47 ` [PATCH 2/6] web--browse: coding style Giuseppe Bilotta
2010-11-29 14:47 ` [PATCH 3/6] web--browse: split valid_tool list Giuseppe Bilotta
2010-11-29 16:44   ` Jonathan Nieder
2010-11-29 19:19     ` Giuseppe Bilotta
2010-11-29 20:24     ` Junio C Hamano
2010-11-29 14:47 ` [PATCH 4/6] web--browse: support opera, seamonkey and elinks Giuseppe Bilotta
2010-11-29 14:47 ` [PATCH 5/6] web--browse: use (x-)www-browser if available Giuseppe Bilotta
2010-11-29 16:18   ` Christian Couder
2010-11-29 16:25     ` Christian Couder
2010-11-29 19:05     ` Giuseppe Bilotta
2010-11-30  4:02       ` Christian Couder
2010-11-30  8:22         ` Giuseppe Bilotta
2010-12-01 10:59           ` Christian Couder [this message]
2010-12-01 11:46             ` Giuseppe Bilotta
2010-12-01 15:49               ` Jonathan Nieder
2010-11-29 16:48   ` Jonathan Nieder
2010-11-29 19:16     ` Giuseppe Bilotta
2010-11-29 14:47 ` [PATCH 6/6] web--browse: special-case chromium path Giuseppe Bilotta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinzCeaiFoL4a-+c6wuJoUQ68zC9vE8AoHfmvN-F@mail.gmail.com \
    --to=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=giuseppe.bilotta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).