On Wed, Dec 12, 2018 at 9:59 AM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > > Could you give more context about the bug you're encountering? What does > mean "function correctly if a URL was not provided"? What is the use > case? What result did you expect, besides not encountering an error > message?
The issue occurs when org protocol capture is invoked without a url param, e.g. emacsclient 'org-protocol://capture?url=percent-encoded-url&body=some-text' vs emacsclient 'org-protocol://capture?body=some-text' By "function correctly", I mean make the latter not break org-insert-link by not corrupting the value of org-stored-links. The use case is capturing some text without an associated URL. The result I expect is the latter not breaking org-insert-link. Note that invoking the latter otherwise behaves correctly/as expected. It starts the capture process with the provided body text/initial contents. The only thing that breaks is org-insert-link when the user calls org-insert-link later. > There are multiple ways to solve this. In particular, if a URL is not > provided, it seems natural to store nil instead, as > `org-protocol-capture' currently does. If we do not support missing URL, > then it should raise an error instead of letting it slip into > `org-insert-link'. If we do, then `org-insert-link' should handle it > gracefully. Except storing nil is not supported by org-insert-link, breaking it until the savvy user manually fixes org-stored-links. I don't see what meaning storing and inserting a nil link could have. We could change org-insert-link to fix or ignore the invalid value in org-stored-links, but why not stop inserting the invalid value into org-stored-links in the first place? > > So, again, more context could help understanding what is the best > solution. > > Regards, > > -- > Nicolas Goaziou
