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

agenda --tsv: handle fields with multiple elements #829

Open
michaelmhoffman opened this issue Jan 31, 2025 · 0 comments
Open

agenda --tsv: handle fields with multiple elements #829

michaelmhoffman opened this issue Jan 31, 2025 · 0 comments

Comments

@michaelmhoffman
Copy link
Collaborator

michaelmhoffman commented Jan 31, 2025

The Google Calendar API Event properties conferenceData.entryPoints[], attachments[], reminders.overrides[], and attendees[] properties are all lists.

Currently, only --details conference is supported by agenda --tsv. The current implementation prints only the first list element, which has never been an issue for me. But it will not work well for the other properties, and I'd like to see attachments implemented.

How to expose these fields with multiple elements? Given that escaping of newlines (especially) and tabs in event properties is required for the TSV format to work here, perhaps we can use the ASCII form feed character '\f' to provide item separation within a field. If, by some astonishing situation, it is actually in the text, we can escape it as r'\f'.

Some backslash-escaping format is going to be most convenient here. Introducing another form of escaping is going to require multiple ways of unescaping.

Other options:

  • r'\t': Tab is a less exciting character, but nesting tabs and the two-character string r'\t's is a bit confusing. This was my original idea, but it was even awkward to describe it in the issue.
  • r'\n': I don't like this because newlines are more likely to actually occur in the text than a tab, so double-escaping is going to be necessary.
  • '\0' or r'\0': I don't like this because a null character may break some of the downstream programs one might want to use to process the output
  • other, more esoteric code points like ASCII field separator: seem like extra complexity and weirdness for little gain
  • adding quoting of elements: a whole extra ball of complexity I'd like to avoid

I'm open to other suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant