linl icon indicating copy to clipboard operation
linl copied to clipboard

footnote trouble with email in return-address

Open rnuske opened this issue 7 years ago • 10 comments

Sometimes it seems useful to include an email address in the return-address block (maybe to suggest a way for faster exchange of messages or ...).

linl seems to get confused if an email address is added to the return-address. It marks the email address with a superscript 1 indicating a footnote but does not print a footnote (eg. email_in_return_address.pdf)

As far as I understood the process: pandoc's "markdown to latex" converts all email address to \href{mailto:...}{\nolinkurl{...}} and the linl template.tex tries to do footnotes instead of hotlinks.

I think there is no need for a footnote in case of email addresses but couldn't come up with a solution. I guess even the mailto and nolinkurl stuff could be done away with but have no clue how communicate this to pandoc

rnuske avatar Nov 07 '17 16:11 rnuske

Reproducible example, please, or the bug report may not exist...

eddelbuettel avatar Nov 07 '17 16:11 eddelbuettel

alright, based on the linl-skeleton:

---
author:
- Aaron Wolen
opening: Dear Dirk,
closing: Sincerely,
address:
- Dirk Eddelbuettel
- 123 Street Rd
- Chicago, IL
return-address: 
- 456 Road St.
- New York, NY
- [email protected]
output: linl::linl
      
---

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin mollis
dolor vitae tristique eleifend. Quisque non ipsum sit amet velit
malesuada consectetur. Praesent vel facilisis leo. Sed facilisis
varius orci, ut aliquam lorem malesuada in. Morbi nec purus at nisi
fringilla varius non ut dui. Pellentesque bibendum sapien velit. Nulla
purus justo, congue eget enim a, elementum sollicitudin eros. Cras
porta augue ligula, vel adipiscing odio ullamcorper eu. In tincidunt
nisi sit amet tincidunt tincidunt. Maecenas elementum neque eget dolor
[egestas fringilla](http://example.com):

> Nullam eget dapibus quam, sit amet sagittis magna. Nam tincidunt,
> orci ac imperdiet ultricies, neque metus ultrices quam, id gravida
> augue lacus ac leo.

Vestibulum id sodales lectus, sed scelerisque quam. Nullam auctor mi
et feugiat commodo. Duis interdum imperdiet nulla, vitae bibendum eros
placerat non. Cras ornare, risus in faucibus malesuada, libero sem
fringilla quam, ut luctus enim sapien eget dolor.

rnuske avatar Nov 07 '17 16:11 rnuske

Oh, I see now. That may be a pandoc interaction.

I guess we can add 'allow for email address' as a feature request. I suspect it may be easiest to make it a new frontmatter idem rather than shoehorning it into address. But I just guessing at this point...

eddelbuettel avatar Nov 07 '17 16:11 eddelbuettel

that would be cool, thanks.

yep, the first half (converting [email protected] to \href{mailto:[email protected]}{\nolinkurl{[email protected]}}) absolutly. The second half (turning all \href{} into foontotes) is at least controlled by linl's template.tex. That's my guess.

rnuske avatar Nov 07 '17 16:11 rnuske

That latter one has a toggle. You could turn that off for a start.

eddelbuettel avatar Nov 07 '17 16:11 eddelbuettel

Tested and verified. Just add

inline-links: true

to your front-mastter. Now the link is part from the from address just as you specified.

We could close this, or keep it open as a 'wishlist' for a from-email field. May as well go with it and make the email a wee bit more visually distinctive. Thoughts, @aaronwolen ?

eddelbuettel avatar Nov 07 '17 16:11 eddelbuettel

just tried it. It works for the email but kills the other link in the example above [egestas fringilla](http://example.com)

rnuske avatar Nov 07 '17 19:11 rnuske

That's an interesting problem.

I agree it should be possible to include an email address and use the links as footnotes option but I'm not sure how best to make that happen.

One option would be to move the line redefining \href to the line following \opening in the template:

...
\opening{$opening$}
\renewcommand{\href}[2]{#2\footnote{\url{#1}}}
...

It's not pretty but it works. The question is would the change have any unintended side effects.

Let's leave this open for now.

aaronwolen avatar Nov 07 '17 20:11 aaronwolen

We need a better long term solution but in the mean time we can workaround this by disabling Pandoc's autolink_bare_uris extension

output: 
  linl::linl:
    md_extensions: "-autolink_bare_uris"

aaronwolen avatar Nov 07 '17 22:11 aaronwolen

The md_extensions: "-autolink_bare_uris" approach looks promising. My little tests showed good results and others seemed to have come up with the same solution for this problem.

Actually, I would prefer to put it into the linl function in R/linl.R, for instance in line 64:

base <- inherit_pdf_document(..., template = template, keep_tex = keep_tex,  md_extensions = "-autolink_bare_uris")

rnuske avatar Nov 08 '17 14:11 rnuske