UnicodeEncodeError: 'charmap' codec on Windows in some scenarios

[Nitemice]

Similar to #335, but some of the conditions & error are different.

Steps to reproduce:

1. Add an event to a default calendar called Birthday Extravaganza!! 🎈🎈 at 9 p.m.
2. gcalcli --nocolor agenda 12am 11:59pm

Sun Oct 14 9:00pm Birthday Extravaganza!! 🎈🎈

3. gcalcli agenda 9pm 11pm | findstr Birth*

Traceback (most recent call last):
  File "C:\Python37\Scripts\gcalcli-script.py", line 11, in <module>
    load_entry_point('gcalcli==4.0.0a5', 'console_scripts', 'gcalcli')()
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\gcalcli.py", line 1614, in main
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\gcalcli.py", line 1170, in AgendaQuery
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\gcalcli.py", line 1154, in _display_queried_events
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\gcalcli.py", line 1036, in _iterate_events
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\gcalcli.py", line 732, in _PrintEvent
  File "C:\Python37\lib\site-packages\gcalcli-4.0.0a5-py3.7.egg\gcalcli\printer.py", line 91, in msg
  File "C:\Python37\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 35-36: character maps to <undefined>

gcalcli-4.0.0a5, Python 3.7.0, Microsoft Windows 10 (1803), using cmd, or powershell

The workaround mentioned in #335 (setting PYTHONIOENCODING=utf8) works here too, but I thought it was worth reporting anyway, as I'm running Py3.

[jcrowgey]

I don't know anything about Windows. 'charmap' is not a codec I've ever heard of. I remember cmd from when I was little. I don't know what a powershell is. That said, I don't keep up with the latest minutia of python minor version release changes. I'm slowly migrating to 3.6 from 3.5, maybe this charmap thing is a 3.7 concept that I just haven't encountered yet.

I'm inclined to close this as wontfix unless:

1. someone can repro this on a supported platform
2. someone can show how this isn't window's specific
3. or other maintainers have some interest in supporting Windows.

Anyone interested?

[yulqen]

"charmap" is not a 3.7 thing. charmap_encode() is undocumented but seems to be used for handling encodings such as Windows' cp1252 - see characters it handles at https://github.com/python/cpython/blob/master/Lib/encodings/cp1252.py. 🎈 - (U+1F388) cannot be encoded here hence the need for UTF-8. Don't know enough about Python character encoding to be able elegantly handle pipes/Powershell, etc. Windows!

[dbarnett]

https://stackoverflow.com/a/4637795/307705 suggests this may only be an issue on older pre-3.6 python versions we don't support, and there's some other good context on it on that question and related https://stackoverflow.com/questions/14630288/unicodeencodeerror-charmap-codec-cant-encode-character-maps-to-undefined.

In general I think it's reasonable to expect that whatever's going on with encodings, gcalcli will do its best to show you what output it can instead of completely blowing up, at least for the basic functionality.

[dbarnett]

Duping to #375

[dbarnett]

Oh hey, turns out it's easy to repro an error like this just running the tests in GH Actions on windows-latest platform (https://github.com/insanum/gcalcli/actions/runs/10533711279/job/29190148575):

[dbarnett]

(I'll rename and keep this one as the canonical dupe for the Windows 'charmap' ones.)

[dbarnett]

Hmm, this may be an upstream bug in the vobject dep, or possibly in our argparse setup code.

There's not really any gcalcli code explicitly fiddling with encodings here, just two bits of code where we...

1. configure argparse to handle the file argument:

   gcalcli/gcalcli/argparsers.py

   Line 398 in 1000154

   'file', type=argparse.FileType('r'), nargs='?', default=None)

   , and
2. call vobject.readComponents on it:

   gcalcli/gcalcli/gcal.py

   Line 1576 in 1000154

   v = next(vobject.readComponents(f))

it's possible there's something screwy with the default encoding option on Windows, or that

See docs for argparse.FileType, which point to the docs for stdlib open() for details on the encoding arg.

[dbarnett]

Hey, I might have fixed this!

Please reach out if you still notice severe encoding issues in the new version.