Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
Hehe ;) No, I was merely suggesting that maybe someone tried too hard to fix non-working urls becauase of other use cases. Luckily it seems fixed now. On 03/06/2014 10:17 AM, Andreas Leha wrote: R. Michael Weylandt michael.weyla...@gmail.com writes: On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum simon.t...@gmx.de wrote: This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. I am not sure, that I understand what you say here. But in case you want to convince me, that exporting non-working links when the user supplies working links is a feature and not a bug, you will have a hard time ;-) - Andreas I believe the former. If the user types in a working link, the exporter shouldn't break it. This could be fixed by sprinkling org-url-decode through various backends, but that suggests to me that the problem may be upstream. Michael
Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
R. Michael Weylandt michael.weyla...@gmail.com writes: On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum simon.t...@gmx.de wrote: This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. I am not sure, that I understand what you say here. But in case you want to convince me, that exporting non-working links when the user supplies working links is a feature and not a bug, you will have a hard time ;-) - Andreas I believe the former. If the user types in a working link, the exporter shouldn't break it. This could be fixed by sprinkling org-url-decode through various backends, but that suggests to me that the problem may be upstream. Michael
Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum simon.t...@gmx.de wrote: This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. I believe the former. If the user types in a working link, the exporter shouldn't break it. This could be fixed by sprinkling org-url-decode through various backends, but that suggests to me that the problem may be upstream. Michael
Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. On 03/03/2014 09:06 PM, R. Michael Weylandt michael.weyla...@gmail.com wrote: On Feb 28, 2014, at 15:26, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: R. Michael Weylandt michael.weyla...@gmail.com michael.weyla...@gmail.com writes: I've tried this with Org 7.9.3 and 8.2.5h to the same result: -- #+TITLE: Test * One Here is a [[http://google.com/search?q=orgmode][link]] -- Exporting to HTML doesn't transform the link but exporting to LaTeX results in the (non-working) http://google.com/search?%3Dorgmode Is there a reason for this behavior and, if so, a way to work around it? RFC 3986 2.2 explicitly says URLs may include `=` and =url-encode-url= doesn't change the link in question. I've played with org-url-hexify-p and read past ML discussions, but they seem primarily concerned with characters which should not appear in URIs. Thanks, Michael Hi Michael, I have recently been bitten by this as well. Based on a block post [fn:1], I now have this in my .emacs as a work-around: --8---cut here---start-8--- (defun al-link-filter (contents backend info) (let ((contents (replace-regexp-in-string #\\+name:.*$ contents)));; old and unrelated (replace-regexp-in-string %3D = contents))) (add-to-list 'org-export-filter-final-output-functions 'al-link-filter) --8---cut here---end--- Hi Andreas, Thanks for this. I had time to dig further and it seems that the 'problem' is the default value of org-link-escape-chars, which explicitly escapes = as well as other valid URL characters. Perhaps someone more familiar with this code could explain the choice these escapes. Michael [Subject updated because the problem isn't LaTeX specific in 8.2.5h, only in 7.9.3]
[O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
On Feb 28, 2014, at 15:26, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: R. Michael Weylandt michael.weyla...@gmail.com michael.weyla...@gmail.com writes: I've tried this with Org 7.9.3 and 8.2.5h to the same result: -- #+TITLE: Test * One Here is a [[http://google.com/search?q=orgmode][link]] -- Exporting to HTML doesn't transform the link but exporting to LaTeX results in the (non-working) http://google.com/search?%3Dorgmode Is there a reason for this behavior and, if so, a way to work around it? RFC 3986 2.2 explicitly says URLs may include `=` and =url-encode-url= doesn't change the link in question. I've played with org-url-hexify-p and read past ML discussions, but they seem primarily concerned with characters which should not appear in URIs. Thanks, Michael Hi Michael, I have recently been bitten by this as well. Based on a block post [fn:1], I now have this in my .emacs as a work-around: --8---cut here---start-8--- (defun al-link-filter (contents backend info) (let ((contents (replace-regexp-in-string #\\+name:.*$ contents)));; old and unrelated (replace-regexp-in-string %3D = contents))) (add-to-list 'org-export-filter-final-output-functions 'al-link-filter) --8---cut here---end--- Hi Andreas, Thanks for this. I had time to dig further and it seems that the 'problem' is the default value of org-link-escape-chars, which explicitly escapes = as well as other valid URL characters. Perhaps someone more familiar with this code could explain the choice these escapes. Michael [Subject updated because the problem isn't LaTeX specific in 8.2.5h, only in 7.9.3]
