[RFC] Creole-style / Support for **emphasis**__within__**a word**

[RFC] Creole-style / Support for **emphasis**__within__**a word**

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]


Nicolas

(Sorry for multiple posts.  `customize-save-variable' in the attached
minimal emacs -- which I foolishly added to the top of my .emacs --
wiped out all my customizations including IMAP and SMTP settings)

[RFC] Creole-style / Support for **emphasis**__within__**a word**

The attached files should speak for themselves.  Such an arrangement

a) Does not change the status quo AT ALL.
b) Provide more rope.

The patch is in the spirit of "show and tell".  I will not provide a
formal patch.

What about formalizing such an arrangement...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emphasis.org --]
[-- Type: text/x-org, Size: 659 bytes --]

#+OPTIONS: ':nil *:t -:t ::t <:t H:3 \n:nil ^:t arch:headline
#+OPTIONS: author:nil c:nil creator:comment d:(not "LOGBOOK") date:nil
#+OPTIONS: e:t email:nil f:t inline:t num:nil p:nil pri:nil prop:nil
#+OPTIONS: stat:t tags:t tasks:t tex:t timestamp:t toc:nil todo:t |:t
#+TITLE: a
#+DATE: <2014-03-04 Tue>
#+AUTHOR: Jambunathan K
#+EMAIL: kjambunathan@debian-6.05
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export
#+EXCLUDE_TAGS: noexport
#+CREATOR: Emacs 24.3.50.33 (Org mode 8.2.5h)

Support for **emphasis**__within__**a word**. ==A proposal==.

* Headline 1

**bold**and**bold**//italic// __underline__==and==++strike-through++ plain text

[-- Attachment #3: emphasis.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 10286 bytes --]

[-- Attachment #4: .emacs.minimal.el --]
[-- Type: application/emacs-lisp, Size: 1097 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: org-emphasis.diff --]
[-- Type: text/x-diff, Size: 2676 bytes --]

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 0faf1fd..131b442 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2612,6 +2612,11 @@ Assume point is at the first star marker."
 CONTENTS is the contents of the object."
   (format "*%s*" contents))
 
+(defvar org-element--marker->type 
+  (loop for markers in  (mapcar 'car org-emphasis-alist)
+	for element-type in '(bold italic underline verbatim code strike-through)
+	collect (cons markers element-type)))
+
 (defun org-element-text-markup-successor ()
   "Search for the next text-markup object.
 
@@ -2622,15 +2627,10 @@ and CDR is beginning position."
     (unless (bolp) (backward-char))
     (when (re-search-forward org-emph-re nil t)
       (let ((marker (match-string 3)))
-	(cons (cond
-	       ((equal marker "*") 'bold)
-	       ((equal marker "/") 'italic)
-	       ((equal marker "_") 'underline)
-	       ((equal marker "+") 'strike-through)
-	       ((equal marker "~") 'code)
-	       ((equal marker "=") 'verbatim)
-	       (t (error "Unknown marker at %d" (match-beginning 3))))
-	      (match-beginning 2))))))
+	(cons
+	 (or (assoc-default marker org-element--marker->type)
+	     (error "Unknown marker at %d" (match-beginning 3)))
+	 (match-beginning 2))))))
 
 
 ;;;; Code
diff --git a/lisp/org.el b/lisp/org.el
index f2bb99f..24f07f9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4191,10 +4191,14 @@ After a match, the match groups contain these elements:
 	   (body (nth 3 e))
 	   (nl (nth 4 e))
 	   (body1 (concat body "*?"))
-	   (markers (mapconcat 'car org-emphasis-alist ""))
+	   (markers (mapconcat (lambda (em)
+				 (regexp-quote (car em))
+				 )
+			       org-emphasis-alist "\\|"))
 	   (vmarkers (mapconcat
-		      (lambda (x) (if (eq (nth 2 x) 'verbatim) (car x) ""))
-		      org-emphasis-alist "")))
+		      (lambda (x)
+			(regexp-quote (if (eq (nth 2 x) 'verbatim) (car x) "")))
+		      org-emphasis-alist "\\|")))
       ;; make sure special characters appear at the right position in the class
       (if (string-match "\\^" markers)
 	  (setq markers (concat (replace-match "" t t markers) "^")))
@@ -4211,7 +4215,7 @@ After a match, the match groups contain these elements:
       (setq org-emph-re
 	    (concat "\\([" pre "]\\|^\\)"
 		    "\\("
-		    "\\([" markers "]\\)"
+		    "\\(" markers "\\)"
 		    "\\("
 		    "[^" border "]\\|"
 		    "[^" border "]"
@@ -4223,7 +4227,7 @@ After a match, the match groups contain these elements:
       (setq org-verbatim-re
 	    (concat "\\([" pre "]\\|^\\)"
 		    "\\("
-		    "\\([" vmarkers "]\\)"
+		    "\\(" vmarkers "\\)"
 		    "\\("
 		    "[^" border "]\\|"
 		    "[^" border "]"

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> (with-eval-after-load 'org
>   (setcar org-emphasis-regexp-components "^\\n")
>   (setcar (cdr org-emphasis-regexp-components) "^\\n")
>   (customize-save-variable 'org-emphasis-alist org-emphasis-alist))

A small correction ....

Instead of \\n it should be \n.  So use the below form instead.

(with-eval-after-load 'org
  (setcar org-emphasis-regexp-components "^\n")
  (setcar (cdr org-emphasis-regexp-components) "^\n")
  (customize-save-variable 'org-emphasis-alist org-emphasis-alist))

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> [RFC] Creole-style / Support for **emphasis**__within__**a word**
>
> The attached files should speak for themselves.  Such an arrangement
>
> a) Does not change the status quo AT ALL.
> b) Provide more rope.
>
> The patch is in the spirit of "show and tell".  I will not provide a
> formal patch.
>
> What about formalizing such an arrangement...

FWIW I think is the idea is very interesting. This is more verbose, but
it could allow us to get rid of the terrible
`org-emphasis-regexp-components' variable.

Unfortunately, this would introduce incompatibilities in old documents,
unless that is, we keep checking `org-emphasis-regexp-components', but
then, the change would become, IMO, much less desirable.

In a nutshell, I don't think this will go past the active
"backward-compatibility" squad on the ML. What we're really after is
a way to

  - keep single character markup ;
  - get rid of `org-emphasis-regexp-components' ;
  - allow midword markup.

Good luck.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> In a nutshell, I don't think this will go past the active
> "backward-compatibility" squad on the ML. What we're really after is
> a way to
>
>   - keep single character markup ;
>   - get rid of `org-emphasis-regexp-components' ;
>   - allow midword markup.

What I'm after is a bit different:

- keep single character markup;

- simplify `org-emphasis-regexp-components' (getting it of it is the
  extreme version of simplifying it);

- allow a more liberal multiline markup fontification where the user
  does not have to tweak `org-emphasis-regexp-components'.

Midword markup is not a priority to me, but I understand how it could
be useful, this would certainly be a plus.

Also, there is no "backward-compatibility squad", only users who care
about what they like.

-- 
 Bastien

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Andreas Leha]

Hi all,

Bastien <bzg@gnu.org> writes:

[ ...]

>
> Also, there is no "backward-compatibility squad", only users who care
> about what they like.

I have been part in threads that discuss backward-compatibility.  As it
looks, there is the feeling that this ML is too(?) much concerned about
backward-compatibility -- even in favour over new features or cleaner
implementation (both of which the proposed emphasis change would be an
example of, IIUC).

In a way, I am happy that backward-compatibility is now a major
concern.  But on the other hand, it is not my intention to block
enhancements.

For the case at hand, I would happily type double letter emphasis, if
that helps to get a clean implementation.  If it even allows more
features, that would be a benefit.

My point of writing is this:  If a change like this was going to happen,
it would be very nice if a function was provided to change from the old
style to the new style.  This was (at least) once the case for a major
backward incompatible change in babel and even if it did not work
flawlessly it was a big help.
I guess it would be easy for the lisp-guru who removes the regexp to
turn it into such a function.  But it would take quite some time for me
to dig that regexp somewhen later and produce a working translation
function from it...

Anyway, as it looks this is probably hypothetical for this particular
change.

Regards,
Andreas

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Bastien]

Hi Andreas,

I'm also in favor of breaking backward compatibility when
it benefits Org's users and developers.

We should not consider changes only in terms of backward
compatibility, we should also consider them by themselves.

What I like with *this markup* is that it's non-intrusive:
it's easy to type and it does not clutter the document.

And in general, I'd rather fix problems then getting rid
of them for maintainability purpose.

What's the problems with *this markup*?  It is difficult
to get proper fontification in some cases, fontification
of multiple lines is not reliable beyond a certain amout
of lines, and we cannot nest markup.

Until someone has taken the time to seriously try to fix
those problems without changing the current feature, I don't
think we should consider changing the feature itself.

But of course, this is always a trade-off.

-- 
 Bastien

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> What I'm after is a bit different:

Is it?

> - keep single character markup;
>
> - simplify `org-emphasis-regexp-components' (getting it of it is the
>   extreme version of simplifying it);

You call it extreme, I label it ambitious.

Also, "getting rid of it" really means "no need to change it anymore".
I'd rather have a static complex regexp than a simple customizable one
for the sake of syntax consistency. Of course, a fixed simple regexp is
better (and no regexp at all is even better).

> - allow a more liberal multiline markup fontification where the user
>   does not have to tweak `org-emphasis-regexp-components'.

Which is basically "getting rid of it". See above.

> Midword markup is not a priority to me, but I understand how it could
> be useful, this would certainly be a plus.

I agree. This is not a priority, I wasn't clear on this point.

> Also, there is no "backward-compatibility squad", only users who care
> about what they like.

That is what they want us to believe! :)


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Bastien]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> You call it extreme, I label it ambitious.
>
> Also, "getting rid of it" really means "no need to change it anymore".
> I'd rather have a static complex regexp than a simple customizable one
> for the sake of syntax consistency. Of course, a fixed simple regexp is
> better (and no regexp at all is even better).

Fully agreed.

>> Also, there is no "backward-compatibility squad", only users who care
>> about what they like.
>
> That is what they want us to believe! :)

I don't know who is "us" ;)

-- 
 Bastien

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Samuel Wales]

one option might be to keep what we have for emphasis, ossify it, and
create a backend-independent nestable, multiline [and so on] markup
for emphasis.

but not just any syntax [because that would clutter us with more
syntax].  this time it would be $[extensible :pretty-nicely t], and it
will work for non-emphasis features and for emphasis sub-features we
need later.

thus, after this, new features and sub-features do not require new
syntax.  this keeps our syntax issues to a minimum.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Marcin Borkowski]

Dnia 2014-03-22, o godz. 16:30:31
Nicolas Goaziou <n.goaziou@gmail.com> napisał(a):

> > Also, there is no "backward-compatibility squad", only users who
> > care about what they like.
> 
> That is what they want us to believe! :)

Ninja'd!

Re: topic: one idea that is maybe not very Org-ish, but seems
reasonable: Org already uses LaTeX syntax for sub/superscripts, and
accepts LaTeX snippets etc.  Why not allow \textbf{something} parallel
to *something*?  Would it break something?  When using the LaTeX
exporter, currently it seems (from very few simple experiments), that
\textbf{whatever} copies "whatever" verbatim to the file (I tried LaTeX
and HTML exporters).

Of course, one problem would be nesting - regexen won't help in this.
But it could be restricted to just letters or something (yes, I know,
very inelegant hack - but let's brainstorm a little, maybe someone
could come up with a better idea).

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Suvayu Ali]

On Sun, Mar 23, 2014 at 01:06:35AM +0100, Marcin Borkowski wrote:
> Dnia 2014-03-22, o godz. 16:30:31
> Nicolas Goaziou <n.goaziou@gmail.com> napisał(a):
> 
> > > Also, there is no "backward-compatibility squad", only users who
> > > care about what they like.
> > 
> > That is what they want us to believe! :)
> 
> Ninja'd!
> 
> Re: topic: one idea that is maybe not very Org-ish, but seems
> reasonable: Org already uses LaTeX syntax for sub/superscripts, and
> accepts LaTeX snippets etc.  Why not allow \textbf{something} parallel
> to *something*?  Would it break something?  When using the LaTeX
> exporter, currently it seems (from very few simple experiments), that
> \textbf{whatever} copies "whatever" verbatim to the file (I tried LaTeX
> and HTML exporters).

Often LaTeX users tend to forget (including myself) one of Org's
features is to be able to export to different backends without major
modifications to the source file (.org file).

Your proposal breaks that.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Marcin Borkowski]

Dnia 2014-03-23, o godz. 12:32:46
Suvayu Ali <fatkasuvayu+linux@gmail.com> napisał(a):

> On Sun, Mar 23, 2014 at 01:06:35AM +0100, Marcin Borkowski wrote:
> > Dnia 2014-03-22, o godz. 16:30:31
> > Nicolas Goaziou <n.goaziou@gmail.com> napisał(a):
> > 
> > > > Also, there is no "backward-compatibility squad", only users who
> > > > care about what they like.
> > > 
> > > That is what they want us to believe! :)
> > 
> > Ninja'd!
> > 
> > Re: topic: one idea that is maybe not very Org-ish, but seems
> > reasonable: Org already uses LaTeX syntax for sub/superscripts, and
> > accepts LaTeX snippets etc.  Why not allow \textbf{something}
> > parallel to *something*?  Would it break something?  When using the
> > LaTeX exporter, currently it seems (from very few simple
> > experiments), that \textbf{whatever} copies "whatever" verbatim to
> > the file (I tried LaTeX and HTML exporters).
> 
> Often LaTeX users tend to forget (including myself) one of Org's
> features is to be able to export to different backends without major
> modifications to the source file (.org file).
> 
> Your proposal breaks that.

No, it doesn't.  What I meant was to make Org *recognize* the
\textbf{...} etc. syntax and *convert* it to <strong> ... </strong> and
similar things (depending on the backend).  Sorry if I wasn't clear
enough.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Good luck.

Got my answer.  The rest are just details.

RE: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Vincent Belaïche]

Hello,

Sorry to dig out this almost 8 year old discussion, but after looking
into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
Monospace") node, and after looking into the mail archive I could not
find any answer to this question: how to switch style within a word.

I would like to put something like this in an OrgMode document:

  ~--some-cli-option=~/some cli argument/

where the intent is that « --some-cli-option= » would be monospaced, and
« some cli argument » would be italicized, and as you know this does not
work this way.

  Vincent.

De : emacs-orgmode-bounces+vincent.b.1=hotmail.fr@gnu.org <emacs-orgmode-bounces+vincent.b.1=hotmail.fr@gnu.org> de la part de Jambunathan K <kjambunathan@gmail.com>
Envoyé : dimanche 23 mars 2014 03:59
À : Nicolas Goaziou <n.goaziou@gmail.com>
Cc : emacs-orgmode@gnu.org <emacs-orgmode@gnu.org>
Objet : Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word** 
 
Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Good luck.

Got my answer.  The rest are just details.

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Nicolas Goaziou]

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> I would like to put something like this in an OrgMode document:
>
>   ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.

You can put a zero-width space between ~ and /.

Regards,
-- 
Nicolas Goaziou

Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Juan Manuel Macías]

Hi Vincent,

Vincent Belaïche writes:

> Hello,
>
> Sorry to dig out this almost 8 year old discussion, but after looking
> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
> Monospace") node, and after looking into the mail archive I could not
> find any answer to this question: how to switch style within a word.
>
> I would like to put something like this in an OrgMode document:
>
>  ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.
>
>   Vincent.

It seems that this topic is already a classic :-) The supported solution
for intra-word emphases is to introduce a zero width space (U+200B), for
example:

~--some-cli-option=~[zero-width space]/some cli argument/

I don't really like this solution, but at least it works. If you export
to LaTeX, you may want to remove the space using a filter, as in some
(few) cases it can alter the LaTeX result.

The other realistic possibility is to use macros:

{{{mono(--some-cli-option=)}}}{{{emph(some cli argument)}}}

That is, more or less, the state of art. By the nature of its syntax,
emphasis between words is not possible in Org.

Best regards,

Juan Manuel 

RE: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Vincent Belaïche]

Hello,

Thank-you both for the reply, I should have mentioned that I am aware of
this trick but it works only for document encodings which have the
zero-width space, like UTF-8, I was after a fix for documents in
ISO-8859-15, aka latin-9.

  V.

De : Juan Manuel Macías <maciaschain@posteo.net>
Envoyé : lundi 24 janvier 2022 13:09
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : orgmode <emacs-orgmode@gnu.org>
Objet : Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word** 
 
Hi Vincent,

Vincent Belaïche writes:

> Hello,
>
> Sorry to dig out this almost 8 year old discussion, but after looking
> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
> Monospace") node, and after looking into the mail archive I could not
> find any answer to this question: how to switch style within a word.
>
> I would like to put something like this in an OrgMode document:
>
>  ~--some-cli-option=~/some cli argument/
>
> where the intent is that « --some-cli-option= » would be monospaced, and
> « some cli argument » would be italicized, and as you know this does not
> work this way.
>
>   Vincent.

It seems that this topic is already a classic :-) The supported solution
for intra-word emphases is to introduce a zero width space (U+200B), for
example:

~--some-cli-option=~[zero-width space]/some cli argument/

I don't really like this solution, but at least it works. If you export
to LaTeX, you may want to remove the space using a filter, as in some
(few) cases it can alter the LaTeX result.

The other realistic possibility is to use macros:

{{{mono(--some-cli-option=)}}}{{{emph(some cli argument)}}}

That is, more or less, the state of art. By the nature of its syntax,
emphasis between words is not possible in Org.

Best regards,

Juan Manuel 

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Nicolas Goaziou]

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

You mean the source itself is not UTF-8?

I don't think there's a solution for you then, unless you convert it to
UTF-8, of course.

Regards,
-- 
Nicolas Goaziou

RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

Hello,

Actually the source was in UTF-8, but it was using only characters that exist in latin-9, and it is exported to LaTeX for inclusion in a LaTeX document that is in latin-9.

So I used an Emacs lisp snippet to make the export, and in this snippet after calling something like  (org-export-to-buffer 'latex out-buffer nil nil nil t), I was doing some insertion like

      (goto-char (point-max))
      (insert "
% Local Variables:
% coding: latin-9
% End:
")
      (save-buffer)
      (kill-buffer)

so that the exported buffer is converted to latin-9 before being saved.

OK, when I inserted the zero width space this barked because of no zwsp (aka U+200B) in latin-9.

Then I tried something else, I rewrote the code with some some LaTeX snippet @@latex:\kern-0.5em\relax@@ in it, like this:

    ~--my-option=~ @@latex:\kern-0.5em\relax@@ /option value/

that was OK, but this really makes the OrgMode ugly (maybe a custom entity would be better), and also this works only for the LaTeX export.

Then, I tried something else, I passed « utf8,latin9 » options, to LaTeX inputenc package, instead of just « latin9 », and I kept my org mode document in UTF-8, just before exporting I did something like this in the input buffer:

    (goto-char (point-max))
    (insert "\n\n#+begin_export latex\n\\inputencoding{latin9}\n#+end_export\n")
    (goto-char (point-min))
    (insert "\n\n#+begin_export latex\n\\inputencoding{utf8}\n#+end_export\n")

this way the LaTeX processor is switching dynamically from latin9 to utf8 at the beginning of the doc, and back to latin9 at the end of it. But there are two pitfalls:

the first one is that zwsp are not defined in the inputenc utf8.def definition file, so having a zwsp character in the LaTeX code, even though utf8 is declared as input encoding make a LaTeX compilation error.

the second (but this is less serious I think …) is that my document ends with an enumerate list, and the orgmode exporter make the second begin_export go into the enumerate list, not after it. I mean I get in the output this:

   \inputencoding{latin9}
   \end{enumerate}

instead of this:

   \end{enumerate}
   \inputencoding{latin9}

My conlcusion is that for what I am after, an evolution of org-mode would be preferable, maybe I contribute something someday, so that writing one of the following would make it:

   ~--my-option=~\relax{}/option value/
   ~--my-option=~@@:@@/option value/
   \left~--my-option=\right~/option value/
   \left~--my-option=\right~\left/option value\right/
   ~--my-option=~\left/option value\right/


________________________________
De : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

You mean the source itself is not UTF-8?

I don't think there's a solution for you then, unless you convert it to
UTF-8, of course.

Regards,
--
Nicolas Goaziou

[-- Attachment #2: Type: text/html, Size: 12293 bytes --]

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Juan Manuel Macías]

Hi Vincent,

Vincent Belaïche writes:

> My conlcusion is that for what I am after, an evolution of org-mode
> would be preferable, maybe I contribute something someday, so that
> writing one of the following would make it:
>
>    ~--my-option=~\relax{}/option value/
>    ~--my-option=~@@:@@/option value/
>    \left~--my-option=\right~/option value/
>    \left~--my-option=\right~\left/option value\right/
>    ~--my-option=~\left/option value\right/

Considering that Org's emphasis marks are not compromised by contact
with a single quote, I come up with this somewhat dirty solution: you
can use some kind of dummy mark (e.g. two single quotes: '') and put it
between the two emphasis parts. It would then be removed by a filter.
Something like this:

#+BIND: org-export-filter-final-output-functions (my-filter)

#+begin_src emacs-lisp :exports results :results none
  (defun my-filter (text backend info)
    (replace-regexp-in-string "''" "" text))
#+end_src


~some-cli-option=~''/some cli argument/

== LaTeX ==>

\texttt{some-cli-option=}\emph{some cli argument}

The solution is tricky and temporary, but at least it's not as
text-invasive as other options.

Best regards,

Juan Manuel 

RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Thank you so much Juan, I could adapt your filter to my needs, and this works like a charm !

  V.
________________________________
De : Juan Manuel Macías <maciaschain@posteo.net>
Envoyé : mardi 25 janvier 2022 18:30
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hi Vincent,

Vincent Belaïche writes:

> My conlcusion is that for what I am after, an evolution of org-mode
> would be preferable, maybe I contribute something someday, so that
> writing one of the following would make it:
>
>    ~--my-option=~\relax{}/option value/
>    ~--my-option=~@@:@@/option value/
>    \left~--my-option=\right~/option value/
>    \left~--my-option=\right~\left/option value\right/
>    ~--my-option=~\left/option value\right/

Considering that Org's emphasis marks are not compromised by contact
with a single quote, I come up with this somewhat dirty solution: you
can use some kind of dummy mark (e.g. two single quotes: '') and put it
between the two emphasis parts. It would then be removed by a filter.
Something like this:

#+BIND: org-export-filter-final-output-functions (my-filter)

#+begin_src emacs-lisp :exports results :results none
  (defun my-filter (text backend info)
    (replace-regexp-in-string "''" "" text))
#+end_src


~some-cli-option=~''/some cli argument/

== LaTeX ==>

\texttt{some-cli-option=}\emph{some cli argument}

The solution is tricky and temporary, but at least it's not as
text-invasive as other options.

Best regards,

Juan Manuel

[-- Attachment #2: Type: text/html, Size: 2888 bytes --]

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Nicolas Goaziou]

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Actually the source was in UTF-8,


Then use a zero-width space, and remove it from the output with
a filter.

Regards,
-- 
Nicolas Goaziou

RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Vincent Belaïche]

[-- Attachment #1: Type: text/plain, Size: 4895 bytes --]

Just replying to myself : the dynamic latin9/utf8 switch does not really easily work in a LaTeX document (I am sure some people made it work, but I did not manage to make it).

Adding the ZWSP support is easy, just insert

\DeclareUnicodeCharacter{200B}{}

in the document preamble, but this does not work because the table of content gets ugly with the titles likes « germe de générateur pseudo-aléatoire » instead of « germe de générateur pseudo-aléatoire » (some sections in the UTF-8 part going to the toc that is in the latin-9 part).

I tried to circumvent this by using the following encapsulation for the UTF-8 part :

\inputencoding{utf8}\addtocontents{toc}{\protect\inputencoding{utf8}}
...
\inputencoding{latin9}\addtocontents{toc}{\protect\inputencoding{latin9}}

(there are \addtocontents commands in addition to the \inputencoding so that I also switch the encoding in the toc file), but there are still issues, the dynamic switch does not work well with moving arguments like section titles going to the toc file. This is probably a problem of non-immediate write occurring at page shipout.

  V.

________________________________
De : Vincent Belaïche <vincent.b.1@hotmail.fr>
Envoyé : mardi 25 janvier 2022 18:18
À : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Actually the source was in UTF-8, but it was using only characters that exist in latin-9, and it is exported to LaTeX for inclusion in a LaTeX document that is in latin-9.

So I used an Emacs lisp snippet to make the export, and in this snippet after calling something like  (org-export-to-buffer 'latex out-buffer nil nil nil t), I was doing some insertion like

      (goto-char (point-max))
      (insert "
% Local Variables:
% coding: latin-9
% End:
")
      (save-buffer)
      (kill-buffer)

so that the exported buffer is converted to latin-9 before being saved.

OK, when I inserted the zero width space this barked because of no zwsp (aka U+200B) in latin-9.

Then I tried something else, I rewrote the code with some some LaTeX snippet @@latex:\kern-0.5em\relax@@ in it, like this:

    ~--my-option=~ @@latex:\kern-0.5em\relax@@ /option value/

that was OK, but this really makes the OrgMode ugly (maybe a custom entity would be better), and also this works only for the LaTeX export.

Then, I tried something else, I passed « utf8,latin9 » options, to LaTeX inputenc package, instead of just « latin9 », and I kept my org mode document in UTF-8, just before exporting I did something like this in the input buffer:

    (goto-char (point-max))
    (insert "\n\n#+begin_export latex\n\\inputencoding{latin9}\n#+end_export\n")
    (goto-char (point-min))
    (insert "\n\n#+begin_export latex\n\\inputencoding{utf8}\n#+end_export\n")

this way the LaTeX processor is switching dynamically from latin9 to utf8 at the beginning of the doc, and back to latin9 at the end of it. But there are two pitfalls:

the first one is that zwsp are not defined in the inputenc utf8.def definition file, so having a zwsp character in the LaTeX code, even though utf8 is declared as input encoding make a LaTeX compilation error.

the second (but this is less serious I think …) is that my document ends with an enumerate list, and the orgmode exporter make the second begin_export go into the enumerate list, not after it. I mean I get in the output this:

   \inputencoding{latin9}
   \end{enumerate}

instead of this:

   \end{enumerate}
   \inputencoding{latin9}

My conlcusion is that for what I am after, an evolution of org-mode would be preferable, maybe I contribute something someday, so that writing one of the following would make it:

   ~--my-option=~\relax{}/option value/
   ~--my-option=~@@:@@/option value/
   \left~--my-option=\right~/option value/
   \left~--my-option=\right~\left/option value\right/
   ~--my-option=~\left/option value\right/


________________________________
De : Nicolas Goaziou <mail@nicolasgoaziou.fr>
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche <vincent.b.1@hotmail.fr>
Cc : Juan Manuel Macías <maciaschain@posteo.net>; orgmode <emacs-orgmode@gnu.org>
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

Hello,

Vincent Belaïche <vincent.b.1@hotmail.fr> writes:

> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

You mean the source itself is not UTF-8?

I don't think there's a solution for you then, unless you convert it to
UTF-8, of course.

Regards,
--
Nicolas Goaziou

[-- Attachment #2: Type: text/html, Size: 16912 bytes --]

Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**

[Max Nikulin]

On 24/01/2022 19:32, Vincent Belaïche wrote:
> 
> Thank-you both for the reply, I should have mentioned that I am aware of
> this trick but it works only for document encodings which have the
> zero-width space, like UTF-8, I was after a fix for documents in
> ISO-8859-15, aka latin-9.

I have a hope that 8bit charsets will disappear soon. UTF-8 alleviates 
issues with incompatible charsets used for the same alphabet.

You can use a trick with custom links, it has some limitation, but it is 
charset-neutral. See below for details.

[[sep:][~--some-cli-option=~]][[sep:][/some cli argument/]]

> Vincent Belaïche writes:
> 
>> Sorry to dig out this almost 8 year old discussion, but after looking
>> into the git HEAD Org Mode manual (v9.5 or so) (info "(org) Emphasis and
>> Monospace") node, and after looking into the mail archive I could not
>> find any answer to this question: how to switch style within a word.
>>
>> I would like to put something like this in an OrgMode document:
>>
>>    ~--some-cli-option=~/some cli argument/

You are a bit late. It was thoroughly discussed a month ago:

Denis Maier. Org-syntax: Intra-word markup.
Thu, 2 Dec 2021 11:50:32 +0100.
https://list.orgmode.org/4897bc60-b74f-ccfd-e13e-9b89a1194fdf@mailbox.org/

Eric S Fraga. On zero width spaces and Org syntax.
Mon, 06 Dec 2021 11:40:57 +0000.
https://list.orgmode.org/87r1aqj706.fsf@ucl.ac.uk

> A very strong +1 on this.  Org has enough /escape mechanisms/, as you
> call them, to cater for special cases, and these include @@...@@, babel,
> and filters, amongst others.  The simplicity of org is a major
> advantage.

Actually I had expectation that export snippets or macros may help in 
such case. I can not say that results the following observations are 
intuitive for me.

---- >8 ----
#+macro: first $1
- Custom link
   #+begin_src elisp :results none :exports both
     (org-link-set-parameters
      "sep"
      :export (lambda (path desc backend)
	       (if (org-export-derived-backend-p backend 'org)
		   (org-link-make-string (concat "sep:" path) desc)
		 (or desc ""))))
   #+end_src
   + Requires evaluation of elisp code.
   + May be defined to remain on its place after export to Org.
   + May be defined to completely disappear during export
     to other formats
   + Does not allow to put a link inside or to be put inside a link.
   + Does not deactivate markup when put inside:
     *[[sep:]]bold* /italic[[sep:]]/.
   + May be placed immediately after markup /inter/[[sep:]]word.
   + Deactivates following marker inter[[sep:]]/word/.
   + Markup may be placed inside description
   + [[sep:][~--some-cli-option=~]][[sep:][/some cli argument/]]
- Zero width space
   + Invisible, so not really plain text markup.
   + It persists in export result, so a filter is required.
   + =C-x 8 RET 200B RET=
   + ~--some-cli-option=~​/some cli argument/
- Export snippet
   + For some reason =ox-org= does not define
     ~export-snippet~ transcoder,
     so they will be pruned during export to org.
   + May be used to deactivate markup:
     @@s:x@@*not bold* /not italic/@@s:x@@
     (must be put outside).
   + Does not deactivate markup when it is inside:
     *@@s:x@@bold* /italic@@s:x@@/.
   + Does not help when it is necessary to activate markup
     without a space inter@@s:x@@/word/ /inter/@@s:x@@word.
- Macro is useless (besides deactivation of markup when combined
   with export snippets in definition)
   + Beware of commas:
     {{{first("missed" after comma disappears, missed)}}}.
   + Not survived after export to Org.
   + Can not be used to activate markup in any form:
     not{{{first(*bold*)}}}, {{{first(*not*)}}}bold,
     not{{{first()}}}*bold*, {{{first(not)}}}{{{first(*bold*)}}}.
   + Can not be used (without e.g. export snippets) to deactivate markup.
     Still {{{first(/)}}}italic{{{first(/)}}} and broken second macro.