emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] Bug: Please make org-emphasis-regexp-components respect all whitespa


From: Reuben Thomas
Subject: [O] Bug: Please make org-emphasis-regexp-components respect all whitespace [9.0.10 (9.0.10-5-g1654a5-elpa @ /home/rrt/.emacs.d/elpa/org-20170904/)]
Date: Thu, 14 Sep 2017 20:59:01 +0100


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.
------------------------------------------------------------------------

I tried writing:

  ~get~/~set~ methods

Fair enough, this renders as all verbatim, according to the parsing rules.

So, I tried adding zero-width spaces around the slash. Same result.

org-emphasis-regexp-components indeed does not consider all whitespace,
just some. So, I tried adding [:space:] to the PRE and POST patterns,
and now it works.

I currently have in my Emacs init:

(setq org-emphasis-regexp-components ;; define before loading org
      '("[:space:]('\"{" "-[:space:].,:!?;'\")}\\[" "[:space:]\r\n" "." 1))

In other words, I added [:space:] to the BORDER pattern too.

It would seem reasonable to have something like this be the default. In
particular, worg/dev/org-syntax.org already talks about “whitespace”,
not specifically “spaces, tabs etc.”.

But, I wonder, is it a problem that [:space:] contains vertical
whitespace characters too? (I left “\r\n” in the BORDER pattern as a
reminder that they are there on purpose, whereas PRE and POST previously
contained only space and tab, i.e. horizontal whitespace.) On the other
hand, since PRE and POST are anchored to the start and end of a line,
and the number of newlines is by default limited to 1, perhaps it’s not
a problem?

In any case, it would be nice to have a natural solution to the problem
of emphasis delimiters in this sort of situation. Simply taking
advantage of Unicode characters such as zero-width space seems simpler
than complicating the parser (and it’s also increasingly obvious to
users as they get used to the power of Unicode, and is the sort of trick
that works with lots of different systems, not just Org).

Emacs  : GNU Emacs 25.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-12
Package: Org mode version 9.0.10 (9.0.10-5-g1654a5-elpa @ 
/home/rrt/.emacs.d/elpa/org-20170904/)
-- 
https://rrt.sc3d.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]