Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync'ing color should not sync trailing newline #358

Closed
WhyNotHugo opened this issue Mar 4, 2016 · 3 comments
Closed

Sync'ing color should not sync trailing newline #358

WhyNotHugo opened this issue Mar 4, 2016 · 3 comments

Comments

@WhyNotHugo
Copy link
Member

@WhyNotHugo WhyNotHugo commented Mar 4, 2016

I've my calendars configured with a /color file with a hex colour (eg: #c0c0c0). Since I edit these files with vim, they end up with a trailing newline. I doubt I'm the only person for whom this happens too.

When I sync to my CalDAV server, sync works fine, but other clients that sync to it (a web client, a mobile client) fail to parse this value, and use a fallback colour.

I've reported the issue to those other clients (since they can't be that strict in what the accept!), but I still think vdirsyncer should trim the trailing newline when uploading the colour.

@untitaker
Copy link
Member

@untitaker untitaker commented Mar 4, 2016

I don't think it's the other client's consumer's responsibility to accept such values.

Loading

@WhyNotHugo
Copy link
Member Author

@WhyNotHugo WhyNotHugo commented Mar 5, 2016

FWIW, Fastmail fixed their consumer support too. :)

Loading

@untitaker
Copy link
Member

@untitaker untitaker commented Mar 5, 2016

I'm reopening this, the fix is terrible. get_meta should already return the normalized value, at least it should be this way in python-vdir.

Loading

@untitaker untitaker reopened this Mar 5, 2016
untitaker added a commit that referenced this issue Mar 5, 2016
This fixes #358 again, in a different way.
@untitaker untitaker self-assigned this Mar 5, 2016
untitaker added a commit that referenced this issue Mar 5, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
untitaker added a commit that referenced this issue Mar 6, 2016
This fixes #358 again, in a different way.
@untitaker untitaker removed their assignment Mar 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants