Aaron Ecay <aaronecay@gmail.com> writes:

Hello, Aaron, all!

> API change to remove the ‘new-style’ arguments from these functions.
> I don’t have any clever ideas to solve this, and it’s not an objection

How about this approach? If it's new-style, we pass the new-style
property list as the only parameter to the org-protocol function. Since
the standard org-protocol handlers have been updated to deal with
property lists, they should cover maybe 95% of use cases. I've changed
the condition-case to a more general error handler, so anyone with
custom functions (who presumably uses old-style links too) will get the
old-style behaviour and a warning.

> (org-protocol-parse-parameters, org-protocol-assign-parameters): New
> functions.

Done.

> I also think the convention in Changelogs is not to put in details, but
> just to say “New function” or “Accept new-style links”.  A narrative
> explanation can be put in the git commit message below the changelog

I have no idea either. I've simplified the changelog message, though.

>> +(defun org-protocol-parse-parameters (info new-style &optional default-order unhexify separator)
> Is there ever a case where we would want unhexify to be something other
> than t?  Hexification is imposed by the URL format, there is no optionality

Beats me, but the previous implementation made it a separate parameter
for org-protocol-split-data, so I figured I'd carry it upwards into this
new wrapper function. The previous implementation of
org-protocol-open-source unhexified after parsing the parameters instead
of passing the unhexify parameter to org-protocol-split-data directly.
I'm not sure if anyone's relying on the nuances of that, so I left it
roughly the same.

> about it.  Handler functions get access to the raw string if they need it
> for some reason, I don’t think our helper functions need to bother

Now that I've changed handler functions to use only one parameter, they
don't get the raw strings unless they're greedy handler functions or
they use old-style links... Hmm.

> unhexify != t case. Similarly, I would not have a separator argument,
> but use the value of ‘org-protocol-data-separator’ directly. In the
> rare case that a caller needs to influence the separator, they can
> let-bind that variable. TLDR: can we get rid of unhexify and separator
> arguments?

Same notes as for hexify. Probably okay either way, but I don't know
enough about who else uses this code to say. =) I can change it if you'd
like to make that decision.