Add basic support for properties

[aviav]

See [1]. Does not support property inheritance. Does not support
allowed values. Does not prevent clashes between two keys of different
case, e.g. "key", and "Key". Does not prevent use of special keys.

Keys can only consist of letters a-z and A-Z.

[1] https://orgmode.org/org.html#Properties-and-Columns

[aviav]

Setting to WIP since Travis still warns about OTP version and some out-of-date dependencies

[aviav]

Set Travis to use current OTP, and updated Ex_Doc. Now there are no warnings.

If you spot flaws in this PR, comments are welcome. Since I intend to use this parser a lot, I'll probably get around to making improvements also in the code of this PR

[aviav]

Reading CI log closely, Dialyxir asks to be added with runtime: false. So I changed that, and also set only: :dev according to its current readme.

[nilclass]

So, I know you added _ here on your repo as well. But I was wondering: should the set of characters really be limited?
I didn't find any mention of what valid properties are, except that they start and end with a colon.

Judging by what gets highlighted, it doesn't seem like there's any restriction (not even spaces):

So maybe \:([^\:]+)\: is safer here?

[aviav]

In the best case, we also respect rules about inherited properties, allowed values or adding to properties [1]. However, limiting the character set was just an arbitrary decision on my part after something -- but I didn't note down what it was -- didn't work as I expected, and I'd agree it is probably an unnecessary restriction. I searched for a while what characters could be used, but didn't find anything explicit, and so I deduced from the examples in the manual.

Do you think as a first step it would be okay if we don't give special treatment to '+' suffixes [1], special properties [2], etc.? In that case, I'd make the change you describe and leave additional refinement to the next person who needs it enough

[1] https://orgmode.org/manual/Property-syntax.html#Property-syntax
[2] https://orgmode.org/manual/Special-properties.html#Special-properties

[rrix]

This appears to be incorrect syntax in your test case, the properties must be in a drawer.

* Test
:PROPERTIES:
:property-with-dashes: 123
:property with spaces: 123
:123278&%#@!#^$(#$: 345
:END:

whether placed in the property drawer or not, these properties are not presented in the org-mode
APIs, org-entry-properties or lower-level org-get-property-block which is specifically looking
for these drawers, using the regular expression stored in org-property-drawer-re.

org-entry-properties uses re-search-forward to match within that property block using org-property-re

Consider the following org-mode document:

#+begin_src emacs-lisp :results none
(highlight-regexp org-property-drawer-re 'hi-yellow)
(highlight-regexp org-property-re 'hi-pink)
(defun tmp/test-get-block ()
  (interactive)
  (let ((block (org-get-property-block)))
    (message "%s" (org-entry-properties))
    (message "%s" (if-let ((beg (when block (car block)))
                           (end (when block (cdr block))))
                      (buffer-substring beg end)
                    "NOPE"))))
#+end_src

* Test
:property-with-dashes: 123
:property with spaces: 123
:123278&%#@!#^$(#$: 345

* Test
:PROPERTIES:
:property-with-dashes: 123
:property with spaces: 123
:123278&%#@!#^$(#$: 345
:END:

* Test
:PROPERTIES:
:property-with-dashes: 123
:property with spaces: 123
:END:

* Test
:PROPERTIES:
:property-with-dashes: 123
:123278&%#@!#^$(#$: 345
:END:

* Test
:PROPERTIES:
:property-with-dashes: 123
:END:

* Test
:PROPERTIES:
:property_with_undies: 123
:END:

Executing the first highlight-regexp with C-x C-e at the end of it shows the last three headings
being matched as property blocks; the first three will not even consider them in
org-entry-properties. Going further, the second line will show which properties will be exported
within those blocks. This can be verified using the included function, which writes to the
*Messages* buffer the entry under the cursor's properties as returned by the high level APIs, as well as the area of the buffer returned by org-get-property-block, or "NOPE" if none match.

[rrix]

Sorry, that may've been a bit unconstructive. I was looking around GitHub at org-mode parsers for a side-project and got nerd sniped. :)

[aviav]

Skimming this, I think it is definitely constructive. Thanks! I've only been using this branch a little so far, and I also don't know that much about org mode syntax yet. I have my use cases, and that's that.

I'll look at your comment in detail, and hopefully come around to change this PR soon. If you found something better that you'd rather use to access org files from Elixir, do let me know ☺