Improve the key value parsing of MetaEdit

In debugging a QuickAdd script I noted that the MetaEdit 1.7.2 API could be improved to return keys in a more consistent manner. Initially I wasn't too sure why given the value - someKey:: Some value using getPropertyValue('someKey', 'someFilePath') would return no results.

It wasn't until I took a look at the results returned by getPropertiesInFile('someFilePath') did I notice the inconsistencies.

After trying some common formats I noted people discussing in the Issues, I've put together a short list of their in file annotation and how they are returned by getPropertiesInFile():

- (someKey:: Some value) → - (someKey
> - (someKey:: Some value) → > - (someKey
- someKey:: Some value → > - someKey

Furthermore, when using the Dataview () notation to hide the key MetaEdit returns the value with a trailing ). For example:

{key: '- (someKey', content: 'Something something a thing to do)', type: 1}

To make MetaEdit more consistent in it's ability to query and update these values I would propose that MetaEdit drop leading and trailing characters such as -, (, ), [, ], >.

Perhaps the parseInlineFields (and any other relevant places) can be updated so as once the string has been split and trimmed the following regex (or something of the like) .replace(/[\\-\s\(\)\[\]>\\]/g, '') can be applied.

Of course this would need to be applied carefully so as not to accidentally break any value strings that may contain these characters. I'd be happy to open a PR to make these changes, however I'm not overly familiar with the overall structure of MetaEdit / Obsidian plugins, so I might need some additional guidance in making these changes.

Update

I've also noted that if you create a table with two different keys the results returned by MetaEdit omit the second key value pair. For example, given the following table:

 | **Task**                                      | **Heads or Tails** |
 | --------------------------------------------- | ------------------ |
 | (task:: Something something a thing to do)    | (result:: None)    |
 | (task:: Something else to do)                 | (result:: None)    |
 | (task:: Or maybe something else all together) | (result:: None)    |

When you run getPropertiesInFile the results are as follows:

[
    {
        "key": " | (task",
        "content": "Something something a thing to do)    | result",
        "type": 1
    },
    {
        "key": " | (task",
        "content": "Something else to do)                 | result",
        "type": 1
    },
    {
        "key": " | (task",
        "content": "Or maybe something else all together) | result",
        "type": 1
    }
]

So we can see from the | result the parseInlineFields is partially working -- it's not completely taking into account, that the pipe (|) splits the first key from the second.

But in this case I don't think the initial suggestion to just .replace(/[\\-\s\(\)\[\]>\\]/g, '') will resolve this additional problem.

chhoumann / MetaEdit

Improve the key value parsing of MetaEdit #84

Update