Re: [O] Let's discuss citation and Org syntax
Hi Rasmus, hi the list,
Reading this thread I've understood that the question of html export of
biblatex citations is still an open problem for org-mode developers, right
?
Thanks to the online manual and the help of the list, I have succeeded to
write a template of koma-article class which is correctly exported both in
latex and in html. But I meet the problem of exporting into html footnotes
and references.
At the moment, what is the best i.e. the more convenient solution?
My best wishes for this new year,
Jo.
2013/5/21 Rasmus ras...@gmx.us
Hi,
Now that 8.0 has shipped let's talk bibliography support. This
follows directly upon the discussion around March[1].
The essence of the thread was that some people agreed that it would be
nice to have support for citation commands build into Org (I'll
summarize in the next post). But let me first restate my own take on
the issue. IMO a nice format would be:
(*) [KEYWORD PROPERTIES]
I think we should allow for a more general approach than one just for
citation and this is a good thing (IMO).
The in-buffer display of (*) could be governed by
org-buffer-format-KEYWORD (similar to
gnus-user-format-function-LETTER) or just identity if no function is
defined. Export could be handled by org-BACKEND-KEYWORD or
org-export-KEYWORD. With officially recognized KEYWORDs something
like citation could be a 'first-class citizen'. PROPERTIES could be a
string like:
optional-keyless-entry :prop1 one :prop2 two ...
Perhaps, treatment of keyword, could even be handled by an
in-buffer Org Babel function in the spirit of e.g. reproducible
research (see below).
This would be different from Org links in that (*) is more like a
functions that allows for (i) pretty and informative display in
buffer/export and (ii) easy user extension.
I think there are many compelling use-cases for such a framework.
1. Citation: Take the keyword citetext which should be an 'official'
KEYWORD. So for instance we could have
[citetext BIBTEX-KEY :prenote note, w/comma :postnote blah].
In buffers, via org-in-buffer-format-citetext, it would be
displayed as
BIBTEX-KEY (note, w/comma, YEAR, blah)
or something similar (depending to what extend bibtex.el would be
leveraged; e.g. BIBTEX-KEY might show the author/editor key and
YEAR would also depend on parsing a bibtex file) (obviouesly,
there's some reference to a bibtex file somewhere). In LaTeX it
would be exported as
\citetext[note,w/comma][blah]{BIBTEX-KEY}
In html it might utilize some tool that understand bibtex (there's
a link to such a tool in the next post). In ASCII it could almost
use what would be displayed in the buffer.
2. MY-FUN: MY-FUN is some function that does something with some
properties, perhaps just a string (simple cases: [sc text] is used
for small caps, or mayhaps [my-treat-dna-string DNA-STRING]). I
might use it in a single file that I want to send to people or I
might just use it in my notes. Currently it's implemented via
org-emphasis-alist or as a link. Changing emphases is a hacks, and
they are hard to export with the now more robust Org syntax and
further permit little control over how they are displayed
in-buffer. Links are more flexible but lacks display control and
becomes somewhat painful with many arguments[2]. Also, MY-FUN
doesn't take a 'description'. With (*) I could simply write
[MY-FUN PROPERTIES].
Perhaps, I could even define org-BACKEND-MY-FUN in a babel block
if it's only relevant to the current file.
There's been some work and some discussion on this already, most
notably Aaron already supplied some patches towards this end[3],
but using a slightly different syntax more like the link syntax;
e.g. textcite above would look like
[[textcite:bibtex-keypre%3Dfoopost%3Dbar][whatever]]
where whatever is ignored. The state of the discussion is to some
extend summarized in the next post.
It would love to hear whether other people find something like this to
be a good idea? Would anyone find a use such a framework? Would (*)
conflict with anyone's current usage of Org? Is (*) too ambitious and
in terms of getting citation support? Is this is taking a musket to
kill a butterfly? What are the the flaws in the above.
I'm not a good (lisp) programmer, but I think I have a month off this
summer where I could work on something like the above.
Thanks for reading,
Rasmus
Footnotes:
[1] http://mid.gmane.org/20130303070635.GA12112%40panahar
[2] my citation links often look like postnote;prenote without
showing the BIBTEX-KEY or citation format.
[2] here http://mid.gmane.org/87lia0s7wi.fsf%40bzg.ath.cx
and here http://mid.gmane.org/87wqthk7vj.fsf%40gmail.com.
--
When in doubt, do it!
Re: [O] [PATCH] Table continuation strings
Hi, At Mon, 23 Dec 2013 10:09:44 +0100, Nicolas Goaziou wrote: There's a limitation: if you use Latin1 characters (e.g. when you write in French), you cannot export to text/ascii anymore. So, if, for some reason, you really need to export to ascii only, but still need to write in french, you have to be careful not to use any of these Latin1 characters, in particular in translated strings. Similarly, Japanese :ascii entries could be written using romanji. I don't know to what extent it is useful, though. Right. It is doable, but for Japanese I don't think anyone wants to do it, or at least not a ordinal usage, IMO. I'm checking exporters I use, including plain text and html, but it doesn't seems to go wrong. But I really needs some help for other back-ends. I'll post a patch for testing if anyone's interested in. Good idea. You can also set entries to :default and provide a different :latex value, if required. Ok, I've checked what I can. It seems working at least for me. Let's patch up the `org-export-dictionary' to see it breaks for others. Here is a patch to convert all Japanese entries from :utf-8 to :default. You can apply it with `git am --scissors'. - 8 - cut here - 8 - Subject: [PATCH 1/2] ox: Convert Japanese translation from utf-8 to default * lisp/ox.el (org-export-dictionary): Convert all Japanese translation from utf-8 to default. There shouldn't be much need for exporters and users to worry about the coding system of the final output. If one wants to export a Japanese document, he should already have the document with Japanese capable coding system. In that case, Emacs should be able to handle the coding system conversion form the translation table to the designated file coding system. There are two cases which I can think don't work: - all words in the document are written in romaji, and one wants romaji translations - the documents are writ en in a language which does not support Japanese character set, ie English or French, and one wants to use Japanese for non-content strings, ie TOC. These cases are too rare that we can ignore for now. --- lisp/ox.el | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index 2160826..592cc79 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -5331,7 +5331,7 @@ them. (hu :default Szerzotilde;) (is :html Houml;fundur) (it :default Autore) - (ja :html #33879;#32773; :utf-8 著者) + (ja :default 著者 :html #33879;#32773;) (nl :default Auteur) (no :default Forfatter) (nb :default Forfatter) @@ -5347,7 +5347,7 @@ them. (es :default Continúa de la página anterior) (fr :default Suite de la page précédente) (it :default Continua da pagina precedente) - (ja :utf-8 前ページからの続き) + (ja :default 前ページからの続き) (nl :default Vervolg van vorige pagina) (pt :default Continuação da página anterior) (ru :html (#1055;#1088;#1086;#1076;#1086;#1083;#1078;#1077;#1085;#1080;#1077;) @@ -5357,7 +5357,7 @@ them. (es :default Continúa en la siguiente página) (fr :default Suite page suivante) (it :default Continua alla pagina successiva) - (ja :utf-8 次ページに続く) + (ja :default 次ページに続く) (nl :default Vervolg op volgende pagina) (pt :default Continua na página seguinte) (ru :html (#1055;#1088;#1086;#1076;#1086;#1083;#1078;#1077;#1085;#1080;#1077; #1089;#1083;#1077;#1076;#1091;#1077;#1090;) @@ -5374,7 +5374,7 @@ them. (hu :html Daacute;tum) (is :default Dagsetning) (it :default Data) - (ja :html #26085;#20184; :utf-8 日付) + (ja :default 日付 :html #26085;#20184;) (nl :default Datum) (no :default Dato) (nb :default Dato) @@ -5403,7 +5403,7 @@ them. (de :default Abbildung) (es :default Figura) (et :default Joonis) - (ja :html #22259; :utf-8 図) + (ja :default 図 :html #22259;) (no :default Illustrasjon) (nb :default Illustrasjon) (nn :default Illustrasjon) @@ -5416,7 +5416,7 @@ them. (es :default Figura %d:) (et :default Joonis %d:) (fr :default Figure %d : :html Figurenbsp;%dnbsp;:) - (ja :html #22259;%d: :utf-8 図%d: ) + (ja :default 図%d: :html #22259;%d: ) (no :default Illustrasjon %d) (nb :default Illustrasjon %d) (nn :default Illustrasjon %d) @@ -5436,7 +5436,7 @@ them. (hu :html Laacute;bjegyzet) (is :html Aftanmaacute;lsgreinar) (it :html Note a piegrave; di pagina) - (ja :html #33050;#27880; :utf-8 脚注) + (ja :default 脚注 :html #33050;#27880;) (nl :default Voetnoten) (no :default Fotnoter) (nb :default Fotnoter) @@ -5497,7 +5497,7 @@ them. (es :default Tabla) (et :default Tabel) (fr :default Tableau) - (ja :html #34920; :utf-8 表) + (ja :default 表 :html #34920;) (ru :html #1058;#1072;#1073;#1083;#1080;#1094;#1072; :utf-8 Таблица)
Re: [O] org-sort-agenda-notime-is-late is mishandled in org-cmp-ts
On 12/01/2013 12:12 PM, Michael Crouch wrote: Bug report for 8.2.3c: When org-agenda-sorting-strategy is set to deadline-up (or similar values), the Global Todo list always places non-timestamped entries at the beginning, even when org-sort-agenda-notime-is-late is true. This is inconsistent with the behavior when org-agenda-sorting-strategy is time-up. I believe the problem is that the org-cmp-ts function copied a line from the older org-cmp-time function: (def (if org-sort-agenda-notime-is-late 9901 -1)) 9901 is later than all times of day, but not later than all date/time stamps. I get this too on org 8.2.4. Replacing 9901 with most-positive-fixnum fixes the problem. Michael Hoffman
[O] Emacs: unifying citations between html and latex in org-mode - Stack Overflow
http://stackoverflow.com/questions/7268797/emacs-unifying-citations-between-html-and-latex-in-org-mode Hello the list, Reading this page and the last reply, I've tried to use ebib in order to get both html references and latex references as well. It seems it works correctly in latex with ebib + biblatex, but in html, nothing works correctly vis-à-vis references. Can someone could help me to understand how using ebib in order to get references in latex files as well as in html files? A simple example could be helpful. Many thanks, Jo.
Re: [O] Let's discuss citation and Org syntax
Take a look at ox-bibtex.el in contrib [1], which adds support for
bibtex citations. The commentary at the top of that file explains the
usage, but in brief, ox-bibtex adds cite: links which will export to
HTML, ASCII and LaTeX (using bibtex2html [2] for HTML export, and pandoc
[3] for ASCII export).
For example, I've used ox-bibtex to write this Org file [4], which
exports to this HTML [5], as well as LaTeX.
Best,
Joseph Vidal-Rosset joseph.vidal.ros...@gmail.com writes:
Hi Rasmus, hi the list,
Reading this thread I've understood that the question of html export of
biblatex citations is still an open problem for org-mode developers, right
?
Thanks to the online manual and the help of the list, I have succeeded to
write a template of koma-article class which is correctly exported both in
latex and in html. But I meet the problem of exporting into html footnotes
and references.
At the moment, what is the best i.e. the more convenient solution?
My best wishes for this new year,
Jo.
2013/5/21 Rasmus ras...@gmx.us
Hi,
Now that 8.0 has shipped let's talk bibliography support. This
follows directly upon the discussion around March[1].
The essence of the thread was that some people agreed that it would be
nice to have support for citation commands build into Org (I'll
summarize in the next post). But let me first restate my own take on
the issue. IMO a nice format would be:
(*) [KEYWORD PROPERTIES]
I think we should allow for a more general approach than one just for
citation and this is a good thing (IMO).
The in-buffer display of (*) could be governed by
org-buffer-format-KEYWORD (similar to
gnus-user-format-function-LETTER) or just identity if no function is
defined. Export could be handled by org-BACKEND-KEYWORD or
org-export-KEYWORD. With officially recognized KEYWORDs something
like citation could be a 'first-class citizen'. PROPERTIES could be a
string like:
optional-keyless-entry :prop1 one :prop2 two ...
Perhaps, treatment of keyword, could even be handled by an
in-buffer Org Babel function in the spirit of e.g. reproducible
research (see below).
This would be different from Org links in that (*) is more like a
functions that allows for (i) pretty and informative display in
buffer/export and (ii) easy user extension.
I think there are many compelling use-cases for such a framework.
1. Citation: Take the keyword citetext which should be an 'official'
KEYWORD. So for instance we could have
[citetext BIBTEX-KEY :prenote note, w/comma :postnote blah].
In buffers, via org-in-buffer-format-citetext, it would be
displayed as
BIBTEX-KEY (note, w/comma, YEAR, blah)
or something similar (depending to what extend bibtex.el would be
leveraged; e.g. BIBTEX-KEY might show the author/editor key and
YEAR would also depend on parsing a bibtex file) (obviouesly,
there's some reference to a bibtex file somewhere). In LaTeX it
would be exported as
\citetext[note,w/comma][blah]{BIBTEX-KEY}
In html it might utilize some tool that understand bibtex (there's
a link to such a tool in the next post). In ASCII it could almost
use what would be displayed in the buffer.
2. MY-FUN: MY-FUN is some function that does something with some
properties, perhaps just a string (simple cases: [sc text] is used
for small caps, or mayhaps [my-treat-dna-string DNA-STRING]). I
might use it in a single file that I want to send to people or I
might just use it in my notes. Currently it's implemented via
org-emphasis-alist or as a link. Changing emphases is a hacks, and
they are hard to export with the now more robust Org syntax and
further permit little control over how they are displayed
in-buffer. Links are more flexible but lacks display control and
becomes somewhat painful with many arguments[2]. Also, MY-FUN
doesn't take a 'description'. With (*) I could simply write
[MY-FUN PROPERTIES].
Perhaps, I could even define org-BACKEND-MY-FUN in a babel block
if it's only relevant to the current file.
There's been some work and some discussion on this already, most
notably Aaron already supplied some patches towards this end[3],
but using a slightly different syntax more like the link syntax;
e.g. textcite above would look like
[[textcite:bibtex-keypre%3Dfoopost%3Dbar][whatever]]
where whatever is ignored. The state of the discussion is to some
extend summarized in the next post.
It would love to hear whether other people find something like this to
be a good idea? Would anyone find a use such a framework? Would (*)
conflict with anyone's current usage of Org? Is (*) too ambitious and
in terms of getting citation support? Is this is taking a musket to
kill a butterfly? What are the the flaws in the above.
I'm not a good (lisp) programmer, but I think I have a month off this
summer where I could work on something like the
Re: [O] Emacs: unifying citations between html and latex in org-mode - Stack Overflow
Joseph Vidal-Rosset joseph.vidal.ros...@gmail.com writes: http://stackoverflow.com/questions/7268797/emacs-unifying-citations-between-html-and-latex-in-org-mode Hello the list, Reading this page and the last reply, I've tried to use ebib in order to get both html references and latex references as well. It seems it works correctly in latex with ebib + biblatex, but in html, nothing works correctly vis-à-vis references. Can someone could help me to understand how using ebib in order to get references in latex files as well as in html files? A simple example could be helpful. Many thanks, Jo. See my reply in the Let's discuss citation and Org syntax thread. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] Problem updating Org
I update org daily (at least I try to) using make-update2 in Cygwin git. Today I received the following message - - - - begin message - - - - rm -f git checkout Dcontrib/lisp/ob-groovy.el Mcontrib/lisp/ob-oz.el Mcontrib/lisp/org-mac-link.el Mlisp/ob-C.el Dlisp/ob-J.el Mlisp/ob-latex.el Mlisp/ob-maxima.el Mlisp/org-agenda.el Mlisp/org-element.el Mlisp/org-habit.el Mlisp/org-inlinetask.el Mlisp/org-table.el Mlisp/org.el Mlisp/ox-html.el Mlisp/ox-latex.el Mlisp/ox-texinfo.el Mlisp/ox.el Mtesting/lisp/test-ob.el Mtesting/lisp/test-ox.el Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded. git remote update Fetching origin From git://orgmode.org/org-mode 13bb116..6e51188 master - origin/master 1a3591c..03ce57e maint - origin/maint git pull error: Your local changes to the following files would be overwritten by merge: lisp/ox-html.el Please, commit your changes or stash them before you can merge. Aborting Updating e23bbda..6e51188 mk/targets.mk:111: recipe for target 'up0' failed make: *** [up0] Error 1 - - - - end message - - - - I have not opened ox-html.el and I do not export to html. (I do export to LaTeX.) GNU Emacs 24.3.1 (i386-mingw-nt6.0.6002) of 2013-03-17 on MARVIN Org-mode version 8.2.4 (release_8.2.4-357-gda05ab.dirty @ c:/cygwin/home/owner/.elisp/org-mode/lisp/) Charlie Millar --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: [O] Problem updating Org
Try checking out the version already in HEAD: git checkout -- lisp/ox-html.el Then pull again. Nathan DeGruchy nat...@degruchy.org On Jan 2, 2014, at 1:55 PM, Charles Millar mill...@verizon.net wrote: I update org daily (at least I try to) using make-update2 in Cygwin git. Today I received the following message - - - - begin message - - - - rm -f git checkout Dcontrib/lisp/ob-groovy.el Mcontrib/lisp/ob-oz.el Mcontrib/lisp/org-mac-link.el Mlisp/ob-C.el Dlisp/ob-J.el Mlisp/ob-latex.el Mlisp/ob-maxima.el Mlisp/org-agenda.el Mlisp/org-element.el Mlisp/org-habit.el Mlisp/org-inlinetask.el Mlisp/org-table.el Mlisp/org.el Mlisp/ox-html.el Mlisp/ox-latex.el Mlisp/ox-texinfo.el Mlisp/ox.el Mtesting/lisp/test-ob.el Mtesting/lisp/test-ox.el Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded. git remote update Fetching origin From git://orgmode.org/org-mode 13bb116..6e51188 master - origin/master 1a3591c..03ce57e maint - origin/maint git pull error: Your local changes to the following files would be overwritten by merge: lisp/ox-html.el Please, commit your changes or stash them before you can merge. Aborting Updating e23bbda..6e51188 mk/targets.mk:111: recipe for target 'up0' failed make: *** [up0] Error 1 - - - - end message - - - - I have not opened ox-html.el and I do not export to html. (I do export to LaTeX.) GNU Emacs 24.3.1 (i386-mingw-nt6.0.6002) of 2013-03-17 on MARVIN Org-mode version 8.2.4 (release_8.2.4-357-gda05ab.dirty @ c:/cygwin/home/owner/.elisp/org-mode/lisp/) Charlie Millar --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: [O] Let's discuss citation and Org syntax
Great ! Many thanks Eric. I see also that I have to forget gmail in order
to definitely adopt gnus ! :)
I will be back on the list to say thank you again , to all of you.
Best wishes,
Jo.
2014/1/2 Eric Schulte schulte.e...@gmail.com
Take a look at ox-bibtex.el in contrib [1], which adds support for
bibtex citations. The commentary at the top of that file explains the
usage, but in brief, ox-bibtex adds cite: links which will export to
HTML, ASCII and LaTeX (using bibtex2html [2] for HTML export, and pandoc
[3] for ASCII export).
For example, I've used ox-bibtex to write this Org file [4], which
exports to this HTML [5], as well as LaTeX.
Best,
Joseph Vidal-Rosset joseph.vidal.ros...@gmail.com writes:
Hi Rasmus, hi the list,
Reading this thread I've understood that the question of html export of
biblatex citations is still an open problem for org-mode developers,
right
?
Thanks to the online manual and the help of the list, I have succeeded to
write a template of koma-article class which is correctly exported both
in
latex and in html. But I meet the problem of exporting into html
footnotes
and references.
At the moment, what is the best i.e. the more convenient solution?
My best wishes for this new year,
Jo.
2013/5/21 Rasmus ras...@gmx.us
Hi,
Now that 8.0 has shipped let's talk bibliography support. This
follows directly upon the discussion around March[1].
The essence of the thread was that some people agreed that it would be
nice to have support for citation commands build into Org (I'll
summarize in the next post). But let me first restate my own take on
the issue. IMO a nice format would be:
(*) [KEYWORD PROPERTIES]
I think we should allow for a more general approach than one just for
citation and this is a good thing (IMO).
The in-buffer display of (*) could be governed by
org-buffer-format-KEYWORD (similar to
gnus-user-format-function-LETTER) or just identity if no function is
defined. Export could be handled by org-BACKEND-KEYWORD or
org-export-KEYWORD. With officially recognized KEYWORDs something
like citation could be a 'first-class citizen'. PROPERTIES could be a
string like:
optional-keyless-entry :prop1 one :prop2 two ...
Perhaps, treatment of keyword, could even be handled by an
in-buffer Org Babel function in the spirit of e.g. reproducible
research (see below).
This would be different from Org links in that (*) is more like a
functions that allows for (i) pretty and informative display in
buffer/export and (ii) easy user extension.
I think there are many compelling use-cases for such a framework.
1. Citation: Take the keyword citetext which should be an 'official'
KEYWORD. So for instance we could have
[citetext BIBTEX-KEY :prenote note, w/comma :postnote blah].
In buffers, via org-in-buffer-format-citetext, it would be
displayed as
BIBTEX-KEY (note, w/comma, YEAR, blah)
or something similar (depending to what extend bibtex.el would be
leveraged; e.g. BIBTEX-KEY might show the author/editor key and
YEAR would also depend on parsing a bibtex file) (obviouesly,
there's some reference to a bibtex file somewhere). In LaTeX it
would be exported as
\citetext[note,w/comma][blah]{BIBTEX-KEY}
In html it might utilize some tool that understand bibtex (there's
a link to such a tool in the next post). In ASCII it could almost
use what would be displayed in the buffer.
2. MY-FUN: MY-FUN is some function that does something with some
properties, perhaps just a string (simple cases: [sc text] is used
for small caps, or mayhaps [my-treat-dna-string DNA-STRING]). I
might use it in a single file that I want to send to people or I
might just use it in my notes. Currently it's implemented via
org-emphasis-alist or as a link. Changing emphases is a hacks, and
they are hard to export with the now more robust Org syntax and
further permit little control over how they are displayed
in-buffer. Links are more flexible but lacks display control and
becomes somewhat painful with many arguments[2]. Also, MY-FUN
doesn't take a 'description'. With (*) I could simply write
[MY-FUN PROPERTIES].
Perhaps, I could even define org-BACKEND-MY-FUN in a babel block
if it's only relevant to the current file.
There's been some work and some discussion on this already, most
notably Aaron already supplied some patches towards this end[3],
but using a slightly different syntax more like the link syntax;
e.g. textcite above would look like
[[textcite:bibtex-keypre%3Dfoopost%3Dbar][whatever]]
where whatever is ignored. The state of the discussion is to some
extend summarized in the next post.
It would love to hear whether other people find something like this to
be a good idea? Would anyone
Re: [O] [PATCH] Table continuation strings
Hi, At Thu, 02 Jan 2014 17:15:17 +0900, Yasushi SHOJI wrote: At Mon, 23 Dec 2013 10:09:44 +0100, Nicolas Goaziou wrote: There's a limitation: if you use Latin1 characters (e.g. when you write in French), you cannot export to text/ascii anymore. So, if, for some reason, you really need to export to ascii only, but still need to write in french, you have to be careful not to use any of these Latin1 characters, in particular in translated strings. Similarly, Japanese :ascii entries could be written using romanji. I don't know to what extent it is useful, though. Right. It is doable, but for Japanese I don't think anyone wants to do it, or at least not a ordinal usage, IMO. I'm checking exporters I use, including plain text and html, but it doesn't seems to go wrong. But I really needs some help for other back-ends. I'll post a patch for testing if anyone's interested in. Good idea. You can also set entries to :default and provide a different :latex value, if required. Ok, I've checked what I can. It seems working at least for me. Let's patch up the `org-export-dictionary' to see it breaks for others. Here is a patch to convert all Japanese entries from :utf-8 to :default. You can apply it with `git am --scissors'. And here is a patch for the rest of Japanese translation strings. - 8 - cut here - 8 - Subject: [PATCH 2/2] ox: Add new Japanese translation strings * lisp/ox.el (org-export-dictionary): Add new Japanese translation strings. A few strings in `org-export-dictionary' didn't have Japanese translations. So, I just added. --- lisp/ox.el | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lisp/ox.el b/lisp/ox.el index 592cc79..ed7afe5 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -5391,6 +5391,7 @@ them. (es :html Ecuacioacute;n :default Ecuación) (et :html V#245;rrand :utf-8 Võrrand) (fr :ascii Equation :default Équation) + (ja :default 方程式) (no :default Ligning) (nb :default Ligning) (nn :default Likning) @@ -5454,6 +5455,7 @@ them. (es :default Indice de Listados de programas) (et :default Loendite nimekiri) (fr :default Liste des programmes) + (ja :default ソースコード目次) (no :default Dataprogrammer) (nb :default Dataprogrammer) (ru :html #1057;#1087;#1080;#1089;#1086;#1082; #1088;#1072;#1089;#1087;#1077;#1095;#1072;#1090;#1086;#1082; @@ -5465,6 +5467,7 @@ them. (es :default Indice de tablas) (et :default Tabelite nimekiri) (fr :default Liste des tableaux) + (ja :default 表目次) (no :default Tabeller) (nb :default Tabeller) (nn :default Tabeller) @@ -5478,6 +5481,7 @@ them. (es :default Listado de programa %d) (et :default Loend %d) (fr :default Programme %d : :html Programmenbsp;%dnbsp;:) + (ja :default ソースコード%d:) (no :default Dataprogram %d) (nb :default Dataprogram %d) (ru :html #1056;#1072;#1089;#1087;#1077;#1095;#1072;#1090;#1082;#1072; %d.: @@ -5489,6 +5493,7 @@ them. (es :default vea seccion %s) (et :html Vaata peat#252;kki %s :utf-8 Vaata peatükki %s) (fr :default cf. section %s) + (ja :default セクション %s を参照) (ru :html #1057;#1084;. #1088;#1072;#1079;#1076;#1077;#1083; %s :utf-8 См. раздел %s) (zh-CN :html #21442;#35265;#31532;%s#33410; :utf-8 参见第%s节)) @@ -5545,6 +5550,7 @@ them. (es :default referencia desconocida) (et :default Tundmatu viide) (fr :ascii Destination inconnue :default Référence inconnue) + (ja :default 不明な参照先) (ru :html #1053;#1077;#1080;#1079;#1074;#1077;#1089;#1090;#1085;#1072;#1103; #1089;#1089;#1099;#1083;#1082;#1072; :utf-8 Неизвестная ссылка) (zh-CN :html #26410;#30693;#24341;#29992; :utf-8 未知引用))) -- 1.8.5.2 -- yashi
Re: [O] mixed orgmode installation
Achim Gratz Stromeko at nexgo.de writes: John Hendy writes: Then again, is Worg saying that if `M-x org-version` outputs the correct answer... we're all set and there's nothing to worry about? The output of org-version is determined essentially by checking for two files from the installation and comparing where they would be loaded from. This catches the most common problems, but certainly not all. In particular, it won't see when the load-path has been changed after some parts of Org have already been loaded from someplace else (but org-reload will give a warning for this case). Regards, Achim. If I byte compile a file, I get this message: In org-jekyll-publish-to-html: ox-jekyll.el:280:4:Warning: org-publish-org-to called with 5 arguments, but accepts only 4 This is because my installation is pointing to the emacs default version rather than my version from git. If I do C-h f and look up this function, I get pointed to the emacs default version. However, if I do org-version, I get the proper new version. However, if I do list-load-path-shadows, I can verify that org-publish is not shadowed, and that's probably due to the fact that the new file is called ox-publish. How do I fix this??? I've tried
Re: [O] [RFC] ox-ascii.el: fixing variable width character handling
Hi Nicolas, Took me a while to get back to this. At Sun, 10 Nov 2013 14:09:48 +0100, Nicolas Goaziou wrote: While I came up with the following experimental patch, I have a few questions: - What is the lisp idiom to handle type error? In the following patch, I've created a new wrapper function `org-ascii--string-width', it's a thin wrapper with if-then-else. I thought placing if-then-else clause in the original place clutter the code. You only use `org-ascii--string-width' in two places. You can write (string-width (or contents )) instead, it will be less intrusive. Thanks! I've used this idiom in the attached patch. BTW, what about `org-ascii--current-text-width'? This function also uses `length' instead of `string-width'. I've checked all occurences of `length' in ox-ascii.el. It turns out that only two were used *not* for width calculation. - If wrapped string-width is good idea, would it be also a good idea to merge it with `org-string-width' in org.el? Because it is not ox-ascii specific. The current `org-string-width' does not handle nil, neither. That would be a good idea, but in a distinct patch. Will do when I have time. - The width of the underline for headlines should be checked with string-width. As defined in Unicode Standard Annex #41[1], character width is environment dependent. So, the calculation of character width at export time might not be sufficient enough. We can check to see the exported document contains cjk chars more than some thresholds or not, I haven't gone that far. I don't think there's much to do about it. Hopefully one can always re-export the Org file in its own environment. - Does anyone using ox-ascii.el depends on the clipped marker `=' for fixed width columns? I thought `...' would be much readable. I have no opinion about it. Though, if we switch to ..., we also need to provide the utf-8 equivalent when using this charset. Will do next time. - BTW, while looking at table handling, I noticed fixed column width doesn't work with the code at the current git HEAD. That's because width calculation is mixed with `length' and `string-width', and pass out-of-range arguments to `add-text-properties'. I guess your patch also fixed that. Ok here is new one. I've been using for a while. Hope it works for others. - 8 - 8 - 8 - 8 - Subject: [PATCH] ox-ascii: Convert `length' to `string-width' where appropriate * lisp/ox-ascii.el (org-ascii--current-text-width): Convert `length' to `string-width'. (org-ascii--build-title): Likewise. (org-ascii--build-toc): Likewise. (org-ascii--list-listings): Likewise. (org-ascii--list-tables): Likewise. (org-ascii-template--document-title): Likewise. (org-ascii-inner-template): Likewise. (org-ascii-format-inlinetask-default): Likewise. (org-ascii-format-inlinetask-default):Likewise. (org-ascii-item): Likewise. (org-ascii--table-cell-width): Likewise. (org-ascii-table-cell): Likewise. (org-ascii--current-text-width): Likewise. I've checked all occurrences of the function `length' in ox-ascii.el. It turns out that the most of them are calculating the width of given string. To support fullwidth characters, we better use `string-width' instead of `length'. Some characters in UCS are categorized as East Asian Ambiguous[1]. The return value of `string-width' with those characters depends on how Emacs is setup. We leave those ambiguous character handling to Emacs. Two usages of `length' in `ox-ascii.el' were left as-is, because those were used for: - bullet position calculation in `org-ascii-headline', and - cell position calculation in `org-ascii--table-cell-width'. [1]: http://www.unicode.org/reports/tr11/#Ambiguous --- lisp/ox-ascii.el | 73 1 file changed, 42 insertions(+), 31 deletions(-) diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index b278ab6..5291a2d 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -527,15 +527,18 @@ INFO is a plist used as a communication channel. ;; the list and current item bullet's length. Also ;; remove checkbox length, and tag length (for ;; description lists) or bullet length. -(let ((struct (org-element-property :structure parent-item)) - (beg-item (org-element-property :begin parent-item))) +(let* ((struct (org-element-property :structure parent-item)) + (beg-item (org-element-property :begin parent-item)) + (tag (org-list-get-tag beg-item struct)) + (bullet (org-list-get-bullet beg-item struct))) (+ (- (org-list-get-ind beg-item struct) (org-list-get-ind (org-list-get-top-point struct) struct)) -
