[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs
From: |
Sacha Chua |
Subject: |
Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs |
Date: |
Mon, 07 Dec 2015 12:52:44 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
Aaron Ecay <address@hidden> 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.
0001-org-protocol-Allow-key-val-key2-val2-style-URLs.patch
Description: Text Data
Sacha
- [O] [PATCH] org-protocol: Allow optional port specification, Sacha Chua, 2015/12/02
- Re: [O] [PATCH] org-protocol: Allow optional port specification, Rasmus, 2015/12/02
- Re: [O] [PATCH] org-protocol: Allow optional port specification, Aaron Ecay, 2015/12/03
- [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Sacha Chua, 2015/12/04
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Aaron Ecay, 2015/12/05
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs,
Sacha Chua <=
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Sacha Chua, 2015/12/07
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Sacha Chua, 2015/12/18
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Nicolas Goaziou, 2015/12/20
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Sacha Chua, 2015/12/21
- Re: [O] [PATCH] org-protocol: Allow key=val&key2=value2-style URLs, Nicolas Goaziou, 2015/12/22