all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Reuben Thomas <rrt@sc3d.org>
To: emacs-orgmode@gnu.org
Subject: 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	[thread overview]
Message-ID: <87lglh9hmi.fsf@sc3d.org> (raw)



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	other threads:[~2017-09-14 19:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 19:59 Reuben Thomas [this message]
2017-09-14 22:22 ` 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/)] Nicolas Goaziou

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lglh9hmi.fsf@sc3d.org \
    --to=rrt@sc3d.org \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.