[Top][All Lists]

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

Re: On zero width spaces and Org syntax

From: Marcin Borkowski
Subject: Re: On zero width spaces and Org syntax
Date: Sat, 04 Dec 2021 07:43:35 +0100
User-agent: mu4e 1.1.0; emacs 28.0.50

On 2021-12-03, at 13:48, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> Hi all,
> It is usually recommended, as you know, to insert a zero width space
> character (Unicode U+200B) as a sort of delimiter mark to solve the
> scenarios of emphasis within a word (for example, =/meta/literature=)
> and others contexts where emphasis marks are not recognized (for example
> =[/literature/]=). I believe that as a puntual workaround it is not bad;
> however, I find it problematic that this character is part, more or less
> de facto, of the Org syntax. For two main reasons:
> 1. It is an invisible character, and therefore it is difficult to
> control and manage. I think it is not good practice to introduce this
> type of characters implicitly in a plain text document.
> 2. It is more natural that this type of space characters are part of the
> 'output' and not of the 'input'. In the input it is better to introduce
> them not implicitly but through their representation. For example, in
> LaTeX (with LuaTeX) using the command '\char"200B{}' (or '^^^^200b'),
> '&#x200B;' in HTML, etc.
> In any case, as an implicit character, I do not see it appropriate for
> the syntax of a markup language. The marks should be simply ascii
> characters, IMHO. So what if Org had a specific delimiter mark for the
> scenarios described above? For example, something like that:

Hi all,

I've skimmed through this discussion.  FWIW, I also use zero-width
spaces in my Org files for this precise reason.  However, I agree that
extending syntax is dangerous.

How about a solution (or maybe it's only a "solution"...) where:

1. We take care to modify the "official" exporters to throw out the ZWSs.
Or even better, convert them to something reasonable, e.g. with LaTeX
they can be discarded or converted to some command – possibly even one
defined in the preamble – so that nothing is lost.  I'd even say that an
option deciding what to do with those could be nice.

2. We modify Emacs itself to somehow highlight the ZWS.  There is (kind
of) a precedent – a no-breaking space is already fontified with
=nobreak-space= face.  At the very least, make whitespace-mode somehow
show ZWSs (which it doesn't now, and I'd probably say it's a bug).

I know that my point 2. is a bit controversial, since it could lead to
alignment issues where a ZWS is displayed as something with a positive
width. OTOH, even now changing the face of a ZWS leads to a narrow
(1-pixel wide) line of a different color.  Is there a way to make it
a bit stronger?

Just some random ideas,

Marcin Borkowski

reply via email to

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