[-- Attachment #1: Type: text/plain, Size: 1020 bytes --] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. ------------------------------------------------------------------------ Using the following text I get failing pdf export: The link is not recognized correctly but ends after the comma and the markup persists in the PDF. /Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail ans [[https://km-bw.de/,Lde/startseite/service/kontakt][Kultusministerium BW]] geschickt. Da hatten wir noch 2 Wochen./ Best wishes, Arne Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/) -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --] Hi Arne, > Using the following text I get failing pdf export: The link is not > recognized correctly but ends after the comma and the markup persists in > the PDF. Thanks for reporting this. I’ve managed to reproduce the behaviour. I also note that this doesn’t happen without the italic markers, i.e. ┌──── │ Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail │ ans [[https://km-bw.de/,Lde/startseite/service/kontakt][Kultusministerium BW]] geschickt. Da hatten wir noch 2 Wochen. └──── Is fine, while your original example, ┌──── │ /Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail ans │ [[https://km-bw.de/,Lde/startseite/service/kontakt][Kultusministerium BW]] geschickt. Da hatten wir noch 2 Wochen./ └──── Causes issues. I also note that in the Org-mode buffer the comma seems to cause issues. I’ve attached a screenshot, in which you can see in the “comma, italics” situation: ⁃ The second line is not italic ⁃ The second `/' of the pair is shown (and I have Org’s entity hiding setting enabled) All the best, Timothy [-- Attachment #2: bad-link-in-buffer.png --] [-- Type: image/png, Size: 28904 bytes --]
[-- Attachment #1: Type: text/plain, Size: 99 bytes --] Ooops, I forgot to mark this as a bug on updates.orgmode.org in my last email. Let’s fix that.
Timothy <tecosaur@gmail.com> writes: > Causes issues. I also note that in the Org-mode buffer the comma seems to cause > issues. I’ve attached a screenshot, in which you can see in the “comma, italics” > situation: > ⁃ The second line is not italic > ⁃ The second `/' of the pair is shown (and I have Org’s entity hiding setting enabled) The problem is with org-emph-re. Our second component of org-emphasis-regexp-components is > Chars allowed as postmatch. End of line will be allowed too. "-[:space:].,:!?;'\")}\\[" So, org-element-italic-parser will treat /, sequence as end of the italic text disregarding that /, is part of the link. If you try the following text, it will not export correctly as well: /Beginning is italic 1^{/,} and tail should be italic/ Though fontification somehow works. Or we can put some other allowed object like inline src block: /Beginning is italic src_elisp{(message "Foo/,")} and tail should be italic/ This time both export and fontification do not work. I suspect that we need to upgrade org-element-italic-parser in non-trivial way to fix this. Best, Ihor
On 03/09/2021 12:17, Dr. Arne Babenhauserheide wrote: > > Using the following text I get failing pdf export: The link is not > recognized correctly but ends after the comma and the markup persists in > the PDF. > > /Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail > ans [[https://km-bw.de/,Lde/startseite/service/kontakt][Kultusministerium BW]] geschickt. Da hatten wir noch 2 Wochen./ It was discussed earlier. On Tue, 20 Apr 2021 22:37:31 +0200, Nicolas Goaziou wrote Re: [Patch] to correctly sort the items with emphasis marks in a list https://orgmode.org/list/874kg0ae0k.fsf@nicolasgoaziou.fr/ : > Maxim Nikulin writes: > >> Surprisingly there are still cases when the old approach works better: >> >> (let ((s (org-sort-remove-invisible >> "A /wrapping [[https://orgmode.org/?a=b&c=d#e][link]] emphasis/"))) >> (set-text-properties 0 (length s) nil s) >> s) >> "A wrapping [[https://orgmode.org?a=b&c=d#e][link]] emphasis/" >> >> I expect "A wrapping link emphasis". > > Yet, your expectations are wrong. There is no link in the text above. > Emphasized text starts at "/wrapping" and ends before "/?". > > Granted, this is a situation where the Org syntax is not very intuitive. > Anyway, the new function is more accurate. > > Maybe we should require a space after punctuation following emphasized > text. I don't know. This is orthogonal to the current discussion. In your particular case it is possible to use "%2C" instead of comma: /Link [[https://km-bw.de/%2CLde/startseite/service/kontakt][kontakt]] link/ As a more general approach, additional emphasis marks can be added around link borders /Test/ [[https://orgmode.org/?q=query][/query/]] /test/ While I believe that during parsing of link target lookup for end of emphasis should be suppressed, I am not sure that it is feasible with current implementation. That is why I consider such behavior as a price for lightweight markup and its current parser.
[-- Attachment #1: Type: text/plain, Size: 784 bytes --] Hi Maxim, > In your particular case it is possible to use “%2C” instead of comma: > > /Link [kontakt] link/ > > As a more general approach, additional emphasis marks can be added around link > borders > > /Test/ [/query/] /test/ > > While I believe that during parsing of link target lookup for end of emphasis > should be suppressed, I am not sure that it is feasible with current > implementation. That is why I consider such behavior as a price for lightweight > markup and its current parser. Perhaps a “fix” could be auto-escaping problematic characters in urls when entering links via `org-insert-link'. All the best, Timothy [kontakt] <https://km-bw.de/%2CLde/startseite/service/kontakt> [/query/] <https://orgmode.org/?q=query>
On 03/09/2021 21:33, Timothy wrote:
>
> Perhaps a “fix” could be auto-escaping problematic characters in urls when
> entering links via `org-insert-link'.
>
> [/query/] <https://orgmode.org/?q=query>
Just to be clear: while comma may be percent-escaped (`org-lint' perhaps
would not be happy), "/?" are interpreted by HTTP server, so such
characters must be preserved.
`org-insert-link' still may detect emphasis markers around the point and
add extra marks. Unfortunately heuristics to detect start marker only
(while typing text when no end marker yet) will be prone to false positives.
On 03/09/2021 21:57, Maxim Nikulin wrote:
> On 03/09/2021 21:33, Timothy wrote:
>>
>> Perhaps a “fix” could be auto-escaping problematic characters in urls
>> when
>> entering links via `org-insert-link'.
>>
>> [/query/] <https://orgmode.org/?q=query>
>
> `org-insert-link' still may detect emphasis markers around the point and
> add extra marks. Unfortunately heuristics to detect start marker only
> (while typing text when no end marker yet) will be prone to false
> positives.
Maybe additional undo step while adding link is enough to alleviate the
issue with false positives (similar to autoreplace patterns in text
processors). If a user notices that additional markers are added
incorrectly, she can remove them through undo. Next undo removes the
inserted link completely.