[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, "W. Trevor King"  wrote:

> On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
>> On Sat, Feb 08 2014, W. Trevor King wrote:
>> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
>> >> 
>> >> yeah, the colour scheme is not my favourite. For the sake of being
>> >> semi-constructive, I attach an alternative suggestion #ffd96e and
>> >> #bce.
>> >
>> > Works for me.
>> 
>> I'm fine with that too.
>
> Updated in my example and nmbug-status-python3 branch.
>
>> >> More importantly some of the threads are run together: e.g. 
>> >> 
>> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
>> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
>> >
>> > Both of those messages are part of the same thread
>> > (thread:eaab on my box, but I doubt thread IDs are
>> > portable), so I don't add a thread-separating space between them.
>> > Would you like more message-separating space even between messages
>> > in the same thread?
>> 
>> ?
>> 
>> I think the more space does not fix anything but it might help
>> regognizing message boundaries a bit (and thus would be a nice
>> feature).
>
> Added to my example and nmbug-status-python3 branch.  I'm using CSS
> for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
> inter-message spacing.  I think the colored-link (second message row)
> vs. default id (first message row) makes inter-message separation
> clear enough in that case.

The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
messages be too far apart from each other. I changed the padding-top
and padding-bottom values to 0.25em which IMHO is better...

> Cheers,
> Trevor

Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, "W. Trevor King"  wrote:

> On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
>> W. Trevor King writes:
>> > I'll remove this once the series lands, but I've currently got a
>> > preview up at http://tremily.us/status.html
>> 
>> yeah, the colour scheme is not my favourite. For the sake of being
>> semi-constructive, I attach an alternative suggestion #ffd96e and
>> #bce.
>
> Works for me.

I'm fine with that too.

>
>> More importantly some of the threads are run together: e.g. 
>> 
>> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
>> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
>
> Both of those messages are part of the same thread
> (thread:eaab on my box, but I doubt thread IDs are
> portable), so I don't add a thread-separating space between them.
> Would you like more message-separating space even between messages in
> the same thread?

They're in the same (notmuch) thread. Easily testable with

notmuch search id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" or 
id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

and therefore shown together. The commit 
02cafc84b4540cd0fb878121dcb3551b4ecd9fd1 made this happen always
(but without this this could have happened if there were no
other patches in new threads coming along in between.

I think the more space does not fix anything but it might help regognizing
message boundaries a bit (and thus would be a nice feature).

> Cheers,
> Trevor

Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:37:43PM +0200, Tomi Ollila wrote:
> On Sat, Feb 08 2014, W. Trevor King wrote:
> > On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
> >> On Sat, Feb 08 2014, W. Trevor King wrote:
> >> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> >> >> More importantly some of the threads are run together: e.g. 
> >> >> 
> >> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> >> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
> >> >
> >> > Both of those messages are part of the same thread
> >> > (thread:eaab on my box, but I doubt thread IDs are
> >> > portable), so I don't add a thread-separating space between them.
> >> > Would you like more message-separating space even between messages
> >> > in the same thread?
> >> 
> >> ?
> >> 
> >> I think the more space does not fix anything but it might help
> >> regognizing message boundaries a bit (and thus would be a nice
> >> feature).
> >
> > Added to my example and nmbug-status-python3 branch.  I'm using CSS
> > for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
> > inter-message spacing.  I think the colored-link (second message row)
> > vs. default id (first message row) makes inter-message separation
> > clear enough in that case.
> 
> The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
> messages be too far apart from each other. I changed the padding-top
> and padding-bottom values to 0.25em which IMHO is better...

0.25em works for me.  Branch and example updated.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[David Bremner]

"W. Trevor King"  writes:

 > I'll remove this once the series lands, but I've currently got a
 > preview up at http://tremily.us/status.html

 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion using colours
 #ffd96e and #bce.

 More importantly some of the threads are run together: e.g. 

 id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
 id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

-- next part --
A non-text attachment was scrubbed...
Name: colour.png
Type: image/png
Size: 89089 bytes
Desc: not available
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
> On Sat, Feb 08 2014, W. Trevor King wrote:
> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> >> W. Trevor King writes:
> >> > I'll remove this once the series lands, but I've currently got a
> >> > preview up at http://tremily.us/status.html
> >> 
> >> yeah, the colour scheme is not my favourite. For the sake of being
> >> semi-constructive, I attach an alternative suggestion #ffd96e and
> >> #bce.
> >
> > Works for me.
> 
> I'm fine with that too.

Updated in my example and nmbug-status-python3 branch.

> >> More importantly some of the threads are run together: e.g. 
> >> 
> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
> >
> > Both of those messages are part of the same thread
> > (thread:eaab on my box, but I doubt thread IDs are
> > portable), so I don't add a thread-separating space between them.
> > Would you like more message-separating space even between messages
> > in the same thread?
> 
> ?
> 
> I think the more space does not fix anything but it might help
> regognizing message boundaries a bit (and thus would be a nice
> feature).

Added to my example and nmbug-status-python3 branch.  I'm using CSS
for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
inter-message spacing.  I think the colored-link (second message row)
vs. default id (first message row) makes inter-message separation
clear enough in that case.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> W. Trevor King writes:
> > I'll remove this once the series lands, but I've currently got a
> > preview up at http://tremily.us/status.html
> 
> yeah, the colour scheme is not my favourite. For the sake of being
> semi-constructive, I attach an alternative suggestion #ffd96e and
> #bce.

Works for me.

> More importantly some of the threads are run together: e.g. 
> 
> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

Both of those messages are part of the same thread
(thread:eaab on my box, but I doubt thread IDs are
portable), so I don't add a thread-separating space between them.
Would you like more message-separating space even between messages in
the same thread?

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
 W. Trevor King writes:
  I'll remove this once the series lands, but I've currently got a
  preview up at http://tremily.us/status.html
 
 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion #ffd96e and
 #bce.

Works for me.

 More importantly some of the threads are run together: e.g. 
 
 id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
 id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

Both of those messages are part of the same thread
(thread:eaab on my box, but I doubt thread IDs are
portable), so I don't add a thread-separating space between them.
Would you like more message-separating space even between messages in
the same thread?

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, W. Trevor King wk...@tremily.us wrote:

 On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
 W. Trevor King writes:
  I'll remove this once the series lands, but I've currently got a
  preview up at http://tremily.us/status.html
 
 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion #ffd96e and
 #bce.

 Works for me.

I'm fine with that too.


 More importantly some of the threads are run together: e.g. 
 
 id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
 id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

 Both of those messages are part of the same thread
 (thread:eaab on my box, but I doubt thread IDs are
 portable), so I don't add a thread-separating space between them.
 Would you like more message-separating space even between messages in
 the same thread?

They're in the same (notmuch) thread. Easily testable with

notmuch search id:4eddf2b1.4288980a.0b74.5...@mx.google.com or 
id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

and therefore shown together. The commit 
02cafc84b4540cd0fb878121dcb3551b4ecd9fd1 made this happen always
(but without this this could have happened if there were no
other patches in new threads coming along in between.

I think the more space does not fix anything but it might help regognizing
message boundaries a bit (and thus would be a nice feature).

 Cheers,
 Trevor

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
  W. Trevor King writes:
   I'll remove this once the series lands, but I've currently got a
   preview up at http://tremily.us/status.html
  
  yeah, the colour scheme is not my favourite. For the sake of being
  semi-constructive, I attach an alternative suggestion #ffd96e and
  #bce.
 
  Works for me.
 
 I'm fine with that too.

Updated in my example and nmbug-status-python3 branch.

  More importantly some of the threads are run together: e.g. 
  
  id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
  id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
 
  Both of those messages are part of the same thread
  (thread:eaab on my box, but I doubt thread IDs are
  portable), so I don't add a thread-separating space between them.
  Would you like more message-separating space even between messages
  in the same thread?
 
 …
 
 I think the more space does not fix anything but it might help
 regognizing message boundaries a bit (and thus would be a nice
 feature).

Added to my example and nmbug-status-python3 branch.  I'm using CSS
for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
inter-message spacing.  I think the colored-link (second message row)
vs. default id (first message row) makes inter-message separation
clear enough in that case.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, W. Trevor King wk...@tremily.us wrote:

 On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
  
  yeah, the colour scheme is not my favourite. For the sake of being
  semi-constructive, I attach an alternative suggestion #ffd96e and
  #bce.
 
  Works for me.
 
 I'm fine with that too.

 Updated in my example and nmbug-status-python3 branch.

  More importantly some of the threads are run together: e.g. 
  
  id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
  id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
 
  Both of those messages are part of the same thread
  (thread:eaab on my box, but I doubt thread IDs are
  portable), so I don't add a thread-separating space between them.
  Would you like more message-separating space even between messages
  in the same thread?
 
 …
 
 I think the more space does not fix anything but it might help
 regognizing message boundaries a bit (and thus would be a nice
 feature).

 Added to my example and nmbug-status-python3 branch.  I'm using CSS
 for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
 inter-message spacing.  I think the colored-link (second message row)
 vs. default id (first message row) makes inter-message separation
 clear enough in that case.

The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
messages be too far apart from each other. I changed the padding-top
and padding-bottom values to 0.25em which IMHO is better...

 Cheers,
 Trevor

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:37:43PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
  On Sat, Feb 08 2014, W. Trevor King wrote:
   On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
   More importantly some of the threads are run together: e.g. 
   
   id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
   id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
  
   Both of those messages are part of the same thread
   (thread:eaab on my box, but I doubt thread IDs are
   portable), so I don't add a thread-separating space between them.
   Would you like more message-separating space even between messages
   in the same thread?
  
  …
  
  I think the more space does not fix anything but it might help
  regognizing message boundaries a bit (and thus would be a nice
  feature).
 
  Added to my example and nmbug-status-python3 branch.  I'm using CSS
  for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
  inter-message spacing.  I think the colored-link (second message row)
  vs. default id (first message row) makes inter-message separation
  clear enough in that case.
 
 The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
 messages be too far apart from each other. I changed the padding-top
 and padding-bottom values to 0.25em which IMHO is better...

0.25em works for me.  Branch and example updated.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 07:31:27AM -0800, W. Trevor King wrote:
> On Wed, Feb 05, 2014 at 05:24:56PM +0200, Tomi Ollila wrote:
> > Forgot to mention that the <, >, & etc. characters could also be
> > encoded in this patch series (to , ,  etc.)
> 
> Good point.  I'll xml.sax.saxutils.escape the message-id, from, and
> subject at the end of HtmlPage._message_display_data, and squash that
> into the Page / HtmlPage commit.

I added this as a new commit instead of squashing (since the escaping
wasn't present in the original nmbug-status), and also pushed the
color and radius reductions [1] to my nmbug-status-python3 branch.

Is this at the point where I should push v2 to the list, or do we want
to wait for more feedback first?

Cheers,
Trevor

[1]: http://mid.gmane.org/20140205152738.GJ14197 at odin.tremily.us

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 07:31:27AM -0800, W. Trevor King wrote:
 On Wed, Feb 05, 2014 at 05:24:56PM +0200, Tomi Ollila wrote:
  Forgot to mention that the , ,  etc. characters could also be
  encoded in this patch series (to lt;, gt;, amp; etc.)
 
 Good point.  I'll xml.sax.saxutils.escape the message-id, from, and
 subject at the end of HtmlPage._message_display_data, and squash that
 into the Page / HtmlPage commit.

I added this as a new commit instead of squashing (since the escaping
wasn't present in the original nmbug-status), and also pushed the
color and radius reductions [1] to my nmbug-status-python3 branch.

Is this at the point where I should push v2 to the list, or do we want
to wait for more feedback first?

Cheers,
Trevor

[1]: http://mid.gmane.org/20140205152738.gj14...@odin.tremily.us

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Thu, Feb 06, 2014 at 12:54:56AM +0200, Tomi Ollila wrote:
> On Wed, Feb 05 2014, "W. Trevor King" wrote:
> > On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
> >> #DFF for the light-blue works better for me.
> >
> > I'm fine with that.  As I said in my cover letter, I'm happy to have
> > alternative color schemes suggested.  Does anyone else want to chime
> > in on better defaults?  This should probably also be configurable via
> > status-config.json.  Maybe:
> >
> >{ "style": {"html": {"thread-colors": ["#DFF", "#FEF"]}}}
> 
> Maybe we can persuade David to test-run new notmuch-status in
> his production server before it is pushed to notmuch master, and
> bikeshed the style in http://nmbug.tethera.net/status/

I'll remove this once the series lands, but I've currently got a
preview up at http://tremily.us/status.html

> probably no-one is interested to configure those later (if we even
> get bikeshed comments... ;)

I suppose we can revisit this when someone with an existing color
scheme decides to use nmbug and nmbug-status as their bugtracker (red
a gray for Red Hat?  Blue and yellow for Python? ;).  Until then, I'm
fine with hardcoding this.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Wed, Feb 05 2014, "W. Trevor King"  wrote:

> On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
>> After I fixed the wrapper the program works fine on python 2.6.6.
>
> :)
>
>> now every other thread is background-colored (girly) pink (fef?)
>> and every other light blue (eff). for me the light blue is not
>> visible (there are no body background color set?)
>
> #EFF is visible to me, but it is light.
>
>> #DFF for the light-blue works better for me.
>
> I'm fine with that.  As I said in my cover letter, I'm happy to have
> alternative color schemes suggested.  Does anyone else want to chime
> in on better defaults?  This should probably also be configurable via
> status-config.json.  Maybe:
>
>{ "style": {"html": {"thread-colors": ["#DFF", "#FEF"]}}}

Maybe we can persuade David to test-run new notmuch-status in
his production server before it is pushed to notmuch master, and
bikeshed the style in http://nmbug.tethera.net/status/

> ?

probably no-one is interested to configure those later (if we even
get bikeshed comments... ;)

Tomi

>> I think rounded corners are nice but IMHO the round radius is too
>> big -- using 0.5mm for the radius would IMHO be better.
>
> No problem.
>
> Cheers,
> Trevor

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Thu, Feb 06, 2014 at 12:54:56AM +0200, Tomi Ollila wrote:
 On Wed, Feb 05 2014, W. Trevor King wrote:
  On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
  #DFF for the light-blue works better for me.
 
  I'm fine with that.  As I said in my cover letter, I'm happy to have
  alternative color schemes suggested.  Does anyone else want to chime
  in on better defaults?  This should probably also be configurable via
  status-config.json.  Maybe:
 
 { style: {html: {thread-colors: [#DFF, #FEF]}}}
 
 Maybe we can persuade David to test-run new notmuch-status in
 his production server before it is pushed to notmuch master, and
 bikeshed the style in http://nmbug.tethera.net/status/

I'll remove this once the series lands, but I've currently got a
preview up at http://tremily.us/status.html

 probably no-one is interested to configure those later (if we even
 get bikeshed comments... ;)

I suppose we can revisit this when someone with an existing color
scheme decides to use nmbug and nmbug-status as their bugtracker (red
a gray for Red Hat?  Blue and yellow for Python? ;).  Until then, I'm
fine with hardcoding this.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Wed, Feb 05 2014, Tomi Ollila  wrote:

> I have some comments on the new look -- which is pretty nice btw.
>
> now every other thread is background-colored (girly) pink (fef?)
> and every other light blue (eff). for me the light blue is not
> visible (there are no body background color set?)
>
> ... hmm, i added 'body { background-color: #FFF; }' to the page and
> still light blue is not visible on my screen (checked w/ #f0f that
> the above line actually has some effect)... #DFF for the light-blue
> works better for me.
>
> I think rounded corners are nice but IMHO the round radius is too big
> -- using 0.5mm for the radius would IMHO be better.

Forgot to mention that the <, >, &  etc. characters could also be encoded
in this patch series (to , ,  etc.)

>
> Tomi

Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, Tomi Ollila  wrote:

> On Tue, Feb 04 2014, "W. Trevor King"  wrote:
>
>
> $ PYTHONPATH=$PWD/bindings/python/ ./devel/nmbug/nmbug-status
> ...
> Traceback (most recent call last):
>   File "devel/nmbug/nmbug-status", line 318, in 
> page.write(database=db, views=config['views'])
>   File "devel/nmbug/nmbug-status", line 94, in write
> self._write_view(database=database, view=view, stream=stream)
>   File "devel/nmbug/nmbug-status", line 113, in _write_view
> self._write_threads(threads=threads, stream=stream)
>   File "devel/nmbug/nmbug-status", line 215, in _write_threads
> ).format(**message_display_data))
>   File "/usr/lib64/python2.6/codecs.py", line 351, in write
> data, consumed = self.encode(object, self.errors)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
> position 176: ordinal not in range(128)
>
>
> I'll dig deeper tomorrow.

PEBKAC. I (actually) used wrapper to run nmbug-status -- to run right
notmuch binary. While it mostly sets environment to be right it internally
uses LC_ALL=C for consistency -- and the wrapper forgot to restore
LC_ALL before running nmbug-status.

(that also confirms that the suggestion you made I used cron was somewhat
accurate ;)

After I fixed the wrapper the program works fine on python 2.6.6.

I have some comments on the new look -- which is pretty nice btw.

now every other thread is background-colored (girly) pink (fef?)
and every other light blue (eff). for me the light blue is not
visible (there are no body background color set?)

... hmm, i added 'body { background-color: #FFF; }' to the page and
still light blue is not visible on my screen (checked w/ #f0f that
the above line actually has some effect)... #DFF for the light-blue
works better for me.

I think rounded corners are nice but IMHO the round radius is too big
-- using 0.5mm for the radius would IMHO be better.

>
> Tomi

Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 05:24:56PM +0200, Tomi Ollila wrote:
> Forgot to mention that the <, >, & etc. characters could also be
> encoded in this patch series (to , ,  etc.)

Good point.  I'll xml.sax.saxutils.escape the message-id, from, and
subject at the end of HtmlPage._message_display_data, and squash that
into the Page / HtmlPage commit.

Thanks,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
> After I fixed the wrapper the program works fine on python 2.6.6.

:)

> now every other thread is background-colored (girly) pink (fef?)
> and every other light blue (eff). for me the light blue is not
> visible (there are no body background color set?)

#EFF is visible to me, but it is light.

> #DFF for the light-blue works better for me.

I'm fine with that.  As I said in my cover letter, I'm happy to have
alternative color schemes suggested.  Does anyone else want to chime
in on better defaults?  This should probably also be configurable via
status-config.json.  Maybe:

   { "style": {"html": {"thread-colors": ["#DFF", "#FEF"]}}}

?

> I think rounded corners are nice but IMHO the round radius is too
> big -- using 0.5mm for the radius would IMHO be better.

No problem.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, Tomi Ollila tomi.oll...@iki.fi wrote:

 On Tue, Feb 04 2014, W. Trevor King wk...@tremily.us wrote:


 $ PYTHONPATH=$PWD/bindings/python/ ./devel/nmbug/nmbug-status
 ...
 Traceback (most recent call last):
   File devel/nmbug/nmbug-status, line 318, in module
 page.write(database=db, views=config['views'])
   File devel/nmbug/nmbug-status, line 94, in write
 self._write_view(database=database, view=view, stream=stream)
   File devel/nmbug/nmbug-status, line 113, in _write_view
 self._write_threads(threads=threads, stream=stream)
   File devel/nmbug/nmbug-status, line 215, in _write_threads
 ).format(**message_display_data))
   File /usr/lib64/python2.6/codecs.py, line 351, in write
 data, consumed = self.encode(object, self.errors)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
 position 176: ordinal not in range(128)


 I'll dig deeper tomorrow.

PEBKAC. I (actually) used wrapper to run nmbug-status -- to run right
notmuch binary. While it mostly sets environment to be right it internally
uses LC_ALL=C for consistency -- and the wrapper forgot to restore
LC_ALL before running nmbug-status.

(that also confirms that the suggestion you made I used cron was somewhat
accurate ;)

After I fixed the wrapper the program works fine on python 2.6.6.

I have some comments on the new look -- which is pretty nice btw.

now every other thread is background-colored (girly) pink (fef?)
and every other light blue (eff). for me the light blue is not
visible (there are no body background color set?)

... hmm, i added 'body { background-color: #FFF; }' to the page and
still light blue is not visible on my screen (checked w/ #f0f that
the above line actually has some effect)... #DFF for the light-blue
works better for me.

I think rounded corners are nice but IMHO the round radius is too big
-- using 0.5mm for the radius would IMHO be better.


 Tomi

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Wed, Feb 05 2014, Tomi Ollila tomi.oll...@iki.fi wrote:

 I have some comments on the new look -- which is pretty nice btw.

 now every other thread is background-colored (girly) pink (fef?)
 and every other light blue (eff). for me the light blue is not
 visible (there are no body background color set?)

 ... hmm, i added 'body { background-color: #FFF; }' to the page and
 still light blue is not visible on my screen (checked w/ #f0f that
 the above line actually has some effect)... #DFF for the light-blue
 works better for me.

 I think rounded corners are nice but IMHO the round radius is too big
 -- using 0.5mm for the radius would IMHO be better.

Forgot to mention that the , ,   etc. characters could also be encoded
in this patch series (to lt;, gt;, amp; etc.)


 Tomi

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
 After I fixed the wrapper the program works fine on python 2.6.6.

:)

 now every other thread is background-colored (girly) pink (fef?)
 and every other light blue (eff). for me the light blue is not
 visible (there are no body background color set?)

#EFF is visible to me, but it is light.

 #DFF for the light-blue works better for me.

I'm fine with that.  As I said in my cover letter, I'm happy to have
alternative color schemes suggested.  Does anyone else want to chime
in on better defaults?  This should probably also be configurable via
status-config.json.  Maybe:

   { style: {html: {thread-colors: [#DFF, #FEF]}}}

?

 I think rounded corners are nice but IMHO the round radius is too
 big -- using 0.5mm for the radius would IMHO be better.

No problem.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Wed, Feb 05, 2014 at 05:24:56PM +0200, Tomi Ollila wrote:
 Forgot to mention that the , ,  etc. characters could also be
 encoded in this patch series (to lt;, gt;, amp; etc.)

Good point.  I'll xml.sax.saxutils.escape the message-id, from, and
subject at the end of HtmlPage._message_display_data, and squash that
into the Page / HtmlPage commit.

Thanks,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Wed, Feb 05 2014, W. Trevor King wk...@tremily.us wrote:

 On Wed, Feb 05, 2014 at 05:00:45PM +0200, Tomi Ollila wrote:
 After I fixed the wrapper the program works fine on python 2.6.6.

 :)

 now every other thread is background-colored (girly) pink (fef?)
 and every other light blue (eff). for me the light blue is not
 visible (there are no body background color set?)

 #EFF is visible to me, but it is light.

 #DFF for the light-blue works better for me.

 I'm fine with that.  As I said in my cover letter, I'm happy to have
 alternative color schemes suggested.  Does anyone else want to chime
 in on better defaults?  This should probably also be configurable via
 status-config.json.  Maybe:

{ style: {html: {thread-colors: [#DFF, #FEF]}}}

Maybe we can persuade David to test-run new notmuch-status in
his production server before it is pushed to notmuch master, and
bikeshed the style in http://nmbug.tethera.net/status/

 ?

probably no-one is interested to configure those later (if we even
get bikeshed comments... ;)

Tomi

 I think rounded corners are nice but IMHO the round radius is too
 big -- using 0.5mm for the radius would IMHO be better.

 No problem.

 Cheers,
 Trevor
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, "W. Trevor King"  wrote:

>> 
>> I don't know what to paste, so i paste this:
>> 
>> $ python
>> Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
>> [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>
> It looks like you left out:
>
>   from __future__ import unicode_literals
>
> Can you try again with that line as the first command?
>
>> >>> data = {'from': '\u017b'}
>> >>> print(type(data['from'])) 
>> 
>
> which is why your data is a 'str' and not a 'unicode' instance.
>
>> >>> string = '  {from}\n'.format(**data)
>> >>> print string
>>   \u017b

Quick update before getting to sleep:

$ python 
Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import print_function
>>> from __future__ import unicode_literals
>>> data = {'from': '\u017b'}
>>> print(type(data['from']))

>>> string = '  {from}\n'.format(**data)
>>> print(string)
  ?

so getting success there

$ PYTHONPATH=$PWD/bindings/python/ ./devel/nmbug/nmbug-status
...
Traceback (most recent call last):
  File "devel/nmbug/nmbug-status", line 318, in 
page.write(database=db, views=config['views'])
  File "devel/nmbug/nmbug-status", line 94, in write
self._write_view(database=database, view=view, stream=stream)
  File "devel/nmbug/nmbug-status", line 113, in _write_view
self._write_threads(threads=threads, stream=stream)
  File "devel/nmbug/nmbug-status", line 215, in _write_threads
).format(**message_display_data))
  File "/usr/lib64/python2.6/codecs.py", line 351, in write
data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 176: ordinal not in range(128)


I'll dig deeper tomorrow.


Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, "W. Trevor King"  wrote:

>
>   >>> from __future__ import unicode_literals
>   >>> import codecs
>   >>> import locale
>   >>> import sys
>   >>> print(locale.getpreferredencoding())  # same as yours
>   UTF-8
>   >>> print(sys.getdefaultencoding())  # same as yours
>   ascii
>   >>> _ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
>   >>> print(_ENCODING)  # double-check default encodings
>   UTF-8
>   >>> byte_stream = sys.stdout  # copied from Page.write
>   >>> stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
>   >>> data = {'from': '\u017b'}  # fake the troublesome data
>   >>> print(type(data['from']))  # double-check unicode_literals
>   
>   >>> string = '  {from}\n'.format(**data)
>   >>> stream.write(string)
> ?
>
> It looks like you'll have the same _ENCODING as I do (UTF-8).  That
> means your stream should be wrapped in a UTF-8 StreamWriter, so I
> don't understand why it's converting to ASCII.  Can you run through
> the above on your troublesome machine and confirm that stream.write()
> is still raising the exception?  If it doesn't work, can you just
> paste that whole run in your next email?

I don't know what to paste, so i paste this:

$ python
Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> data = {'from': '\u017b'}
>>> print(type(data['from'])) 

>>> string = '  {from}\n'.format(**data)
>>> print string
  \u017b

and then:

>>> data = {'from': u'\u017b'}
>>> print(type(data['from'])) 

>>> string = '  {from}\n'.format(**data)
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
>>> position 0: ordinal not in range(128)

... and ...

>>> import os
>>> print os.environ['LANG']
en_US.UTF-8


> Thanks,
> Trevor


Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, "W. Trevor King"  wrote:

> On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
>> On Tue, Feb 04 2014, W. Trevor King wrote:
>> > On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
>> >>   File "devel/nmbug/nmbug-status", line 197, in _write_threads
>> >> ).format(**message_display_data))
>> >>   File "/usr/lib64/python2.6/codecs.py", line 351, in write
>> >> data, consumed = self.encode(object, self.errors)
>> >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
>> >>   position 176: ordinal not in range(128)
>> > ?
>> 
>> LANG=en_US.UTF-8
>
> My current guess is that LANG is set in your terminal, but that you
> ran nmbug-status from a cron job where it wasn't set.  If that's the
> case, try adding:
>
>   export LANG=en_US.UTF-8
>
> to your cron job (or replace with whichever encoding you like).

Yes guess is good, but incorrect I run it on the command line.

Now I did the following:

$ git remote add tremily git://tremily.us/notmuch.git
$ git fetch --all
$ git checkout nmbug-status-python3

commit d64ef215b62fa74a96fdb4c93e1f6f7abf7c80c6

and then rerun nmbug-status -- and I am still having the same problem.
I will investigate this further...

> We don't care about the preferred language yet, but we could [1].
> There's actually not all that much that needs translating for
> nmbug-status.

Yes, that is unfortunate that David (Taavetti in Finnish) did an uneducated
choice by choosing english as the preferred language. It should always
have been written in Finnish so we would not have this conversation >;)

>
> Cheers,
> Trevor
>
> [1]: http://docs.python.org/3/library/gettext.html


Tomi

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 08:40:18PM +0200, Tomi Ollila wrote:
> On Tue, Feb 04 2014, W. Trevor King wrote:
> >
> >   >>> from __future__ import unicode_literals
> >   >>> import codecs
> >   >>> import locale
> >   >>> import sys
> >   >>> print(locale.getpreferredencoding())  # same as yours
> >   UTF-8
> >   >>> print(sys.getdefaultencoding())  # same as yours
> >   ascii
> >   >>> _ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
> >   >>> print(_ENCODING)  # double-check default encodings
> >   UTF-8
> >   >>> byte_stream = sys.stdout  # copied from Page.write
> >   >>> stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
> >   >>> data = {'from': '\u017b'}  # fake the troublesome data
> >   >>> print(type(data['from']))  # double-check unicode_literals
> >   
> >   >>> string = '  {from}\n'.format(**data)
> >   >>> stream.write(string)
> > ?
> >
> > It looks like you'll have the same _ENCODING as I do (UTF-8).  That
> > means your stream should be wrapped in a UTF-8 StreamWriter, so I
> > don't understand why it's converting to ASCII.  Can you run through
> > the above on your troublesome machine and confirm that stream.write()
> > is still raising the exception?  If it doesn't work, can you just
> > paste that whole run in your next email?
> 
> I don't know what to paste, so i paste this:
> 
> $ python
> Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
> [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.

It looks like you left out:

  from __future__ import unicode_literals

Can you try again with that line as the first command?

> >>> data = {'from': '\u017b'}
> >>> print(type(data['from'])) 
> 

which is why your data is a 'str' and not a 'unicode' instance.

> >>> string = '  {from}\n'.format(**data)
> >>> print string
>   \u017b
> 
> and then:
> 
> >>> data = {'from': u'\u017b'}

This works around the lack of unicode_literals with an explicit u''.

> >>> print(type(data['from'])) 
> 
> >>> string = '  {from}\n'.format(**data)
> Traceback (most recent call last):
>   File "", line 1, in 
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in

However, without unicode_literals or an explicit u'', you're format
string '?{from}' is a str (it should be a 'unicode' instance with
unicode_literals).

> >>> import os
> >>> print os.environ['LANG']
> en_US.UTF-8

That's good anyway ;).  Thanks for digging into this :).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
> On Tue, Feb 04 2014, W. Trevor King wrote:
> > On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
> >>   File "devel/nmbug/nmbug-status", line 197, in _write_threads
> >> ).format(**message_display_data))
> >>   File "/usr/lib64/python2.6/codecs.py", line 351, in write
> >> data, consumed = self.encode(object, self.errors)
> >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
> >>   position 176: ordinal not in range(128)
> > ?
> 
> LANG=en_US.UTF-8

My current guess is that LANG is set in your terminal, but that you
ran nmbug-status from a cron job where it wasn't set.  If that's the
case, try adding:

  export LANG=en_US.UTF-8

to your cron job (or replace with whichever encoding you like).

We don't care about the preferred language yet, but we could [1].
There's actually not all that much that needs translating for
nmbug-status.

Cheers,
Trevor

[1]: http://docs.python.org/3/library/gettext.html

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 07:50:32AM -0800, W. Trevor King wrote:
> That's two votes for Python 2.6 and none for later versions, so I'll
> just try a bit harder for 2.6 compatibility ;).

As a v2 preview, and to help with further review, I've posted my
current v1+ version of this branch at:

  git://tremily.us/notmuch.git nmbug-status-python3

Changes since v1:

* '{}' ? '{0}' for Python 2's str.format().
* Added an OrderedDict stub for Python 2.6 (and earlier, but they'll
  be missing json).

This v1+ works on my local box with Python 2.6.9.  I can push it as v2
now, but it's a long series and I don't want to spam the list just for
Python 2.6 fixups.  If folks want a v2 pushed to the list, just let me
know.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[David Bremner]

Tomi Ollila  writes:

> anyway, if this doesn't resolve out and there is no resistance to require
> python 2.7 (that means from David) I can hack around this to get this
> reviewed.

Currently the production copy of nmbug-status is running with python2.6
on Debian squeeze.  I _should_ upgrade that machine to wheezy, but I'm
not sure if there are any complications preventing that.

d

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
> On Tue, Feb 04 2014, "W. Trevor King" wrote:
> > On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
> >>   File "devel/nmbug/nmbug-status", line 197, in _write_threads
> >> ).format(**message_display_data))
> >>   File "/usr/lib64/python2.6/codecs.py", line 351, in write
> >> data, consumed = self.encode(object, self.errors)
> >> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
> >>   position 176: ordinal not in range(128)
> >
> > Hmm.  __future__'s unicode_literals should be giving us a Unicode
> > target, so I'm not sure why we'd have trouble injecting Unicode.  This
> > works fine for me on Python 2.7 and 3.3.  Maybe you just have a funky
> > encoding?  ?
> 
> LANG=en_US.UTF-8
> all other LC_* variables en_US.UTF-8 except
> LC_TIME=en_GB.utf8
> LC_ALL empty (naturally)
> 
> python -c 'import locale; print(locale.getpreferredencoding())'
> UTF-8
> python -c 'import sys; print(sys.getdefaultencoding())'
> ascii

That's very strange.  On Python 2.6.9, with the same encodings:

  >>> from __future__ import unicode_literals
  >>> import codecs
  >>> import locale
  >>> import sys
  >>> print(locale.getpreferredencoding())  # same as yours
  UTF-8
  >>> print(sys.getdefaultencoding())  # same as yours
  ascii
  >>> _ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
  >>> print(_ENCODING)  # double-check default encodings
  UTF-8
  >>> byte_stream = sys.stdout  # copied from Page.write
  >>> stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
  >>> data = {'from': '\u017b'}  # fake the troublesome data
  >>> print(type(data['from']))  # double-check unicode_literals
  
  >>> string = '  {from}\n'.format(**data)
  >>> stream.write(string)
?

It looks like you'll have the same _ENCODING as I do (UTF-8).  That
means your stream should be wrapped in a UTF-8 StreamWriter, so I
don't understand why it's converting to ASCII.  Can you run through
the above on your troublesome machine and confirm that stream.write()
is still raising the exception?  If it doesn't work, can you just
paste that whole run in your next email?

Thanks,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 09:07:45AM -0400, David Bremner wrote:
> Tomi Ollila writes:
> > anyway, if this doesn't resolve out and there is no resistance to require
> > python 2.7 (that means from David) I can hack around this to get this
> > reviewed.
>
> Currently the production copy of nmbug-status is running with python2.6
> on Debian squeeze.

That's two votes for Python 2.6 and none for later versions, so I'll
just try a bit harder for 2.6 compatibility ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, W. Trevor King wk...@tremily.us wrote:

 On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
 data['message-id-term'] = 'id:{}'.format(value)
 ValueError: zero length field name in format

 Oops, Python 2.6 still needs explicit indexes ('{0}', not '{}').  It's
 an easy fix, so I'll queue it for v2.  You're still going to need
 Python 2.7 or greater for collections.OrderedDict().  We could word
 around that too, but do we really care about 2.6?  I don't expect that
 the installed nmbug-status userbase is so large and backward that
 upgrading to 2.7 will be that hard ;).  2.6 isn't even getting
 security fixes anymore [1], so I think it's time to migrate :p.

Probably not many cares about 2.6; I already use argparse and I can add
that OrderedDict() too. Still {0} is easy enough to do :D. I am running
this notmuch  nmbug in Scientific Linux 6.2 machine which has python 2.6
-- and this is the only machine where I can review your nmbug-status
changes ;)

   File devel/nmbug/nmbug-status, line 197, in _write_threads
 ).format(**message_display_data))
   File /usr/lib64/python2.6/codecs.py, line 351, in write
 data, consumed = self.encode(object, self.errors)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
   position 176: ordinal not in range(128)

 Hmm.  __future__'s unicode_literals should be giving us a Unicode
 target, so I'm not sure why we'd have trouble injecting Unicode.  This
 works fine for me on Python 2.7 and 3.3.  Maybe you just have a funky
 encoding?  What is your:

   $ locale
   LANG=en_US.UTF-8
   …
   $ python -c 'import locale, sys; print(locale.getpreferredencoding() or 
 sys.getdefaultencoding())'
   UTF-8

LANG=en_US.UTF-8
all other LC_* variables en_US.UTF-8 except
LC_TIME=en_GB.utf8
LC_ALL empty (naturally)

python -c 'import locale; print(locale.getpreferredencoding())'
UTF-8
python -c 'import sys; print(sys.getdefaultencoding())'
ascii


anyway, if this doesn't resolve out and there is no resistance to require
python 2.7 (that means from David) I can hack around this to get this
reviewed.


 Cheers,
 Trevor

Tomi


 [1]: http://www.python.org/download/releases/2.6.9/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[David Bremner]

Tomi Ollila tomi.oll...@iki.fi writes:

 anyway, if this doesn't resolve out and there is no resistance to require
 python 2.7 (that means from David) I can hack around this to get this
 reviewed.

Currently the production copy of nmbug-status is running with python2.6
on Debian squeeze.  I _should_ upgrade that machine to wheezy, but I'm
not sure if there are any complications preventing that.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 09:07:45AM -0400, David Bremner wrote:
 Tomi Ollila writes:
  anyway, if this doesn't resolve out and there is no resistance to require
  python 2.7 (that means from David) I can hack around this to get this
  reviewed.

 Currently the production copy of nmbug-status is running with python2.6
 on Debian squeeze.

That's two votes for Python 2.6 and none for later versions, so I'll
just try a bit harder for 2.6 compatibility ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
 On Tue, Feb 04 2014, W. Trevor King wrote:
  On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
File devel/nmbug/nmbug-status, line 197, in _write_threads
  ).format(**message_display_data))
File /usr/lib64/python2.6/codecs.py, line 351, in write
  data, consumed = self.encode(object, self.errors)
  UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 176: ordinal not in range(128)
 
  Hmm.  __future__'s unicode_literals should be giving us a Unicode
  target, so I'm not sure why we'd have trouble injecting Unicode.  This
  works fine for me on Python 2.7 and 3.3.  Maybe you just have a funky
  encoding?  …
 
 LANG=en_US.UTF-8
 all other LC_* variables en_US.UTF-8 except
 LC_TIME=en_GB.utf8
 LC_ALL empty (naturally)
 
 python -c 'import locale; print(locale.getpreferredencoding())'
 UTF-8
 python -c 'import sys; print(sys.getdefaultencoding())'
 ascii

That's very strange.  On Python 2.6.9, with the same encodings:

   from __future__ import unicode_literals
   import codecs
   import locale
   import sys
   print(locale.getpreferredencoding())  # same as yours
  UTF-8
   print(sys.getdefaultencoding())  # same as yours
  ascii
   _ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
   print(_ENCODING)  # double-check default encodings
  UTF-8
   byte_stream = sys.stdout  # copied from Page.write
   stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
   data = {'from': '\u017b'}  # fake the troublesome data
   print(type(data['from']))  # double-check unicode_literals
  type 'unicode'
   string = '  td{from}/td\n'.format(**data)
   stream.write(string)
tdŻ/td

It looks like you'll have the same _ENCODING as I do (UTF-8).  That
means your stream should be wrapped in a UTF-8 StreamWriter, so I
don't understand why it's converting to ASCII.  Can you run through
the above on your troublesome machine and confirm that stream.write()
is still raising the exception?  If it doesn't work, can you just
paste that whole run in your next email?

Thanks,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 07:50:32AM -0800, W. Trevor King wrote:
 That's two votes for Python 2.6 and none for later versions, so I'll
 just try a bit harder for 2.6 compatibility ;).

As a v2 preview, and to help with further review, I've posted my
current v1+ version of this branch at:

  git://tremily.us/notmuch.git nmbug-status-python3

Changes since v1:

* '{}' → '{0}' for Python 2's str.format().
* Added an OrderedDict stub for Python 2.6 (and earlier, but they'll
  be missing json).

This v1+ works on my local box with Python 2.6.9.  I can push it as v2
now, but it's a long series and I don't want to spam the list just for
Python 2.6 fixups.  If folks want a v2 pushed to the list, just let me
know.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
 On Tue, Feb 04 2014, W. Trevor King wrote:
  On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
File devel/nmbug/nmbug-status, line 197, in _write_threads
  ).format(**message_display_data))
File /usr/lib64/python2.6/codecs.py, line 351, in write
  data, consumed = self.encode(object, self.errors)
  UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 176: ordinal not in range(128)
  …
 
 LANG=en_US.UTF-8

My current guess is that LANG is set in your terminal, but that you
ran nmbug-status from a cron job where it wasn't set.  If that's the
case, try adding:

  export LANG=en_US.UTF-8

to your cron job (or replace with whichever encoding you like).

We don't care about the preferred language yet, but we could [1].
There's actually not all that much that needs translating for
nmbug-status.

Cheers,
Trevor

[1]: http://docs.python.org/3/library/gettext.html

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, W. Trevor King wk...@tremily.us wrote:

 On Tue, Feb 04, 2014 at 12:30:30PM +0200, Tomi Ollila wrote:
 On Tue, Feb 04 2014, W. Trevor King wrote:
  On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
File devel/nmbug/nmbug-status, line 197, in _write_threads
  ).format(**message_display_data))
File /usr/lib64/python2.6/codecs.py, line 351, in write
  data, consumed = self.encode(object, self.errors)
  UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 176: ordinal not in range(128)
  …
 
 LANG=en_US.UTF-8

 My current guess is that LANG is set in your terminal, but that you
 ran nmbug-status from a cron job where it wasn't set.  If that's the
 case, try adding:

   export LANG=en_US.UTF-8

 to your cron job (or replace with whichever encoding you like).

Yes guess is good, but incorrect I run it on the command line.

Now I did the following:

$ git remote add tremily git://tremily.us/notmuch.git
$ git fetch --all
$ git checkout nmbug-status-python3

commit d64ef215b62fa74a96fdb4c93e1f6f7abf7c80c6

and then rerun nmbug-status -- and I am still having the same problem.
I will investigate this further...

 We don't care about the preferred language yet, but we could [1].
 There's actually not all that much that needs translating for
 nmbug-status.

Yes, that is unfortunate that David (Taavetti in Finnish) did an uneducated
choice by choosing english as the preferred language. It should always
have been written in Finnish so we would not have this conversation ;)


 Cheers,
 Trevor

 [1]: http://docs.python.org/3/library/gettext.html


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, W. Trevor King wk...@tremily.us wrote:


from __future__ import unicode_literals
import codecs
import locale
import sys
print(locale.getpreferredencoding())  # same as yours
   UTF-8
print(sys.getdefaultencoding())  # same as yours
   ascii
_ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
print(_ENCODING)  # double-check default encodings
   UTF-8
byte_stream = sys.stdout  # copied from Page.write
stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
data = {'from': '\u017b'}  # fake the troublesome data
print(type(data['from']))  # double-check unicode_literals
   type 'unicode'
string = '  td{from}/td\n'.format(**data)
stream.write(string)
 tdŻ/td

 It looks like you'll have the same _ENCODING as I do (UTF-8).  That
 means your stream should be wrapped in a UTF-8 StreamWriter, so I
 don't understand why it's converting to ASCII.  Can you run through
 the above on your troublesome machine and confirm that stream.write()
 is still raising the exception?  If it doesn't work, can you just
 paste that whole run in your next email?

I don't know what to paste, so i paste this:

$ python
Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type help, copyright, credits or license for more information.
 data = {'from': '\u017b'}
 print(type(data['from'])) 
type 'str'
 string = '  td{from}/td\n'.format(**data)
 print string
  td\u017b/td

and then:

 data = {'from': u'\u017b'}
 print(type(data['from'])) 
type 'unicode'
 string = '  td{from}/td\n'.format(**data)
Traceback (most recent call last):
  File stdin, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
 position 0: ordinal not in range(128)

... and ...

 import os
 print os.environ['LANG']
en_US.UTF-8


 Thanks,
 Trevor


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Tue, Feb 04, 2014 at 08:40:18PM +0200, Tomi Ollila wrote:
 On Tue, Feb 04 2014, W. Trevor King wrote:
 
 from __future__ import unicode_literals
 import codecs
 import locale
 import sys
 print(locale.getpreferredencoding())  # same as yours
UTF-8
 print(sys.getdefaultencoding())  # same as yours
ascii
 _ENCODING = locale.getpreferredencoding() or sys.getdefaultencoding()
 print(_ENCODING)  # double-check default encodings
UTF-8
 byte_stream = sys.stdout  # copied from Page.write
 stream = codecs.getwriter(encoding=_ENCODING)(stream=byte_stream)
 data = {'from': '\u017b'}  # fake the troublesome data
 print(type(data['from']))  # double-check unicode_literals
type 'unicode'
 string = '  td{from}/td\n'.format(**data)
 stream.write(string)
  tdŻ/td
 
  It looks like you'll have the same _ENCODING as I do (UTF-8).  That
  means your stream should be wrapped in a UTF-8 StreamWriter, so I
  don't understand why it's converting to ASCII.  Can you run through
  the above on your troublesome machine and confirm that stream.write()
  is still raising the exception?  If it doesn't work, can you just
  paste that whole run in your next email?
 
 I don't know what to paste, so i paste this:
 
 $ python
 Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
 [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
 Type help, copyright, credits or license for more information.

It looks like you left out:

  from __future__ import unicode_literals

Can you try again with that line as the first command?

  data = {'from': '\u017b'}
  print(type(data['from'])) 
 type 'str'

which is why your data is a 'str' and not a 'unicode' instance.

  string = '  td{from}/td\n'.format(**data)
  print string
   td\u017b/td
 
 and then:
 
  data = {'from': u'\u017b'}

This works around the lack of unicode_literals with an explicit u''.

  print(type(data['from'])) 
 type 'unicode'
  string = '  td{from}/td\n'.format(**data)
 Traceback (most recent call last):
   File stdin, line 1, in module
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in

However, without unicode_literals or an explicit u'', you're format
string '…{from}' is a str (it should be a 'unicode' instance with
unicode_literals).

  import os
  print os.environ['LANG']
 en_US.UTF-8

That's good anyway ;).  Thanks for digging into this :).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Tue, Feb 04 2014, W. Trevor King wk...@tremily.us wrote:

 
 I don't know what to paste, so i paste this:
 
 $ python
 Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
 [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
 Type help, copyright, credits or license for more information.

 It looks like you left out:

   from __future__ import unicode_literals

 Can you try again with that line as the first command?

  data = {'from': '\u017b'}
  print(type(data['from'])) 
 type 'str'

 which is why your data is a 'str' and not a 'unicode' instance.

  string = '  td{from}/td\n'.format(**data)
  print string
   td\u017b/td

Quick update before getting to sleep:

$ python 
Python 2.6.6 (r266:84292, Nov 21 2013, 12:39:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type help, copyright, credits or license for more information.
 from __future__ import print_function
 from __future__ import unicode_literals
 data = {'from': '\u017b'}
 print(type(data['from']))
type 'unicode'
 string = '  td{from}/td\n'.format(**data)
 print(string)
  tdŻ/td

so getting success there

$ PYTHONPATH=$PWD/bindings/python/ ./devel/nmbug/nmbug-status
...
Traceback (most recent call last):
  File devel/nmbug/nmbug-status, line 318, in module
page.write(database=db, views=config['views'])
  File devel/nmbug/nmbug-status, line 94, in write
self._write_view(database=database, view=view, stream=stream)
  File devel/nmbug/nmbug-status, line 113, in _write_view
self._write_threads(threads=threads, stream=stream)
  File devel/nmbug/nmbug-status, line 215, in _write_threads
).format(**message_display_data))
  File /usr/lib64/python2.6/codecs.py, line 351, in write
data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
position 176: ordinal not in range(128)


I'll dig deeper tomorrow.


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Mon, Feb 03 2014, "W. Trevor King"  wrote:

> I noticed that nmbug-status was written in Python :), but not
> compatible with Python 3 :(.  I started cleaning up a few print
> statements, but this quickly turned into a more general refactoring.
> Let me know if this is too much to bite off at once.  I tried to keep
> each patch fairly contained, but the Page / HtmlPage addition is still
> pretty big.  Despite increasing the size of this module by almost 50%,
> I think my final version is more readable.  However, it's always
> easier to read your own code, so feel free to tell me that this is a
> step in the completely wrong direction ;).
>
> Also anyone with asthetic sensibilities is free to pick nicer colors
> in the final patch.  I'm too partial to the EFF permutation symmetry
> to be able to pick other colors myself ;).

Nice series. One problem with python 2.6 though:

Traceback (most recent call last):
  File "devel/nmbug/nmbug-status", line 300, in 
page.write(database=db, views=config['views'])
  File "devel/nmbug/nmbug-status", line 76, in write
self._write_view(database=database, view=view, stream=stream)
  File "devel/nmbug/nmbug-status", line 93, in _write_view
threads = self._get_threads(messages=q.search_messages())
  File "devel/nmbug/nmbug-status", line 107, in _get_threads
running_data=thread.running_data, message=message)
  File "devel/nmbug/nmbug-status", line 207, in _message_display_data
*args, **kwargs)
  File "devel/nmbug/nmbug-status", line 132, in _message_display_data
data['message-id-term'] = 'id:"{}"'.format(value)
ValueError: zero length field name in format

Using python 2.6.6

$ python -c 'print "{}".format("foo")'
Traceback (most recent call last):
  File "", line 1, in 
ValueError: zero length field name in format
zsh: exit 1 python -c '"{}".format("foo")'

python -c 'print "{0}".format("foo")'
foo

With python 2.7.x python -c 'print "{}".format("foo")' works OK.

Argh, when I changed that one, next:

Traceback (most recent call last):
  File "devel/nmbug/nmbug-status", line 300, in 
page.write(database=db, views=config['views'])
  File "devel/nmbug/nmbug-status", line 76, in write
self._write_view(database=database, view=view, stream=stream)
  File "devel/nmbug/nmbug-status", line 95, in _write_view
self._write_threads(threads=threads, stream=stream)
  File "devel/nmbug/nmbug-status", line 197, in _write_threads
).format(**message_display_data))
  File "/usr/lib64/python2.6/codecs.py", line 351, in write
data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
  position 176: ordinal not in range(128)

This one is harder...

Tomi


>
> W. Trevor King (17):
>   nmbug-status: Convert to Python-3-compatible print functions
>   nmbug-status: Use email.utils instead of rfc822
>   nmbug-status: Decode Popen output using the user's locale
>   nmbug-status: Factor config-loading out into read_config
>   nmbug-status: Add metavars for --config and --get-query
>   nmbug-status: Consolidate functions and main code
>   nmbug-status: Don't require write access
>   nmbug-status: Consolidate HTML header printing
>   nmbug-status: Add a Python-3-compatible urllib.parse.quote import
>   nmbug-status: Add Page and HtmlPage for modular rendering
>   nmbug-status: Normalize table HTML indentation
>   nmbug-status: Convert from XHTML 1.0 to HTML 5
>   nmbug-status: Encode output using the user's locale
>   nmbug-status: Anchor with h3 ids instead of a names
>   nmbug-status: Quote the title when using it as an id
>   nmbug-status: Use  and  markup where appropriate
>   nmbug-status: Color threads in HTML output
>
>  devel/nmbug/nmbug-status | 412 
> ++-
>  1 file changed, 261 insertions(+), 151 deletions(-)
>
> -- 
> 1.8.5.2.8.g0f6c0d1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
> data['message-id-term'] = 'id:"{}"'.format(value)
> ValueError: zero length field name in format

Oops, Python 2.6 still needs explicit indexes ('{0}', not '{}').  It's
an easy fix, so I'll queue it for v2.  You're still going to need
Python 2.7 or greater for collections.OrderedDict().  We could word
around that too, but do we really care about 2.6?  I don't expect that
the installed nmbug-status userbase is so large and backward that
upgrading to 2.7 will be that hard ;).  2.6 isn't even getting
security fixes anymore [1], so I think it's time to migrate :p.

>   File "devel/nmbug/nmbug-status", line 197, in _write_threads
> ).format(**message_display_data))
>   File "/usr/lib64/python2.6/codecs.py", line 351, in write
> data, consumed = self.encode(object, self.errors)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
>   position 176: ordinal not in range(128)

Hmm.  __future__'s unicode_literals should be giving us a Unicode
target, so I'm not sure why we'd have trouble injecting Unicode.  This
works fine for me on Python 2.7 and 3.3.  Maybe you just have a funky
encoding?  What is your:

  $ locale
  LANG=en_US.UTF-8
  ?
  $ python -c 'import locale, sys; print(locale.getpreferredencoding() or 
sys.getdefaultencoding())'
  UTF-8

Cheers,
Trevor

[1]: http://www.python.org/download/releases/2.6.9/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

I noticed that nmbug-status was written in Python :), but not
compatible with Python 3 :(.  I started cleaning up a few print
statements, but this quickly turned into a more general refactoring.
Let me know if this is too much to bite off at once.  I tried to keep
each patch fairly contained, but the Page / HtmlPage addition is still
pretty big.  Despite increasing the size of this module by almost 50%,
I think my final version is more readable.  However, it's always
easier to read your own code, so feel free to tell me that this is a
step in the completely wrong direction ;).

Also anyone with asthetic sensibilities is free to pick nicer colors
in the final patch.  I'm too partial to the EFF permutation symmetry
to be able to pick other colors myself ;).

W. Trevor King (17):
  nmbug-status: Convert to Python-3-compatible print functions
  nmbug-status: Use email.utils instead of rfc822
  nmbug-status: Decode Popen output using the user's locale
  nmbug-status: Factor config-loading out into read_config
  nmbug-status: Add metavars for --config and --get-query
  nmbug-status: Consolidate functions and main code
  nmbug-status: Don't require write access
  nmbug-status: Consolidate HTML header printing
  nmbug-status: Add a Python-3-compatible urllib.parse.quote import
  nmbug-status: Add Page and HtmlPage for modular rendering
  nmbug-status: Normalize table HTML indentation
  nmbug-status: Convert from XHTML 1.0 to HTML 5
  nmbug-status: Encode output using the user's locale
  nmbug-status: Anchor with h3 ids instead of a names
  nmbug-status: Quote the title when using it as an id
  nmbug-status: Use  and  markup where appropriate
  nmbug-status: Color threads in HTML output

 devel/nmbug/nmbug-status | 412 ++-
 1 file changed, 261 insertions(+), 151 deletions(-)

-- 
1.8.5.2.8.g0f6c0d1

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

I noticed that nmbug-status was written in Python :), but not
compatible with Python 3 :(.  I started cleaning up a few print
statements, but this quickly turned into a more general refactoring.
Let me know if this is too much to bite off at once.  I tried to keep
each patch fairly contained, but the Page / HtmlPage addition is still
pretty big.  Despite increasing the size of this module by almost 50%,
I think my final version is more readable.  However, it's always
easier to read your own code, so feel free to tell me that this is a
step in the completely wrong direction ;).

Also anyone with asthetic sensibilities is free to pick nicer colors
in the final patch.  I'm too partial to the EFF permutation symmetry
to be able to pick other colors myself ;).

W. Trevor King (17):
  nmbug-status: Convert to Python-3-compatible print functions
  nmbug-status: Use email.utils instead of rfc822
  nmbug-status: Decode Popen output using the user's locale
  nmbug-status: Factor config-loading out into read_config
  nmbug-status: Add metavars for --config and --get-query
  nmbug-status: Consolidate functions and main code
  nmbug-status: Don't require write access
  nmbug-status: Consolidate HTML header printing
  nmbug-status: Add a Python-3-compatible urllib.parse.quote import
  nmbug-status: Add Page and HtmlPage for modular rendering
  nmbug-status: Normalize table HTML indentation
  nmbug-status: Convert from XHTML 1.0 to HTML 5
  nmbug-status: Encode output using the user's locale
  nmbug-status: Anchor with h3 ids instead of a names
  nmbug-status: Quote the title when using it as an id
  nmbug-status: Use code and p markup where appropriate
  nmbug-status: Color threads in HTML output

 devel/nmbug/nmbug-status | 412 ++-
 1 file changed, 261 insertions(+), 151 deletions(-)

-- 
1.8.5.2.8.g0f6c0d1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Mon, Feb 03 2014, W. Trevor King wk...@tremily.us wrote:

 I noticed that nmbug-status was written in Python :), but not
 compatible with Python 3 :(.  I started cleaning up a few print
 statements, but this quickly turned into a more general refactoring.
 Let me know if this is too much to bite off at once.  I tried to keep
 each patch fairly contained, but the Page / HtmlPage addition is still
 pretty big.  Despite increasing the size of this module by almost 50%,
 I think my final version is more readable.  However, it's always
 easier to read your own code, so feel free to tell me that this is a
 step in the completely wrong direction ;).

 Also anyone with asthetic sensibilities is free to pick nicer colors
 in the final patch.  I'm too partial to the EFF permutation symmetry
 to be able to pick other colors myself ;).

Nice series. One problem with python 2.6 though:

Traceback (most recent call last):
  File devel/nmbug/nmbug-status, line 300, in module
page.write(database=db, views=config['views'])
  File devel/nmbug/nmbug-status, line 76, in write
self._write_view(database=database, view=view, stream=stream)
  File devel/nmbug/nmbug-status, line 93, in _write_view
threads = self._get_threads(messages=q.search_messages())
  File devel/nmbug/nmbug-status, line 107, in _get_threads
running_data=thread.running_data, message=message)
  File devel/nmbug/nmbug-status, line 207, in _message_display_data
*args, **kwargs)
  File devel/nmbug/nmbug-status, line 132, in _message_display_data
data['message-id-term'] = 'id:{}'.format(value)
ValueError: zero length field name in format

Using python 2.6.6

$ python -c 'print {}.format(foo)'
Traceback (most recent call last):
  File string, line 1, in module
ValueError: zero length field name in format
zsh: exit 1 python -c '{}.format(foo)'

python -c 'print {0}.format(foo)'
foo

With python 2.7.x python -c 'print {}.format(foo)' works OK.

Argh, when I changed that one, next:

Traceback (most recent call last):
  File devel/nmbug/nmbug-status, line 300, in module
page.write(database=db, views=config['views'])
  File devel/nmbug/nmbug-status, line 76, in write
self._write_view(database=database, view=view, stream=stream)
  File devel/nmbug/nmbug-status, line 95, in _write_view
self._write_threads(threads=threads, stream=stream)
  File devel/nmbug/nmbug-status, line 197, in _write_threads
).format(**message_display_data))
  File /usr/lib64/python2.6/codecs.py, line 351, in write
data, consumed = self.encode(object, self.errors)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
  position 176: ordinal not in range(128)

This one is harder...

Tomi



 W. Trevor King (17):
   nmbug-status: Convert to Python-3-compatible print functions
   nmbug-status: Use email.utils instead of rfc822
   nmbug-status: Decode Popen output using the user's locale
   nmbug-status: Factor config-loading out into read_config
   nmbug-status: Add metavars for --config and --get-query
   nmbug-status: Consolidate functions and main code
   nmbug-status: Don't require write access
   nmbug-status: Consolidate HTML header printing
   nmbug-status: Add a Python-3-compatible urllib.parse.quote import
   nmbug-status: Add Page and HtmlPage for modular rendering
   nmbug-status: Normalize table HTML indentation
   nmbug-status: Convert from XHTML 1.0 to HTML 5
   nmbug-status: Encode output using the user's locale
   nmbug-status: Anchor with h3 ids instead of a names
   nmbug-status: Quote the title when using it as an id
   nmbug-status: Use code and p markup where appropriate
   nmbug-status: Color threads in HTML output

  devel/nmbug/nmbug-status | 412 
 ++-
  1 file changed, 261 insertions(+), 151 deletions(-)

 -- 
 1.8.5.2.8.g0f6c0d1

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Mon, Feb 03, 2014 at 11:10:23PM +0200, Tomi Ollila wrote:
 data['message-id-term'] = 'id:{}'.format(value)
 ValueError: zero length field name in format

Oops, Python 2.6 still needs explicit indexes ('{0}', not '{}').  It's
an easy fix, so I'll queue it for v2.  You're still going to need
Python 2.7 or greater for collections.OrderedDict().  We could word
around that too, but do we really care about 2.6?  I don't expect that
the installed nmbug-status userbase is so large and backward that
upgrading to 2.7 will be that hard ;).  2.6 isn't even getting
security fixes anymore [1], so I think it's time to migrate :p.

   File devel/nmbug/nmbug-status, line 197, in _write_threads
 ).format(**message_display_data))
   File /usr/lib64/python2.6/codecs.py, line 351, in write
 data, consumed = self.encode(object, self.errors)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
   position 176: ordinal not in range(128)

Hmm.  __future__'s unicode_literals should be giving us a Unicode
target, so I'm not sure why we'd have trouble injecting Unicode.  This
works fine for me on Python 2.7 and 3.3.  Maybe you just have a funky
encoding?  What is your:

  $ locale
  LANG=en_US.UTF-8
  …
  $ python -c 'import locale, sys; print(locale.getpreferredencoding() or 
sys.getdefaultencoding())'
  UTF-8

Cheers,
Trevor

[1]: http://www.python.org/download/releases/2.6.9/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch