Dear Maintainer, when a shell command in an unnumbered list includes '::', it is not recognized as a shell command anymore. To reproduce the bug, paste the following two lines in file 'tmp' asdf :: asdf asdf :: qwer and add the following shell commands to an org file * [[shell:cat ~/tmp | grep "asdf :"]] * [[shell:cat ~/tmp | grep "asdf ::"]] * [[shell:cat ~/tmp | grep "asdf :: "]] If you klick on them you will probably find that the first two work while the last one does not, presumably because it is interpreted as a description list entry. Interestingly, if you use a numbered list 1. [[shell:cat ~/tmp | grep "asdf :"]] 2. [[shell:cat ~/tmp | grep "asdf ::"]] 3. [[shell:cat ~/tmp | grep "asdf :: "]] then all three work. Thanks for this great piece of software, I use it all the time. Best wishes, Josef.
Hi Josef, thanks for your report. As this seems to be a pure upstream problem, could you please follow up on it using the org-mode mailing list[0] ? Once that's done, feel free to add a link to your post in the Debian BTS. Cheers,
Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100 https://list.orgmode.org/878u2a57r2.fsf@nicolasgoaziou.fr/T/#u With more details in e.g. Sun, 28 Feb 2016 00:03:13 +0100 https://list.orgmode.org/87h9gtdadq.fsf@nicolasgoaziou.fr/ Another example of similar confusion: Bug with exporting list with link item containing "::" to markdown https://list.orgmode.org/CABGRHLkLGXYgGNm4CXK_LjOTGTpsLO=5aWD=FyPd1aMy2QdBxw@mail.gmail.com/T/#u And a related issue: try to export text where /italics breaks the link [[https://lists.debian.org/msgid-search/?m=ZITsDG4Dp0wxDQ8g@powdarrmonkey.net][Bits from the Release Team: a trixie customer]] due to adjacent slash and question mark./ It is a price for lightweight markup and it is how org-element parser works. P.S. Behavior of Org parser in pandoc may be different.
Hello Max, Max Nikulin <manikulin@gmail.com> writes: I read the thread upstream, and see what you mean, and upstream's perspective makes sense. How do you feel about keeping this bug open, because this "gotcha" should be documented somewhere. I'm not sure if org-mode's documentation would be the best place, because it's non-free. For future readers of this bug, Brian G Powell wrote some nice style suggestions for avoiding this pitfall, so here is the link: https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=GoCx3rkqKRg@mail.gmail.com/#t Thank you for documenting this one too. Indeed! Please go ahead and give this bug a more useful title. Regards, Nicholas
I do not see any value in having this bug in the open state, but I am leaving decision up to you. I rarely visit list of bugs for the elpa-org and org-mode packages. In my opinion, the "first wins" rule should be prominently stressed in Org mode syntax description and it should be done in some general section, not in description of items https://orgmode.org/worg/org-syntax.html#Items It should help to make behavior of pandoc, org-ruby, etc. more consistent. However I can not suggest specific wording. Despite some conflict of licenses, I do not think it is possible to avoid reading of the Org mode manual. It may benefit from a note on ambiguous syntax. Currently it has some references to zero width space hack only https://orgmode.org/manual/Escape-Character.html that has some drawbacks and not applicable to links. https://orgmode.org/manual/Link-Format.html Discusses escaping of brackets only disregarding possible interference with other markup structures. https://orgmode.org/manual/Plain-Lists.html does not mention possible issues as well. Besides the manual, there are online-only (unless you clone the repository) docs at https://orgmode.org/worg/ If you are more comfortable with Debian wiki, you may create a page with tricks there. Perhaps it would be more "visible" to users than the bug report. While I agree with Brian in general, in this particular case I would consider a more concise variant: breaking "::" by insertion of some characters: - [[shell:cat ~/tmp | grep "asdf :"": "]] does +not+ work. More checkers may be added to `org-lint' to catch similar pitfalls. It falls in a rather generic class of "Enclosing markup may lead to unexpected parsing results" perhaps "Double colon unexpectedly converts an item into description list" would be better
Hi Max and Josef, Max Nikulin <manikulin@gmail.com> writes: I tested with the latest Org version and the bug is still there. May I suggest to the OP (Josef?) to share the bug upstream on the Org-mode list, if not already done? Even if it's a minor gotcha, it deserves to be fixed. Bugs are reported on the mailing list and tracked on https://updates.orgmode.org. I'd rather have the Org manual document the standard syntax and some edge cases, when frequently reported. But such "hacks" rather belong to this page on Worg: https://orgmode.org/worg/org-hacks.html HTH,
lists enough times. An example: Nicolas Goaziou. c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’ Thu, 18 Nov 2021 13:35:19 +0100. https://list.orgmode.org/87y25l8wvs.fsf@nicolasgoaziou.fr : Nicholas D Steeves added the link to the mailing list archive, see comments in the bug tracker. It is not minor issue, it is design of parser as it was implemented by Nicolas Goaziou. I do not mind to get behavior similar to pandoc, but I can not estimate required efforts. Perhaps it would be a breaking change for some users. description breaks link and forces list item to become descriptive one". Another example of a record with similar origin related to parsing approach: "Bug: PDF Export of Link fails [9.4.6]" I see 2 ways: - Serious change of the org-element parser. - More prominently documenting current behavior.
Thanks a lot for the additional context elements. Max Nikulin <manikulin@gmail.com> writes: I'd combine the two ways by documenting the current (wrong) behavior as a footnote in the manual while we change the org-element parser. It's okay to use the manual for non-trivial known issues, whether we can provide hacks to circumvent them or not.