[feature request] Make the start and end delimeters of a template token customizeable

[con-f-use]

In templates, it seems ashes hardcodes the delimiter to be opening and closing curly brackets. It think it would be a small but useful feature to have any arbitrary string as opening and closing delimiter.

I.e. if I have a template file:

Hello, {[(world)]}

I think it would be useful to do:

ashes --template mytmplt.txt -M '{ "world": "People" }' --opening-delimeter '{[(' --closing-delimiter  ')]}'

And get

Hello, People

[jvanasco]

The hardcoding is (likely) because the dust specification is for curly braces.

I don't know if @mahmoud would be open to this or not... But this is quite a fundamental change and should really have unit tests submitted with it to ensure current and backwards behaviors.

[con-f-use]

Well, the way I implemented it for now, is really trivial and only effects the command line application. I don't know if there is any weird behavior with usages that are more out there (e.g. | as delimeter, when filters are specified), but at least that would not effect backwards compatibility. Only applications that actually specify --start-delimeter or --end-delimeter, have a change to be buggy. So I'm sure existing users are safe for now. ;-)

[mahmoud]

Hey there! First off, thank you for the interesting proposal. I think I know where you're coming from and I've been there before. Especially at the command line, templating templates of templates. It's not great, but sometimes it's unavoidable (I presume this is not just for aesthetic reasons).

The implementation looks like it works, as well. I'm inclined to merge, with a couple of reservations/thoughts:

I agree with @jvanasco that it would be good if we had a test or two for this. If you're up for it, a bit of subprocessing to test the CLI would be welcome. :)

The main thing is that tokenization/parsing is not Context-specific. For the command line this is fine, we have little-to-no global concern in that use case, so this is fine for that. I think long-term having the delimiters on the Context would be the only way to consistently offer this functionality for non-CLI purposes.

How does that sound?

[con-f-use]

Sounds good, except I have no idea how to write a test for the command line interface in your current test paradigm. Seems there isn't an existing test I could build on for the CLI. All the existing tests deal with the ashes module being used from within python. I wouldn't even know how to call main() in your test suit. A system call would be feasible but that seems like a dirty workaround.

---

Just a dump of few things that work (ignore this - it's for future tests):

$ python ashes.py -T 'Hello, {[(world|h)]}' -M '{"world": "<b>People</b>" }' \
    -s '{[(' -e ')]}'
Hello, &lt;b&gt;People&lt;/b&gt;

$ python ashes.py -T '{[(#names)]}{[(.)]}{[(~n)]}{[(/names)]}' \
    -M '{"names": ["Moe", "Larry", "Curly"]}'  -s '{[(' -e ')]}'
Moe
Larry
Curly

$ python ashes.py -T '{[(@iterate sort="desc" sort_key=2 key=lol)]}({[($0)]}:{[($1)]}:{[($2)]}){[(/iterate)]}' \
     -M '{"lol": [[1, 10, 100], [1, 2, 3], [4, 5, 6]]}'  -s '{[(' -e ')]}'
(1:10:100)(4:5:6)(1:2:3)