> Since org is a valid export backend though, perhaps this behaviour should be > reserved for @@:…@@, i.e. no export backend, which I think semantically fits > fairly nicely.
This ends up being even more convenient than I initially realized. The current spec for export snippets is ambiguous when it says "NAME can contain any alpha-numeric character and hyphens" but the implementation behavior requires that "any" means "at least one" and is implemented using the + regex operator. What this means is that @@:...@@ syntax is not actually used in Org at all at the moment and renders as plain text. I agree that we need to avoid @@org:..@@ because it has legitimate uses. Making a back-end of empty string valid for parse separately syntax thus makes @@ syntax more regular overall, and allows @@:...@@ to be processed separately because it currently never enters the export snippet processing. This is important because export snippets do not seem to be easily accessible to earlier phases of the org-export machinery, i.e. there isn't a nice centralized place to preprocess @@org:...@@ even if we wanted to. On the other hand @@:...@@ isn't processed at all. I could be missing something in the org export code though. It will take a bit of work to get this behavior implemented I think, but it doesn't seem to have any conflicts. Some users may have set the empty backend to expand manually via org-export-snippet-translation-alist, but as long as we give org-export-snippet-translation-alist priority and warn people that setting "" manually will disable the new functionality then there shouldn't be any disruption. The behavior also sort of matches what we would want the empty string to be in this case, which is "all backends" and of course the only markup that makes sense for "all backends" is org itself! Best, Tom