RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**
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
Envoyé : mardi 25 janvier 2022 18:30
À : Vincent Belaïche
Cc : orgmode
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
RE: [RFC] Creole-style / Support for **emphasis**__within__**a word**
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
Envoyé : mardi 25 janvier 2022 18:18
À : Nicolas Goaziou
Cc : Juan Manuel Macías ; orgmode
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
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche
Cc : Juan Manuel Macías ; orgmode
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello,
Vincent Belaïche 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**
Hello, Vincent Belaïche 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**
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
Envoyé : mardi 25 janvier 2022 11:55
À : Vincent Belaïche
Cc : Juan Manuel Macías ; orgmode
Objet : Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello,
Vincent Belaïche 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**
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**
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-9b89a1194...@mailbox.org/
Eric S Fraga. On zero width spaces and Org syntax.
Mon, 06 Dec 2021 11:40:57 +.
https://list.orgmode.org/87r1aqj706@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.
Re: [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Vincent Belaïche 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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
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
Envoyé : lundi 24 janvier 2022 13:09
À : Vincent Belaïche
Cc : orgmode
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: [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**
Hello, Vincent Belaïche 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**
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...@gnu.org de la part de Jambunathan K Envoyé : dimanche 23 mars 2014 03:59 À : Nicolas Goaziou Cc : emacs-orgmode@gnu.org Objet : Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word** Nicolas Goaziou writes: > Good luck. Got my answer. The rest are just details.
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Nicolas Goaziou n.goaz...@gmail.com writes: Good luck. Got my answer. The rest are just details.
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
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.goaz...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Dnia 2014-03-23, o godz. 12:32:46
Suvayu Ali fatkasuvayu+li...@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.goaz...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Jambunathan K kjambunat...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hi Nicolas, Nicolas Goaziou n.goaz...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hi all, Bastien b...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Bastien b...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Nicolas Goaziou n.goaz...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Dnia 2014-03-22, o godz. 16:30:31
Nicolas Goaziou n.goaz...@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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
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.
[O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Nicolas [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. That said, if I were to say Let's formalize this arrangement what will you say? .emacs.minimal.el Description: application/emacs-lisp emphasis.odt Description: application/vnd.oasis.opendocument.text #+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
[O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Nicolas (Re-sent with the diff file) [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. That said, if I were to say Let's formalize this arrangement what will you say? #+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 emphasis.odt Description: application/vnd.oasis.opendocument.text .emacs.minimal.el Description: application/emacs-lisp 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 ]
[O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
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... #+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 emphasis.odt Description: application/vnd.oasis.opendocument.text .emacs.minimal.el Description: application/emacs-lisp 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: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Jambunathan K kjambunat...@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))
