From: "Clément Pit--Claudel" <clement.pit@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug? Highlighting inconsistent with export
Date: Tue, 30 Aug 2016 12:36:40 -0400 [thread overview]
Message-ID: <6869e618-463c-2c72-d60f-9c4b9fe54ea9@gmail.com> (raw)
In-Reply-To: <87eg56in7c.fsf@saiph.selenimh>
[-- Attachment #1.1.1: Type: text/plain, Size: 1996 bytes --]
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>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-Add-zero-width-spaces-to-org-emphasis-regexp-compone.patch --]
[-- Type: text/x-diff; name="0001-Add-zero-width-spaces-to-org-emphasis-regexp-compone.patch", Size: 1902 bytes --]
From 8ac4260f312c5ddfc0c350ba30285dd0efde471d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Pit--Claudel?= <clement.pitclaudel@live.com>
Date: Tue, 30 Aug 2016 12:22:29 -0400
Subject: [PATCH] Add zero-width spaces to org-emphasis-regexp-components
* lisp/org.el: Add U+8203 and U+8288 to pre and post regexps of
org-emphasis-regexp-components; this makes it easy to fix cases in
which a marker is not properly detected, by inserting a zero-width
space (breaking) or a word joiner (non breaking) before or after the
marker.
---
lisp/org.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index bec8a99..80f7b06 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4496,7 +4496,7 @@ After a match, the match groups contain these elements:
;; set this option proved cumbersome. See this message/thread:
;; http://article.gmane.org/gmane.emacs.orgmode/68681
(defvar org-emphasis-regexp-components
- '(" \t('\"{" "- \t.,:!?;'\")}\\[" " \t\r\n" "." 1)
+ '(" \t('\"{" "- \t.,:!?;'\")}\\[" " \t\r\n" "." 1)
"Components used to build the regular expression for emphasis.
This is a list with five entries. Terminology: In an emphasis string
like \" *strong word* \", we call the initial space PREMATCH, the final
@@ -4511,7 +4511,9 @@ body-regexp A regexp like \".\" to match a body character. Don't use
non-shy groups here, and don't allow newline here.
newline The maximum number of newlines allowed in an emphasis exp.
-You need to reload Org or to restart Emacs after customizing this.")
+The default for both pre and post includes zero-width spaces ()
+and word joiners (, aka zero-width no-break space). You need to
+reload Org or to restart Emacs after customizing this variable.")
(defcustom org-emphasis-alist
'(("*" bold)
--
2.7.4
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-08-30 16:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 17:52 Bug? Highlighting inconsistent with export Clément Pit--Claudel
2016-08-30 10:08 ` Nicolas Goaziou
2016-08-30 16:36 ` Clément Pit--Claudel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6869e618-463c-2c72-d60f-9c4b9fe54ea9@gmail.com \
--to=clement.pit@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).