emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [BUG] Exporting italic link with bang inside to html fails to parse the link [9.5.2 (N/A @ /gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)]
Date: Sat, 30 Apr 2022 21:25:44 +0700	[thread overview]
Message-ID: <t4jgta$q8e$1@ciao.gmane.io> (raw)
In-Reply-To: <8735hu92dh.fsf@localhost>

On 30/04/2022 19:34, Ihor Radchenko wrote:
> Max Nikulin writes:
>> 2021-09-03  5:17 Dr. Arne Babenhauserheide Bug: PDF Export of Link fails
>> https://list.orgmode.org/87pmtqp79s.fsf@web.de/T/#u
>> Timothy suggested to fix `org-insert-link' somehow in than thread.
> Yeah. I recall a number of bug report related to this behaviour.
> Though I wanted to focus on org-insert-link here.

Then the older bug may be cancelled as a duplicate.

> We can expect users to change the markup if they type a problematic link
> manually, but not when specialised functions like org-insert-link are
> used. In this scenario, org-insert-link should take care about not
> messing up the existing markup.
>>> To force Org mode not treat internal /! as italics ending, you can
>>> insert a zero-width space before "/": <zero width space>/!
>> Unfortunately It requires an additional export filter to remove zero
>> width spaces.
> Yeah. Right. It should even be an easy patch, which would be welcome :)

I meant a custom user filter. I consider zero width spaces as the last 
resort. Nicolas considered making zero width spaces an official part of 
syntax stripped during export and a way to preserve some of them. In the 
case of links I still prefer breaking emphasis at the link borders. 
`org-insert-link' may check after inserting the markup if it is parsed 
as a link and add more markers if necessary. Unfortunately it is not 
always possible. In the following case


additional markers would not work (unless augmented by zero width 
spaces, but at least they will be outside of link target)


However mostly it is a decent workaround since links are usually 
surrounded by spaces. At certain moment I was surprised that emphasis 
markers are not recognized at the borders of export snippets and they 
are active one at one side of links.

I am afraid that zero width spaces in link targets may lead to confusion 
of users since in the most cases e.g. http: URLs may be pasted to 
external application as is.

  reply	other threads:[~2022-04-30 14:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 10:18 Dr. Arne Babenhauserheide
2022-04-30  9:37 ` Ihor Radchenko
2022-04-30 11:47   ` Max Nikulin
2022-04-30 12:34     ` Ihor Radchenko
2022-04-30 14:25       ` Max Nikulin [this message]
2022-05-01  3:27         ` Ihor Radchenko
2022-05-02 12:32           ` Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='t4jgta$q8e$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: [BUG] Exporting italic link with bang inside to html fails to parse the link [9.5.2 (N/A @ /gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)]' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).