On Sat, Nov 29, 2014 at 12:09:17PM -0800, W. Trevor King wrote:
On Sat, Nov 29, 2014 at 10:40:01AM +0100, Michal Sojka wrote:
On Út, říj 28 2014, W. Trevor King wrote:
+_spawn(
+args=['git', 'init', '--separate-git-dir', NMBGIT, workdir],
+wait=True
Hello everyone :),
I like Git, so when folks suggest storing things in Git, I'm usually
excited ;). Eric Wong has been working on some tools to store email
in a Git repository, and his client-side code is ssoma [1]. I wanted
a bit more metadata than the stock ssoma-mda [2], and ended up just
Hello everyone :),
I like Git, so when folks suggest storing things in Git, I'm usually
excited ;). Eric Wong has been working on some tools to store email
in a Git repository, and his client-side code is ssoma [1]. I wanted
a bit more metadata than the stock ssoma-mda [2], and ended up just
On Fri, Oct 31, 2014 at 02:04:50PM -0400, Jesse Rosenthal wrote:
> W. Trevor King writes:
> > On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
> >> We instead initalize the dictionary using the dict comprehension
> >> and then update it with the values fr
On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
> We instead initalize the dictionary using the dict comprehension and
> then update it with the values from the tree. This will work with
> both python2 and python3.
Dict comprehensions are new in 2.7 [1,2], so this drops support
On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
We instead initalize the dictionary using the dict comprehension and
then update it with the values from the tree. This will work with
both python2 and python3.
Dict comprehensions are new in 2.7 [1,2], so this drops support for
On Fri, Oct 31, 2014 at 02:04:50PM -0400, Jesse Rosenthal wrote:
W. Trevor King writes:
On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
We instead initalize the dictionary using the dict comprehension
and then update it with the values from the tree. This will work
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal:
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal:
On Sat, Oct 11, 2014 at 09:02:20AM +0200, David Bremner wrote:
> W. Trevor King writes:
> > On Sat, Oct 11, 2014 at 06:53:11AM +0200, David Bremner wrote:
> >> W. Trevor King writes:
> >> > but I expect that closing stdin is more portable than the
> >>
On Sat, Oct 11, 2014 at 09:02:20AM +0200, David Bremner wrote:
W. Trevor King writes:
On Sat, Oct 11, 2014 at 06:53:11AM +0200, David Bremner wrote:
W. Trevor King writes:
but I expect that closing stdin is more portable than the
/dev/null path.
/dev/null is part of POSIX
Maybe
On Sat, Oct 11, 2014 at 06:53:11AM +0200, David Bremner wrote:
> W. Trevor King writes:
> > but I expect that closing stdin is more portable than the /dev/null
> > path.
>
> /dev/null is part of POSIX
Maybe folks want to use nmbug on Windows or some other crazy non-POSIX
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal:
For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.
The empty-blob hash-object call avoids errors like:
$ nmbug commit
error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for
'tags/...'
fatal:
On Sat, Oct 11, 2014 at 06:53:11AM +0200, David Bremner wrote:
W. Trevor King writes:
but I expect that closing stdin is more portable than the /dev/null
path.
/dev/null is part of POSIX
Maybe folks want to use nmbug on Windows or some other crazy non-POSIX
OS? I don't know how Windows
For more details, see the commit message for 7f2cb3be (nmbug:
Translate to Python, 2014-10-03). I realized while writing this that
the 7f2cb3be commit message has:
* 'nmbug log' now execs 'git log', as there's no need to keep the
Python process around once we've launched Git there.
But we
On Tue, Oct 07, 2014 at 08:30:34AM +0200, David Bremner wrote:
> W. Trevor King writes:
> > This is mostly culled from the commit message for 7f2cb3be (nmbug:
> > Translate to Python, 2014-10-03). I realized while writing it
> > that the 7f2cb3be commit message has:
>
On Tue, Oct 07, 2014 at 08:30:34AM +0200, David Bremner wrote:
W. Trevor King writes:
This is mostly culled from the commit message for 7f2cb3be (nmbug:
Translate to Python, 2014-10-03). I realized while writing it
that the 7f2cb3be commit message has:
This seems a bit long for a NEWS
For more details, see the commit message for 7f2cb3be (nmbug:
Translate to Python, 2014-10-03). I realized while writing this that
the 7f2cb3be commit message has:
* 'nmbug log' now execs 'git log', as there's no need to keep the
Python process around once we've launched Git there.
But we
This is mostly culled from the commit message for 7f2cb3be (nmbug:
Translate to Python, 2014-10-03). I realized while writing it that
the 7f2cb3be commit message has:
* 'nmbug log' now execs 'git log', as there's no need to keep the
Python process around once we've launched Git there.
But
This is mostly culled from the commit message for 7f2cb3be (nmbug:
Translate to Python, 2014-10-03). I realized while writing it that
the 7f2cb3be commit message has:
* 'nmbug log' now execs 'git log', as there's no need to keep the
Python process around once we've launched Git there.
But
The 'if args.func == help' block at the end avoids:
AttributeError: 'functools.partial' object has no attribute '__code__'
---
devel/nmbug/nmbug | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index
-The second character (if present) represents a difference between remote
-git and local. Typically C needs to be run to update this.
-
-=over 8
-
-
-=item B
-
-Tag is present in remote, but not in local git.
-
-
-=item B
-
-Tag is present in local git, but not in remote git.
-
-
-=back
-
-=head1
]: id:d44bb6ad59ee0a30ac4a8d2e9fe50e3b98d1c408.1411572592.git.wking at
tremily.us
http://thread.gmane.org/gmane.mail.notmuch.general/19108
W. Trevor King (2):
nmbug: Translate to Python
nmbug: Add a 'help' command for folks who don't like --help
devel/nmbug/nmbug | 1544
The 'if args.func == help' block at the end avoids:
AttributeError: 'functools.partial' object has no attribute '__code__'
---
devel/nmbug/nmbug | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index
]: id:d44bb6ad59ee0a30ac4a8d2e9fe50e3b98d1c408.1411572592.git.wk...@tremily.us
http://thread.gmane.org/gmane.mail.notmuch.general/19108
W. Trevor King (2):
nmbug: Translate to Python
nmbug: Add a 'help' command for folks who don't like --help
devel/nmbug/nmbug | 1544
+# W. Trevor King wk...@tremily.us
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version
On Thu, Oct 02, 2014 at 04:39:41PM -0400, Austin Clements wrote:
> On Thu, 02 Oct 2014, W. Trevor King wrote:
> > On Thu, Oct 02, 2014 at 03:19:08PM -0400, Austin Clements wrote:
> >> This patch simplifies notmuch_database_close to explicitly abort
> >> any outstandin
On Thu, Oct 02, 2014 at 03:19:08PM -0400, Austin Clements wrote:
> This patch simplifies notmuch_database_close to explicitly abort any
> outstanding transaction and then just call Database::close. This
> works for both read-only and read/write databases, takes care of
> committing changes,
On Thu, Oct 02, 2014 at 03:19:08PM -0400, Austin Clements wrote:
This patch simplifies notmuch_database_close to explicitly abort any
outstanding transaction and then just call Database::close. This
works for both read-only and read/write databases, takes care of
committing changes, unifies
On Thu, Oct 02, 2014 at 04:39:41PM -0400, Austin Clements wrote:
On Thu, 02 Oct 2014, W. Trevor King wrote:
On Thu, Oct 02, 2014 at 03:19:08PM -0400, Austin Clements wrote:
This patch simplifies notmuch_database_close to explicitly abort
any outstanding transaction and then just call
On Wed, Sep 24, 2014 at 05:32:50PM -0400, Austin Clements wrote:
> + * If the caller is currently in an atomic section (there was a
> + * notmuch_database_begin_atomic without a matching
> + * notmuch_database_end_atomic), this will abort the atomic section,
> + * discarding any modifications made
On Wed, Sep 24, 2014 at 05:20:23PM -0400, Austin Clements wrote:
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index fe2340b..5c40c67 100644
> --- a/lib/notmuch.h
> +++ b/lib/notmuch.h
> @@ -292,6 +292,11 @@ notmuch_database_open (const char *path,
> * notmuch_database_close can be called
On Wed, Sep 24, 2014 at 10:13:31PM +0200, David Bremner wrote:
> W. Trevor King writes:
> I think it would be better to write our own, not because of licensing
> issues, but because the user of the notmuch API won't know what a xapian
> commit is.
Between version control and datab
On Wed, Sep 24, 2014 at 09:25:20PM +0200, David Bremner wrote:
> I think the fact that you have to close the notmuch database (when
> not using begin/end atomic) to get a commit is surprising for many
> people, so it would be nice to make that clearer somehow.
It looks like Xapian is GPLv2+, so
On Wed, Sep 24, 2014 at 08:09:27PM +0200, David Bremner wrote:
> W. Trevor King writes:
> > Ah, I thought the implicit flush/commit was just in our code.
> > Since it's also in the underlying Xapian close, then this patch
> > looks pretty good to me. I'd mention Xa
-
-
-=item B
-
-Tag is present in local git, but not in remote git.
-
-
-=back
-
-=head1 DUMP FORMAT
-
-Each tag $tag for message with Message-Id $id is written to
-an empty file
-
- tags/encode($id)/encode($tag)
-
-The encoding preserves alphanumerics, and the characters "+-_@=.:,"
-(not the quotes).
) 2011-2014 David Bremner da...@tethera.net
+# W. Trevor King wk...@tremily.us
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3
On Wed, Sep 24, 2014 at 09:25:20PM +0200, David Bremner wrote:
I think the fact that you have to close the notmuch database (when
not using begin/end atomic) to get a commit is surprising for many
people, so it would be nice to make that clearer somehow.
It looks like Xapian is GPLv2+, so we
On Wed, Sep 24, 2014 at 10:13:31PM +0200, David Bremner wrote:
W. Trevor King writes:
I think it would be better to write our own, not because of licensing
issues, but because the user of the notmuch API won't know what a xapian
commit is.
Between version control and databases, I feel like
On Wed, Sep 24, 2014 at 05:20:23PM -0400, Austin Clements wrote:
diff --git a/lib/notmuch.h b/lib/notmuch.h
index fe2340b..5c40c67 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -292,6 +292,11 @@ notmuch_database_open (const char *path,
* notmuch_database_close can be called multiple
On Mon, Sep 22, 2014 at 06:50:50PM +, Austin Clements wrote:
> Quoth W. Trevor King on Sep 22 at 9:59 am:
> > On Mon, Sep 22, 2014 at 11:43:35AM -0400, Austin Clements wrote:
> > > This patch simplifies notmuch_database_close to just call
> > > Database::close. Th
On Mon, Sep 22, 2014 at 10:19:35AM -0700, W. Trevor King wrote:
> I like nmbug's distributed tag maintenance, but not everyone has
> notmuch/nmbug installed locally (yet ;). However, everyone that I
> know does have a browser and a mail client. They can submit
> messages with their
I like nmbug's distributed tag maintenance, but not everyone has
notmuch/nmbug installed locally (yet ;). However, everyone that I
know does have a browser and a mail client. They can submit messages
with their mail client already, but we've been missing a way for them
to help tag messages.
On Mon, Sep 22, 2014 at 11:43:35AM -0400, Austin Clements wrote:
> This patch simplifies notmuch_database_close to just call
> Database::close. This works for both read-only and read/write
> databases, takes care of committing changes, unifies the exception
> handling path, and codifies aborting
On Mon, Sep 22, 2014 at 11:43:35AM -0400, Austin Clements wrote:
This patch simplifies notmuch_database_close to just call
Database::close. This works for both read-only and read/write
databases, takes care of committing changes, unifies the exception
handling path, and codifies aborting
On Mon, Sep 22, 2014 at 10:19:35AM -0700, W. Trevor King wrote:
I like nmbug's distributed tag maintenance, but not everyone has
notmuch/nmbug installed locally (yet ;). However, everyone that I
know does have a browser and a mail client. They can submit
messages with their mail client
On Mon, Sep 22, 2014 at 06:50:50PM +, Austin Clements wrote:
Quoth W. Trevor King on Sep 22 at 9:59 am:
On Mon, Sep 22, 2014 at 11:43:35AM -0400, Austin Clements wrote:
This patch simplifies notmuch_database_close to just call
Database::close. This works for both read-only and read
On Mon, Sep 15, 2014 at 08:09:11PM +0200, David Bremner wrote:
> W. Trevor King writes:
> > Give it a spin to kick the tires, and reply to the v4 patch saying
> > that none of the pieces fell off while you were kicking it ;).
> > Basically, it's just waiting for review and
On Mon, Sep 15, 2014 at 05:32:59PM +0100, David Edmondson wrote:
> On Mon, Sep 15 2014, W. Trevor King wrote:
> > On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
> >> On Sun, Jul 06 2014, W. Trevor King wrote:
> >> > For folks that want to start versi
On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
> On Sun, Jul 06 2014, W. Trevor King wrote:
> > For folks that want to start versioning a new tag-space, instead
> > of cloning one that someone else has already started.
>
> I tried this patch, and it (app
On Mon, Sep 15, 2014 at 03:26:26PM +0100, David Edmondson wrote:
> On Mon, Sep 15 2014, W. Trevor King wrote:
> > Does nmbug not do this for you? This is exactly what it was designed
> > to do (sync tags).
>
> Perhaps. Is anyone using it for personal tag sync?
I will once
On Mon, Sep 15, 2014 at 02:49:16PM +0100, David Edmondson wrote:
> On Thu, May 20 2010, David Edmondson wrote:
> (Wow, was it really more than four years ago?)
>
> > What's the current state of the art in merging tags from multiple
> > machines?
> >
> > In my own case the contents of the mail
On Mon, Sep 15, 2014 at 02:49:16PM +0100, David Edmondson wrote:
On Thu, May 20 2010, David Edmondson wrote:
(Wow, was it really more than four years ago?)
What's the current state of the art in merging tags from multiple
machines?
In my own case the contents of the mail store can be
On Mon, Sep 15, 2014 at 03:26:26PM +0100, David Edmondson wrote:
On Mon, Sep 15 2014, W. Trevor King wrote:
Does nmbug not do this for you? This is exactly what it was designed
to do (sync tags).
Perhaps. Is anyone using it for personal tag sync?
I will once my Python translation lands
On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
On Sun, Jul 06 2014, W. Trevor King wrote:
For folks that want to start versioning a new tag-space, instead
of cloning one that someone else has already started.
I tried this patch, and it (appeared) to work for me. Given
On Mon, Sep 15, 2014 at 05:32:59PM +0100, David Edmondson wrote:
On Mon, Sep 15 2014, W. Trevor King wrote:
On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
On Sun, Jul 06 2014, W. Trevor King wrote:
For folks that want to start versioning a new tag-space, instead
On Mon, Sep 15, 2014 at 08:09:11PM +0200, David Bremner wrote:
W. Trevor King writes:
Give it a spin to kick the tires, and reply to the v4 patch saying
that none of the pieces fell off while you were kicking it ;).
Basically, it's just waiting for review and a consensus that it's
a solid
eeds to be run to update this.
-
-=over 8
-
-
-=item B
-
-Tag is present in remote, but not in local git.
-
-
-=item B
-
-Tag is present in local git, but not in remote git.
-
-
-=back
-
-=head1 DUMP FORMAT
-
-Each tag $tag for message with Message-Id $id is written to
-an empty file
-
-
for tags of
-interest to nmbug. If not specified 'notmuch::' is used.
+#!/usr/bin/env python
+#
+# Copyright (c) 2011-2014 David Bremner da...@tethera.net
+# W. Trevor King wk...@tremily.us
+#
+# This program is free software: you can redistribute it and/or modify
+# it under
On Tue, Aug 05, 2014 at 10:24:10PM -0300, David Bremner wrote:
> I have a local commit that deletes a couple tags; when I attempt to
> merge I get complaints about local changes to files.
>
> error: Your local changes to the following files would be overwritten by
> merge:
>
On Tue, Aug 05, 2014 at 10:16:10PM -0300, David Bremner wrote:
> David Bremner writes:
> > I did notice that merging was noticably noisier than I remembered.
>
> rejected pushes also seem noisier than before; I'm not sure the
> python backtrace adds anything here.
>
> To nmbug at
On Mon, Aug 04, 2014 at 09:14:46PM -0300, David Bremner wrote:
> W. Trevor King writes:
> > * Commands are no longer split into "most common", "other useful",
> > and "less common" sets. If we need something like this, I'd
> > pr
On Mon, Aug 04, 2014 at 09:14:46PM -0300, David Bremner wrote:
W. Trevor King writes:
* Commands are no longer split into most common, other useful,
and less common sets. If we need something like this, I'd
prefer workflow examples highlighting common commands in the
module
On Tue, Aug 05, 2014 at 10:16:10PM -0300, David Bremner wrote:
David Bremner writes:
I did notice that merging was noticably noisier than I remembered.
rejected pushes also seem noisier than before; I'm not sure the
python backtrace adds anything here.
To
On Tue, Aug 05, 2014 at 10:24:10PM -0300, David Bremner wrote:
I have a local commit that deletes a couple tags; when I attempt to
merge I get complaints about local changes to files.
error: Your local changes to the following files would be overwritten by
merge:
I should also import print_function and unicode_literals from
__future__ for Python 2.x compatibility, since I use print() once and
never use bytes. I hadn't turned up any problems with 2.x without the
__future__ imports, but it's nice to be explicit ;).
Cheers,
Trevor
--
This email may be
On Sun, Jul 20, 2014 at 03:59:49PM -0700, W. Trevor King wrote:
> +def pull(repository=None, refspecs=None):
> +"""
> +Pull (merge) remote repository changes to notmuch.
> +
> +'pull' is equivalent to 'fetch' followed by 'merge'. We use the
> +G
On Sun, Jul 20, 2014 at 03:59:49PM -0700, W. Trevor King wrote:
> Most of the user-facing interface is the same, but there are a few
> changes, where reproducing the original interface was too difficult
> or I saw a change to make the underlying Git UI accessible:
It's not listed in t
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
This allows us to capture stdout and stderr separately, and do other
explicit subprocess manipulation without resorting to external
packages. It should be compatible with Python 2.6 and later
(including the 3.x series), although with 2.6 you'll need the external
argparse package.
Most of the
On Sun, Jul 20, 2014 at 03:59:49PM -0700, W. Trevor King wrote:
Most of the user-facing interface is the same, but there are a few
changes, where reproducing the original interface was too difficult
or I saw a change to make the underlying Git UI accessible:
It's not listed in the commit
On Sun, Jul 20, 2014 at 03:59:49PM -0700, W. Trevor King wrote:
+def pull(repository=None, refspecs=None):
+
+Pull (merge) remote repository changes to notmuch.
+
+'pull' is equivalent to 'fetch' followed by 'merge'. We use the
+Git-configured repository for your current
I should also import print_function and unicode_literals from
__future__ for Python 2.x compatibility, since I use print() once and
never use bytes. I hadn't turned up any problems with 2.x without the
__future__ imports, but it's nice to be explicit ;).
Cheers,
Trevor
--
This email may be
On Thu, Jul 17, 2014 at 06:28:55AM -0300, David Bremner wrote:
W. Trevor King writes:
On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
W. Trevor King writes:
If we don't have an upstream, there is nothing to merge, so
nothing is unmerged. This avoids errors like
On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
W. Trevor King writes:
If we don't have an upstream, there is nothing to merge, so
nothing is unmerged. This avoids errors like:
pushed this one patch.
Without the stderr-catching of something like patch 3, this means
folks
On Tue, Jul 15, 2014 at 08:49:58PM -0300, David Bremner wrote:
> "W. Trevor King" writes:
>
> > + if ($dir eq '-2|') {
> > +$dir = '-|';
> > + }
> > +
>
> I think I'd prefer an extra flag, rather than making new syntax.
> The exist
On Tue, Jul 15, 2014 at 08:54:28PM -0300, David Bremner wrote:
> "W. Trevor King" writes:
>
> > +sub do_init {
> > + my $tempwork = tempdir ('/tmp/nmbug-init.XX', CLEANUP => 1);
> > + system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) ==
On Tue, Jul 15, 2014 at 08:44:53PM -0300, David Bremner wrote:
> W. Trevor King writes:
> > - my $fetch_head = git ('rev-parse', $commit);
> > + my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
> > + if ($status) {
> > +return 0;
> > + }
On Tue, Jul 15, 2014 at 08:44:53PM -0300, David Bremner wrote:
W. Trevor King writes:
- my $fetch_head = git ('rev-parse', $commit);
+ my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
+ if ($status) {
+return 0;
+ }
Could there be other errors here, other
On Tue, Jul 15, 2014 at 08:54:28PM -0300, David Bremner wrote:
W. Trevor King wk...@tremily.us writes:
+sub do_init {
+ my $tempwork = tempdir ('/tmp/nmbug-init.XX', CLEANUP = 1);
+ system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) == 0
+or die 'git init' exited
On Tue, Jul 15, 2014 at 08:49:58PM -0300, David Bremner wrote:
W. Trevor King wk...@tremily.us writes:
+ if ($dir eq '-2|') {
+$dir = '-|';
+ }
+
I think I'd prefer an extra flag, rather than making new syntax.
The existing syntax is not pretty, but it is standard perl
On Mon, Jul 14, 2014 at 06:51:22AM -0300, David Bremner wrote:
> W. Trevor King writes:
> > On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> >> I consider it a useful feature that it works without the user
> >> configuring a local branch. I agree
On Mon, Jul 14, 2014 at 06:51:22AM -0300, David Bremner wrote:
W. Trevor King writes:
On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
I consider it a useful feature that it works without the user
configuring a local branch. I agree that in more complex setups
On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> I consider it a useful feature that it works without the user
> configuring a local branch. I agree that in more complex setups
> this ambiguity is not as nice, but I'd rather it was only the
> minority of users with unusual setups
On Sun, Jul 13, 2014 at 09:05:41AM +0300, Tomi Ollila wrote:
> I am satisfied with rst-man2any.py, but as being normal picky me I
> wonder whether the command prefix 'rst-' is being too generic
> i.e. is invading that "namespace". If no one else has the same
> feeling (or the feeling is just wrong
On Sun, Jul 13, 2014 at 09:05:41AM +0300, Tomi Ollila wrote:
I am satisfied with rst-man2any.py, but as being normal picky me I
wonder whether the command prefix 'rst-' is being too generic
i.e. is invading that namespace. If no one else has the same
feeling (or the feeling is just wrong (or
On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
I consider it a useful feature that it works without the user
configuring a local branch. I agree that in more complex setups
this ambiguity is not as nice, but I'd rather it was only the
minority of users with unusual setups
We already fall back to rst2man if Sphinx isn't available for building
the man pages. With this commit we'll fall back to rst2html for
building the HTML docs too. The only tricky bit here is that
HAVE_SPHINX explicitly checks for sphinx.writers.manpage. I'm just
assuming sphinx.writers.html
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
For example, with these changes we can build HTML output using:
$ rst-man2any.py -c rst2html -i ${SRCDIR} -o ${OUTDIR} -e html
The extension adjustment ensures that the output filenames from the
above command match what we currently generate with sphinx-html.
Adding argparse handling at the
excefile is gone in Python 3 [1]. Instead of exec-ing the
configuration, it's easier to insert the source directory in Python's
path [2], and just import the configuration. With this change,
prerst2man.py is compatible with both Python 2 and 3.
[1]:
Gentoo's dev-python/docutils-0.10 installs Docutils scripts with a
*.py extension, so I have /usr/bin/rst2man.py and no rst2man script.
This patch supports users with both types of systems by checking for
rst2man, falling back on rst2man.py, and giving up only if neither is
found. Users can also
at guru.guru-group.fi
http://article.gmane.org/gmane.mail.notmuch.general/18653
W. Trevor King (5):
doc: Allow rst2man.py as an alternative to rst2man
doc/prerst2man.py: Convert execfile to import
doc/rst-man2any.py: Adjust to handle any output format, not just man
pages
doc
The rst2man target was removed in 9d9a700 (doc: build man pages at
build time; introduce HAVE_SPHINX, HAVE_RST2MAN, 2014-03-13), but a
reference in the install docs slipped through. While I was removing
that reference, I also:
* Converted doc/INSTALL to reStructuredText, so I can link to Sphinx
@guru.guru-group.fi
http://article.gmane.org/gmane.mail.notmuch.general/18653
W. Trevor King (5):
doc: Allow rst2man.py as an alternative to rst2man
doc/prerst2man.py: Convert execfile to import
doc/rst-man2any.py: Adjust to handle any output format, not just man
pages
doc: Consolidate
101 - 200 of 489 matches
Mail list logo
