git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jay Soffian" <jaysoffian+git@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: "Peter Oberndorfer" <kumbayo84@arcor.de>,
	"Catalin Marinas" <catalin.marinas@gmail.com>,
	git@vger.kernel.org
Subject: Re: [StGit PATCH 4/5] Simplify editor selection logic
Date: Wed, 30 Jan 2008 09:55:18 -0500	[thread overview]
Message-ID: <76718490801300655r3d1b5b41l2945b4f730faedb2@mail.gmail.com> (raw)
In-Reply-To: <20080130072828.GA24648@diana.vm.bytemark.co.uk>

On Jan 30, 2008 2:28 AM, Karl Hasselström <kha@treskal.com> wrote:
> You could write it kind of like this:
>
>   def e(key): return os.environ.get(key, None)
>   def c(key): return config.get(key)
>   editor = filter(None, [e('GIT_EDITOR'), c('stgit.editor'), c('core.editor'),
>                          e('VISUAL'), e('EDITOR'), 'vi'])[0]

Too clever by half if you ask me. Why not just:

editor = (os.environ.get('GIT_EDITOR') or
          config.get('stgit.editor') or
          config.get('core.editor') or
          os.environ.get('VISUAL') or
          os.environ.get('EDITOR') or
          'vi')

And be done with it?

> Of course, if we're going to have code like this in several places
> (you already mentioned the pager), we could build a function like
> this:
>
>   editor = get_config(['GIT_EDITOR', 'stgit.editor', 'core.editor',
>                        'VISUAL', 'EDITOR'], default = 'vi')
>
> that would differentiate between env variables and conf keys by
> looking for dots in the name or something.

def get_config(keys, default=None):
    rv = default
    for k in keys:
        if '.' in k:
            d = config
        else:
            d = os.environ
        if k in d:
            rv = d[k]
            break
    return rv

j.

  reply	other threads:[~2008-01-30 14:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29  2:58 kha/safe and kha/experimental updated Karl Hasselström
2008-01-29  3:02 ` [StGit PATCH 0/5] Various cleanups Karl Hasselström
2008-01-29  3:02   ` [StGit PATCH 1/5] Create index and worktree objects just once Karl Hasselström
2008-01-29  3:03   ` [StGit PATCH 2/5] Wrap excessively long line Karl Hasselström
2008-01-29  3:03   ` [StGit PATCH 3/5] Eliminate temp variable that's used just once Karl Hasselström
2008-01-29  3:04   ` [StGit PATCH 4/5] Simplify editor selection logic Karl Hasselström
2008-01-29 20:09     ` Peter Oberndorfer
2008-01-30  7:28       ` Karl Hasselström
2008-01-30 14:55         ` Jay Soffian [this message]
2008-01-30 17:57           ` Karl Hasselström
2008-01-29  3:06   ` [StGit PATCH 5/5] Let the caller supply the diff text to diffstat() Karl Hasselström
2008-01-29  3:10 ` [StGit PATCH 0/2] "stg clean" test+bugfix Karl Hasselström
2008-01-29  3:11   ` [StGit PATCH 1/2] Add test to ensure that "stg clean" preserves conflicting patches Karl Hasselström
2008-01-29  3:12   ` [StGit PATCH 2/2] Don't clean away patches with conflicts Karl Hasselström
2008-01-29  3:15 ` [StGit PATCH 0/4] Rewrite "stg edit" to use new infrastructure Karl Hasselström
2008-01-29  3:15   ` [StGit PATCH 1/4] Teach new infrastructure about the default author and committer Karl Hasselström
2008-01-29  3:15   ` [StGit PATCH 2/4] Teach new infrastructure to apply patches Karl Hasselström
2008-01-29  3:16   ` [StGit PATCH 3/4] Teach new infrastructure to diff two trees Karl Hasselström
2008-01-29 14:40     ` David Kågedal
2008-01-29 15:57       ` Karl Hasselström
2008-01-29  3:17   ` [StGit PATCH 4/4] Convert "stg edit" to the new infrastructure Karl Hasselström
2008-02-01  7:49   ` [StGit PATCH 0/3] "stg edit" fixups Karl Hasselström
2008-02-01  7:50     ` [StGit PATCH 1/3] Parse the date instead of treating it as an opaque string Karl Hasselström
2008-02-01  7:50     ` [StGit PATCH 2/3] Convert "stg edit" to the new infrastructure Karl Hasselström
2008-02-01  7:50     ` [StGit PATCH 3/3] It's possible to edit unapplied patches now Karl Hasselström

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=76718490801300655r3d1b5b41l2945b4f730faedb2@mail.gmail.com \
    --to=jaysoffian+git@gmail.com \
    --cc=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    --cc=kumbayo84@arcor.de \
    /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).