Hi all, After a bunch of rambling (see below if interested), I think I have a solution that should work for everyone. The key realization is that what we really want is the ability to have a "parse me separately" type of syntax. This meets the intra-word syntax needs and might meet some other needs as well.
The solution is to make @@org:...@@ "parse me separately" block! It nearly works that way already too! To minimize typing we could have @@:...@@ the empty type default to org. This seems like a winner to me. The syntax for it already exists and won't conflict. It requires relatively minimal additional typing the implication is clear, and there are other places where such behavior could be useful. This syntax seems like a winner to me @@org:/hello/@@world @@:/hello/@@world You can also do things like #+begin_src org I want a number in this number@@org:src_elisp{(+ 1 2)}@@word! #+end_src Which would render to #+begin_src org I want a number in this number3word! #+end_src Thoughts? Best! Tom --------------- rambling below ------------- > This idea reminds me a bit of Scribble/Racket where every document is > just inverted code, which makes it possible to insert arbitrary Racket > code in your prose... I will say, despite some of my comments elsewhere, that I think exploring certain features of Scribble syntax for use in Org mode would simplify certain parts of the syntax immensely. For example various inline blocks are an absolute pain to parse because they allow nested delimiters /if they are matched/. The implementation of the /if they are matched/ clause is currently a nasty hack which generates a regular expression that can only actually handle nesting to depth 3. Actually implementing the recursive grammar add a lot of complexity to the syntax and is hard to get right. It would be vastly simpler to use Scribble's |<{hello }} world}>| style syntax and always terminate at the first matching delimiter. I'm sure that this would break some Org files, but it would make dealing with latex fragments and inline source blocks and inline footnotes SO much simpler. Matching an arbitrary number of angle brackets does add some complexity, but it is tiny compared to the complexity of enforcing matched parens and their failure cases especially because many of the places where nesting is required probably only see use of the nesting feature in a tiny fraction of all cases. One other reason why this is attractive is that all the instances where nested delimiters can appear on a line are preceded by some non-whitespace character. This means that using the pipe syntax does not conflict with table syntax! Now the question comes. If we could implement this for delimiters, could we also implement something similar for markup? The issue with the proposed markup outside delimiter inside approach is that it will change existing behavior for files that want the delimiters to be included in the markup, i.e. /{oops}/ becoming /oops/ is bad. A second issue is that putting the delimiter inside the markup cannot work for verbatim and code ={oops}= is ={oops}= no matter what. Therefore the solution is not uniform across all types of markup. We need another solution that works for all types of markup. What if we put the "start arbitrary markup" char outside the markup? Say something like |/ital/|icks? Or what if we went whole hog and used |{/ital/}|ics and made the |{...}| syntax trigger a generalized feature where the contents of the |{...}| block are parsed by themselves and can abutt any other text? This would be generally useful in a variety of situations beyond just intra-word markup. What are the issues with this approach? The first issue is that there is a conflict with table syntax if we were to use the pipe character because markup can appear at the start of a line. The second issue is that it might be confusing for users if |{}| also worked like {} when in the context of latex elements or inline src blocks, or maybe that is ok because |{}| never renders as text. Hrm. Ok. Second issue resolved, but what to do about the first? If we want generalized "parse this by itself" syntax so that we can write hello|{/world/}|ok, then we need a solution that can appear at the start of a line. So we can't use pipe because that is always a table line even if a zero width space is put before it ;). What other options do we have? How about #+|{/hello/}|world for the start of a line? As long as there is no trailing colon it isn't a keyword, so it could work ... except that if someone reflows the text and it is no longer a the start of a line then the syntax breaks. That is to say using #+| at the start of a line is not uniform, so we can't take that approach. What other chars to we have at our disposal? Hrm. How about @@? Could we use that? What happens if we use @@org:/hello/@@world? Or maybe if we want to minimize the number of chars we could do @@:/hello/@@world and have the empty prefix in @@ blocks mean org?