Feature Request: import location from icalendar file

[jebaum]

when using the --import option, it would be nice if location info from the ics file (if it's there) could be appended to the event description. without this I still have to go back into my outlook calendar to check where I'm going for appointments, but with that info in calcurse I'd never have to look at outlook again.

is this possible?

edit: just realized that this doesn't seem to be the main place to report bugs or request features so I'll send this to the mailing list as well

[luukvbaal]

Any plans for this? Would to be able to import the location of my lectures.

[Sponge5]

I would very much appreciate this feature. Should I subscribe to the mailing list and ask there or has @luukvbaal asked already? Is anyone working on this?

[lfos]

I don't think so. No need to report on the ML if already reported here. Writing a patch and filing a FR would be appreciated, though!

[Sponge5]

I cloned the repo and will play a bit with it, don't expect anything just yet though, I've never contributed code to FOSS before.

[jchook]

I started looking into implementing this missing feature...

Adding the location field seems to churn the spaghetti a bit, but I thought we might get away with appending info like the location to the note.

[lfos]

Adding it to the note sounds fine. It might even make sense to add more generic support for additional headers to the note format. Suggestion:

This is a note.
-- 
Location: 200 University Ave W, Waterloo, ON N2L 3G1

Everythin following the separator -- ("dash-dash-space-return") is a header.

[lhca]

This is a note.
-- 
Location: 200 University Ave W, Waterloo, ON N2L 3G1

Everythin following the separator -- ("dash-dash-space-return") is a header.

There are some tacit assumptions, so I will elaborate a little ("header" is called property in RFC 5545 parlance).

This is a note (containing text from DESCRIPTION).
-- 
Location: 200 University Ave W, Waterloo, ON N2L 3G1 (a single line from LOCATION)
Comment: Anything else (text from COMMENT)
Status: CONFIRMED (text from STATUS)

Only properties of value type TEXT are taken into account.

This is fine, and there is no doubt that it can be implemented. But there are several complications.

• the properties are optional
• for several of the properties the text may contain several lines
• the properties can be encountered in any order in the VEVENT

At present, calcurse creates the note file when a DESCRIPTION is encountered. It will require a major rewrite to implement the suggested note format.

As a simpler (easier implemented) format I suggest the following:

Description:
text lines from DESCRIPTION
-- 
Location: text line(s) from LOCATION
-- 
Comment:
text lines from COMMENT
-- 
Status: CONFIRMED (this property has fixed, one word values)

The note file is created on first encounter of one of the supported properties. If more follows, each are appended to the file preceded by a separator. Single line properties are kept on a single line.

The properties of interest for events and todos are CATEGORIES, CLASS, COMMENT, DESCRIPTION, LOCATION, RESOURCES, STATUS, TRANSP, CONTACT, RELATED-TO.

[lhca]

Properties of type INTEGER could also be imported in this way: PRIORITY (in events), PERCENT-COMPLETE (in todos), SEQUENCE.

[lhca]

I would like to change the format to

Description:
text lines
from DESCRIPTION
-- 
Location: text line from LOCATION
Status: CONFIRMED (this property has fixed, one word values)
Comment:
several text lines
from COMMENT
-- 

The note file is created on first encounter of one of the supported properties. If more follow, each is appended to the file. Single line properties are kept on a single line, while multi-line properties have a separator appended.

If DESCRIPTION comes first, the result is (almost) as originally proposed by @lfos.

[lfos]

Thanks for all the suggestions!

How about, instead of using the separator multiple times, having continuation lines indented (by, say, two or four spaces)?

Location: text line from LOCATION
Status: CONFIRMED (this property has fixed, one word values)
Comment: several text lines
    from COMMENT 

One issue with separators is that we need to take special care of (i.e. escape) separator sequences in property values. We do not have the same issue with indentation.

The main reasons for me originally suggesting that the description be a special field above the separator are:

1. Backwards compatibility. Except for the separator issue mentioned above, note files in the current format are just note files without properties.
2. Readability and semantics. The file is still called "note", so the note itself should be the primary content of the file. Having the note be separated as I suggested makes it very natural to read the note like an email with some additional fields below. If we want to have the same key-value format for all fields (including the note text), I would probably prefer renaming the file to something like "item metadata" because "note file" is no longer a good description. Or, alternatively, keep the note file as-is and only add the other fields to a new metadata file in whatever format we agree on.

[lhca]

One issue with separators is that we need to take special care of (i.e. escape) separator sequences in property values. We do not have the same issue with indentation.

??? why?

The main reasons for me originally suggesting that the description be a special field above the separator are:

In other words, DESCRIPTION is the main contents of the note file and must come first? Or?

Proporties can appear in any order in an iCalendar object, and the solution I have in mind just appends them to the note file as they are are encountered. If that is not acceptable, I will just drop the issue.

[lhca]

Proporties can appear in any order in an iCalendar object, and the solution I have in mind just appends them to the note file as they are are encountered.

I'm having second thoughts about this approach. It's too constrained.

[lfos]

One issue with separators is that we need to take special care of (i.e. escape) separator sequences in property values. We do not have the same issue with indentation.

??? why?

Because with indentation, we can simply detect whether the line is a continuation line by checking whether the first character is a space, then remove the fixed predefined number of prefix spaces. If any line starts with spaces already, it will just have even more spaces in the prefixed version. With a separator, we actively need to do something about a property value that contains a line that looks like the separator.

In other words, DESCRIPTION is the main contents of the note file and must come first? Or?

That was one of the suggestions, yes.

Proporties can appear in any order in an iCalendar object, and the solution I have in mind just appends them to the note file as they are are encountered. If that is not acceptable, I will just drop the issue.

As I mentioned before, that is okay, too. But it that case, the file should not longer be called "note file" because that's not a good description. I suggested "meta data" instead.

I'm having second thoughts about this approach. It's too constrained.

Could you please elaborate?

[lhca]

I'm having second thoughts about this approach. It's too constrained.

Could you please elaborate?

I am talking about my own approach only (appending properties to the note file as they are encountered in the ical file). Aiming at an "email look" is OK with me.

[lhca]

Back to start https://github.com/lfos/calcurse/issues/9#issuecomment-489155214. Here is my interpretation with more of the boring details.

This is text from DESCRIPTION, one or more lines.
A separator is added only if another supported property is present.
-- 
Location: Text from LOCATION.
Comment: Text from COMMENT with
    continuation lines indented by
    four spaces.
Status: TENTATIVE

We have to decide which additional properties to support. The property name is written in lower case, but capitalized, followed by : (colon-space), followed by the text with continuation lines indented.

How should an empty property be handled (a property that is present in the ical file, but has no value)? The question came up recently for DESCRIPTION (#274). I am inclined to treat it as any other case (the property value is a single, empty line) unless RFC 5545 prescribes fixed values as for STATUS.

Most properties may appear only once, but COMMENT may appear several times.

[lfos]

Yes, I think that's a great solution, except for the fact that we cannot guarantee that the description will come in the same order when performing an import followed by an export (as you noted above). Not sure whether that's an issue, though.

[lhca]

I have a PR coming up.