On 2016-08-30 06:08, Nicolas Goaziou wrote:
> I have no objection to this.

Ok; patch attached :) Here's a test case:

    ~this~~won't~~work~
    ~but~​~this~​~will~
    ~and~⁠~so~⁠~will~⁠~this~

    ⇒ <code>this~~won't~~work</code>
      <code>but</code>​<code>this</code>​<code>will</code>
      <code>and</code>⁠<code>so</code>⁠<code>will</code>⁠<code>this</code>

You can see the difference in behaviour by resizing the browser window: the second line will break at code boundaries (it uses zero-width spaces) while the second line will stay together (it uses word joiners, aka zero-width no-break spaces)

I detailed the change in the commit message.

> However, another option is to get rid of
> `org-emphasis-regexp-components', make every paired "=" character
> trigger verbatim mode and every paired "~" characters trigger code mode,
> but provide a way to escape "=" and "~". It should probably be extended
> to any emphasis markup and special characters like "|", "#"...

I agree, though this seems non-trivial.  Here's another idea (I don't know how it compares to other options :): src_<lang>[]{} could be extended to allow different delimiters; this would make it more widely usable. For example, the following forms would all be equivalent:

    src_elisp[…options…]<…code…>
    src_elisp[…options…]“…code…”
    src_elisp[…options…]⟨…code…⟩
    src_elisp[…options…]«…code…»

This is inspired by LaTeX's \verb syntax, but using paired delimiters.  The nice part of this is that it would solve the current issue that makes src_<lang> not always usable, namely unmatched curly braces:

    #+PROPERTY: header-args :exports code
    src_elisp{(defun foo () ?})}
    ⇒ <code class="src src-lisp">(defun foo () ?</code>)}

    #+PROPERTY: header-args :exports code
    src_elisp{(defun foo () ?\})} is an ELisp function
    ⇒ <code class="src src-lisp">(defun foo () ?\})</code>