Re: [O] Problem with org-entities-user
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 22.9.2012, at 10:52, Nicolas Goaziou wrote: If the LaTeX command doesn't require an argument, you can always add it to `org-entities-user'. Yes, even though this is not very clean by itself. This is debatable. Entities are perfectly integrated into Org and are, by essence, multiple-back-end friendly. Anyway this is a minor point. I guess it will be swept under the rug of historical reasons, after all. Maybe not. I can go along with your arguments for cleanness. Would you object to keeping this feature in as an option, turned off be default, so that it is at least easy to keep lengthy files working? I'd rather leave it as it is, then. This option would require to maintain two versions of the parser: one without LaTeX commands and another one with them. That would defeat the whole point of removing them. The way I understand it, the new exporter will be default in 8.0, so this is the time to make some incompatible changes. Indeed. I will preserve my quota of backward-incompatible changes for other things. Regards, -- Nicolas Goaziou
Re: [O] Problem with org-entities-user
On 23.9.2012, at 10:30, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 22.9.2012, at 10:52, Nicolas Goaziou wrote: If the LaTeX command doesn't require an argument, you can always add it to `org-entities-user'. Yes, even though this is not very clean by itself. This is debatable. Entities are perfectly integrated into Org and are, by essence, multiple-back-end friendly. I only mean in the sense that entities are made to insert symbols and characters, not to execute commands. It certainly can be used to that, but this is not the intention of this mechanism. Anyway this is a minor point. I guess it will be swept under the rug of historical reasons, after all. Maybe not. I can go along with your arguments for cleanness. Would you object to keeping this feature in as an option, turned off be default, so that it is at least easy to keep lengthy files working? I'd rather leave it as it is, then. This option would require to maintain two versions of the parser: one without LaTeX commands and another one with them. That would defeat the whole point of removing them. The way I understand it, the new exporter will be default in 8.0, so this is the time to make some incompatible changes. Indeed. I will preserve my quota of backward-incompatible changes for other things. OK. - Carsten Regards, -- Nicolas Goaziou
Re: [O] Problem with org-entities-user
Carsten Dominik carsten.domi...@gmail.com writes: On 23.9.2012, at 10:30, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 22.9.2012, at 10:52, Nicolas Goaziou wrote: If the LaTeX command doesn't require an argument, you can always add it to `org-entities-user'. Yes, even though this is not very clean by itself. This is debatable. Entities are perfectly integrated into Org and are, by essence, multiple-back-end friendly. I only mean in the sense that entities are made to insert symbols and characters, not to execute commands. It certainly can be used to that, but this is not the intention of this mechanism. Yes, this is the essence of the mismatch. The mechanism is designed to work with entities, but the regular expression catches all LaTeX commands, whose names don't distinguish entities from other constructs AFAIK. Anyway this is a minor point. I guess it will be swept under the rug of historical reasons, after all. Maybe not. I can go along with your arguments for cleanness. Would you object to keeping this feature in as an option, turned off be default, so that it is at least easy to keep lengthy files working? I'd rather leave it as it is, then. This option would require to maintain two versions of the parser: one without LaTeX commands and another one with them. That would defeat the whole point of removing them. The way I understand it, the new exporter will be default in 8.0, so this is the time to make some incompatible changes. Indeed. I will preserve my quota of backward-incompatible changes for other things. OK. Two versions of the parser! Yikes, that doesn't sound good. Links still provide a path to handle arbitrary LaTeX commands and have them send sensible output to the different backends. They don't look so great in the Org buffer, but that is an aesthetic issue, not functional. Thanks, Nicolas, for the new LaTeX exporter. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Problem with org-entities-user
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
The only thing is: I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends. So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.
If the LaTeX command doesn't require an argument, you can always add it
to `org-entities-user'. Otherwise, you may define a macro like the
following:
#+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@
I agree that's not as convenient to set up. But once it is done, it's as
easy to use as raw commands.
Anyway this is a minor point. I guess it will be swept under the rug of
historical reasons, after all.
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
The only thing is: I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends. So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.
If the LaTeX command doesn't require an argument, you can always add it
to `org-entities-user'.
Yes, even though this is not very clean by itself.
Otherwise, you may define a macro like the
following:
#+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@
I agree that's not as convenient to set up. But once it is done, it's as
easy to use as raw commands.
True.
Anyway this is a minor point. I guess it will be swept under the rug of
historical reasons, after all.
Maybe not. I can go along with your arguments for cleanness. Would you object
to keeping this feature in as an option, turned off be default, so that it is
at least easy to keep lengthy files working?
The way I understand it, the new exporter will be default in 8.0, so this is
the time to make some incompatible changes. But if it is possible to support
this as an option, I would like it.
Regards
- Carsten
Re: [O] Problem with org-entities-user
Carsten Dominik carsten.domi...@gmail.com writes:
On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
The only thing is: I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends. So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.
If the LaTeX command doesn't require an argument, you can always add it
to `org-entities-user'.
Yes, even though this is not very clean by itself.
Otherwise, you may define a macro like the
following:
#+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@
I agree that's not as convenient to set up. But once it is done, it's as
easy to use as raw commands.
True.
Anyway this is a minor point. I guess it will be swept under the rug of
historical reasons, after all.
Maybe not. I can go along with your arguments for cleanness. Would you
object to keeping this feature in as an option, turned off be default,
so that it is at least easy to keep lengthy files working?
The way I understand it, the new exporter will be default in 8.0, so
this is the time to make some incompatible changes. But if it is
possible to support this as an option, I would like it.
Regards
- Carsten
I would like this, too. I think it would help me keep reproducible
research documents viable.
All the best,
Tom
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] Problem with org-entities-user
Hi Nicolas,
maybe first have to get clear what you mean by not accepting raw commands.
Would that mean that if I write \vspace in the buffer, the LaTeX exporter
would then give me \textbackslash{}vspace, for example, because i thinks that
I want that text to appear in the output?
- Carsten
On 19 sep. 2012, at 17:55, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
These are all valid arguments. However, I did design
Org-mode to be LaTeX-near to make sure that it becomes
easy and fast to type as a notes environment. In my mind, a user
expecting \cite{...} to work in other backends is not necessarily
a wrong expectation, and if we introduce a syntax for doing citations
in HTML, why not using the LaTeX syntax for it?
So actually, it seems I do not fully agree with your *consistency*
argument. While you are right that it is the logical and clean thing
if you view Org as a markup language created for export, it is not
necessarily the right solution for a convenience point of view.
My point is not about removing anything related to LaTeX syntax. I'm
fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
long as it really is accepted by most major export back-ends.
But I think accepting raw commands like \vspace, \hfill and al. is not
necessary (as long as there's still a way to send them to the export
back-end). We shouldn't trick users into thinking these commands will be
obeyed in any situation.
Moreover, I don't think that they belong to an easy and fast to type
notes environment.
Regards,
--
Nicolas Goaziou
- Carsten
Re: [O] Problem with org-entities-user
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
maybe first have to get clear what you mean by not accepting raw commands.
Would that mean that if I write \vspace in the buffer, the LaTeX exporter
would then give me \textbackslash{}vspace, for example, because i thinks that
I want that text to appear in the output?
Correct. This is the same when you type psomething/p in an Org
buffer and call the HTML back-end.
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
On 20 sep. 2012, at 13:57, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
maybe first have to get clear what you mean by not accepting raw commands.
Would that mean that if I write \vspace in the buffer, the LaTeX exporter
would then give me \textbackslash{}vspace, for example, because i thinks that
I want that text to appear in the output?
Correct. This is the same when you type psomething/p in an Org
buffer and call the HTML back-end.
Yes, I see what you mean and it is indeed consistent.
The only thing is: I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends. So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.
If the consent will be to remove this for cleanness and exporter
speed, maybe we could leave the code that does the protection
in an allow users to opt-in?
- Carsten
Re: [O] Problem with org-entities-user
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I'm not sure about support for \hfill{}, etc. The new latex and html
exporters pass \hfill{} through unchanged, which might be what the latex
author wants, or what the html author writing about latex commands
wants.
It would not change anything for the HTML author, since \hfill{} would
be exported as-is in any exporter. Though, it would be a less convenient
for the LaTeX author, who would have to type @@latex:\hfill{}@@.
On the other hand, I see at lest 3 reasons to remove support for such
constructs:
- consistency :: it's not possible to write raw HTML in an Org buffer,
nor raw Texinfo. LaTeX shouldn't be treated
differently.
- clarity :: Recently, an user expected the \cite{} command to work in
a backend different from LaTeX.
- ecumenism :: Removing LaTeXisms will make Org documents easier to
export to various back-ends.
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
On 19 sep. 2012, at 15:15, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I'm not sure about support for \hfill{}, etc. The new latex and html
exporters pass \hfill{} through unchanged, which might be what the latex
author wants, or what the html author writing about latex commands
wants.
It would not change anything for the HTML author, since \hfill{} would
be exported as-is in any exporter. Though, it would be a less convenient
for the LaTeX author, who would have to type @@latex:\hfill{}@@.
On the other hand, I see at lest 3 reasons to remove support for such
constructs:
- consistency :: it's not possible to write raw HTML in an Org buffer,
nor raw Texinfo. LaTeX shouldn't be treated
differently.
- clarity :: Recently, an user expected the \cite{} command to work in
a backend different from LaTeX.
- ecumenism :: Removing LaTeXisms will make Org documents easier to
export to various back-ends.
These are all valid arguments. However, I did design
Org-mode to be LaTeX-near to make sure that it becomes
easy and fast to type as a notes environment. In my mind, a user
expecting \cite{...} to work in other backends is not necessarily
a wrong expectation, and if we introduce a syntax for doing citations
in HTML, why not using the LaTeX syntax for it?
So actually, it seems I do not fully agree with your *consistency*
argument. While you are right that it is the logical and clean thing
if you view Org as a markup language created for export, it is not
necessarily the right solution for a convenience point of view.
Just my 5c, of course...
- Carsten
Re: [O] Problem with org-entities-user
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
These are all valid arguments. However, I did design
Org-mode to be LaTeX-near to make sure that it becomes
easy and fast to type as a notes environment. In my mind, a user
expecting \cite{...} to work in other backends is not necessarily
a wrong expectation, and if we introduce a syntax for doing citations
in HTML, why not using the LaTeX syntax for it?
So actually, it seems I do not fully agree with your *consistency*
argument. While you are right that it is the logical and clean thing
if you view Org as a markup language created for export, it is not
necessarily the right solution for a convenience point of view.
My point is not about removing anything related to LaTeX syntax. I'm
fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
long as it really is accepted by most major export back-ends.
But I think accepting raw commands like \vspace, \hfill and al. is not
necessary (as long as there's still a way to send them to the export
back-end). We shouldn't trick users into thinking these commands will be
obeyed in any situation.
Moreover, I don't think that they belong to an easy and fast to type
notes environment.
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
Hi,
Nicolas Goaziou n.goaz...@gmail.com writes:
My point is not about removing anything related to LaTeX syntax. I'm
fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
long as it really is accepted by most major export back-ends.
But I think accepting raw commands like \vspace, \hfill and al. is not
necessary (as long as there's still a way to send them to the export
back-end). We shouldn't trick users into thinking these commands will be
obeyed in any situation.
The contrast between \cite{...} and \hfill is interesting: the former
has an intuitive meaning in non-LaTeX backends too, so I agree
[[cite:...]] would be better here, but \hfill is a pure LaTeXism
(as are inline $...$ formulas for example.)
If we had a general syntax like [[cite:...]], then allowing the
\cite{...} latexism would be convenient but redundant, and we could
safely advise against using it.
But pure latexisms like \hfill have no intuitive equivalent in other
backends, and there is no ambiguity on what the user expects when he
uses this -- so accepting them is convenient. Forcing #+LATEX: before
these constructs would slow down editing the buffer.
So here is the Occam's razor I suggest: let's generalize as much as
possible, and let's handle as much latexisms as possible.
--
Bastien
Re: [O] Problem with org-entities-user
Aloha all,
Bastien b...@altern.org writes:
Hi,
Nicolas Goaziou n.goaz...@gmail.com writes:
My point is not about removing anything related to LaTeX syntax. I'm
fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
long as it really is accepted by most major export back-ends.
But I think accepting raw commands like \vspace, \hfill and al. is not
necessary (as long as there's still a way to send them to the export
back-end). We shouldn't trick users into thinking these commands will be
obeyed in any situation.
The contrast between \cite{...} and \hfill is interesting: the former
has an intuitive meaning in non-LaTeX backends too, so I agree
[[cite:...]] would be better here, but \hfill is a pure LaTeXism
(as are inline $...$ formulas for example.)
If we had a general syntax like [[cite:...]], then allowing the
\cite{...} latexism would be convenient but redundant, and we could
safely advise against using it.
But pure latexisms like \hfill have no intuitive equivalent in other
backends, and there is no ambiguity on what the user expects when he
uses this -- so accepting them is convenient. Forcing #+LATEX: before
these constructs would slow down editing the buffer.
So here is the Occam's razor I suggest: let's generalize as much as
possible, and let's handle as much latexisms as possible.
I wonder if the suggested razor is reasonable? Might it be better to
provide a mechanism for the user to generalize as much as possible and
have Org handle as many latexisms as needed to take fast notes?
I agree with Nicolas that having the regular expression recognize a
syntactically correct LaTeX command does not seem particularly useful if
Org isn't prepared to do the right thing in all cases. And, of course,
Org can't do the right thing in all cases because LaTeX isn't a fixed
target--there are new packages and commands introduced all the time.
Would the change to the regular expression that Nicolas proposes make it
possible to use org-entities-user more flexibly and practically as a way
to extend Org? I love the way org-entities takes care of all the export
backends *and* the display of the Org buffer. The examples that I used
to introduce this thread were unfortunately off the mark, and once I
stopped thinking LaTeX and started thinking Org I was able to
implement them perfectly with the existing Org facilities. Are there
examples of useful entities that would be made possible by Nicolas'
proposed change to the regular expression?
The other route I've found to extend Org (without messing the source
code) is links. The approach I prefer parses the description (because
Org parses the path and I don't want to mess that up). This works, but
it looks ugly in the Org buffer. I'd love to be able to hook in a
function that told Org how to display my custom link :)
All the best,
Tom
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] Problem with org-entities-user
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I'm probably doing something silly here, but can't figure it out. Using
the new LaTeX exporter, and with org-entities-user defined as below,
this:
\C14 \frac12 \Omacron
exports as:
\C14 \textonehalf{} \={O}
Why isn't my C14 entity being exported correctly?
All the best,
Tom
Value: ((U234 \\textsuperscript{234}U nil sup234/supU 234U 234U
234U)
(Th230 \\textsuperscript{230}Th nil sup230/supTh 230Th 230Th
230Th)
(C14 \\textsuperscript{14}C nil 14C 14C 14C)
(Umacron \\={U} nil #0362 U U Ū)
(Omacron \\={O} nil #0332 O O Ō)
(Imacron \\={I} nil #0298 I I Ī)
(Emacron \\={E} nil #0274 E E Ē)
(Amacron \\={A} nil #0256 A A Ā)
(umacron \\={u} nil #0363 u u ū)
(omacron \\={o} nil #0333 o o ō)
(imacron \\={i} nil #0299 i i ī)
(emacron \\={e} nil #0275 e e ē)
(amacron \\={a} nil #0257 a a ā)
(space \\ nil))
That's because numbers are not allowed in entities, except for a few
exceptions:
\\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\($\\|{}\\|[^[:alpha:]]\\)
Note that this regexp also matches LaTeX commands.
One seducing idea would be to drop support for such commands (I'm _not_
talking about math environments and snippets, but about commands like
\hfill{} or \bigskip{}). After all, if you want to write raw LaTeX in an
Org buffer, you can always use #+LATEX: or @@latex:...@@ like with any
other back-end. I see no compelling reason to keep this convenience if
it gets in the way.
It would speed-up a bit entities matching, and would allow for a relaxed
regexp (i.e. a regexp built upon already defined entities).
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I'm probably doing something silly here, but can't figure it out. Using
the new LaTeX exporter, and with org-entities-user defined as below,
this:
\C14 \frac12 \Omacron
exports as:
\C14 \textonehalf{} \={O}
Why isn't my C14 entity being exported correctly?
All the best,
Tom
Value: ((U234 \\textsuperscript{234}U nil sup234/supU
234U 234U 234U)
(Th230 \\textsuperscript{230}Th nil sup230/supTh 230Th
230Th 230Th)
(C14 \\textsuperscript{14}C nil 14C 14C 14C)
(Umacron \\={U} nil #0362 U U Ū)
(Omacron \\={O} nil #0332 O O Ō)
(Imacron \\={I} nil #0298 I I Ī)
(Emacron \\={E} nil #0274 E E Ē)
(Amacron \\={A} nil #0256 A A Ā)
(umacron \\={u} nil #0363 u u ū)
(omacron \\={o} nil #0333 o o ō)
(imacron \\={i} nil #0299 i i ī)
(emacron \\={e} nil #0275 e e ē)
(amacron \\={a} nil #0257 a a ā)
(space \\ nil))
That's because numbers are not allowed in entities, except for a few
exceptions:
\\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\($\\|{}\\|[^[:alpha:]]\\)
Note that this regexp also matches LaTeX commands.
One seducing idea would be to drop support for such commands (I'm _not_
talking about math environments and snippets, but about commands like
\hfill{} or \bigskip{}). After all, if you want to write raw LaTeX in an
Org buffer, you can always use #+LATEX: or @@latex:...@@ like with any
other back-end. I see no compelling reason to keep this convenience if
it gets in the way.
It would speed-up a bit entities matching, and would allow for a relaxed
regexp (i.e. a regexp built upon already defined entities).
Thanks Nicolas. I was confused by the exceptional numbers into thinking
they were generally allowed.
I'm not sure about support for \hfill{}, etc. The new latex and html
exporters pass \hfill{} through unchanged, which might be what the latex
author wants, or what the html author writing about latex commands
wants.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] Problem with org-entities-user
Aloha all,
I'm probably doing something silly here, but can't figure it out. Using
the new LaTeX exporter, and with org-entities-user defined as below,
this:
\C14 \frac12 \Omacron
exports as:
\C14 \textonehalf{} \={O}
Why isn't my C14 entity being exported correctly?
All the best,
Tom
Value: ((U234 \\textsuperscript{234}U nil sup234/supU 234U 234U
234U)
(Th230 \\textsuperscript{230}Th nil sup230/supTh 230Th 230Th
230Th)
(C14 \\textsuperscript{14}C nil 14C 14C 14C)
(Umacron \\={U} nil #0362 U U Ū)
(Omacron \\={O} nil #0332 O O Ō)
(Imacron \\={I} nil #0298 I I Ī)
(Emacron \\={E} nil #0274 E E Ē)
(Amacron \\={A} nil #0256 A A Ā)
(umacron \\={u} nil #0363 u u ū)
(omacron \\={o} nil #0333 o o ō)
(imacron \\={i} nil #0299 i i ī)
(emacron \\={e} nil #0275 e e ē)
(amacron \\={a} nil #0257 a a ā)
(space \\ nil))
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
