(Org-mode Interop) Clobbering Properties

[ComedyTomedy]

This may not be a design goal, or perhaps not for 1.0, but I think it's a good idea to leave any org-mode markup that BrainTool doesn't understand unaltered, so that the BrainTool.org file can seamlessly interop with Emacs, eleventy, org-roam, LogSeq, and other apps that speak org.

The Problem

I tried adding a property drawer to one of the links:

:PROPERTIES:
:ID: this-is-my-id
:prop: value is a string with whitespace
:END:

After importing to BT, editing the link, then M-x revert-buffer in Emacs, it's been changed to:

:PROPERTIES:
:ID: this
:prop: value
:END:

The Solution

The problem is in BTAppNode.js line 595.

        const reg = /:(\w*):\s*(\w*)/g;              // regex to iterate thru props and values

Can be altered to:

        const reg = /:(\w*):\s*(.*\w)/g;              // regex to iterate thru props and values

This uses the greediness of \s* to guarantee we're not starting the value on whitespace, the greediness of .* to ensure the whole value is included, and the \w character to effectively strip any trailing whitespace (matching the behaviour of Emacs org-entry-get.

[ComedyTomedy]

...we could also do a simpler value slurp and leave trailing whitespace unaltered, too. I can't imagine anything relies on trailing whitespace in values though, given that org won't read it.

[tconfrey]

Thanks for the detailed bug report! And apologies for the delay, I haven't been monitoring this list very closely. The most recent 1.0.2 version of BT, which just went live in the Chrome Store, fixes the bug. I went with the approach of grabbing everything to the end of the line:
/:([\w-]*):(.*)$/gm;

[ComedyTomedy]

Thanks a lot! No problem about response time, I can only apologise for throwing so many thoughts and ideas at you. I mean well.