[O] Biblatex and Org [was: [OT] Don't use BibTeX!]
Hi Thomas, "Thomas S. Dye" writes: > If you're just starting out, I encourage you to use biblatex. It will > take a few minutes to make the switch and then you won't have to think > about it. A biblatex site you find googling should tell you what you > need to know. Well, that's the trouble...although I'm still probably a couple of years from wanting to publish anything, I'm not just starting out. I use Org to keep track of my readings and citation information, and then export this data to .bib on the fly using functions from org-bibtex. I have quite a few readings recorded this way. I described my setup a while ago here: http://thread.gmane.org/gmane.emacs.orgmode/78983/focus=79016 So I'm not really tied to BibTeX, but I *am* relying on org-bibtex. I'm certainly willing to switch to biblatex if that's going to save me a lot of time or headache in the future. What I need to know is what's required to switch over the parts of my setup that originate in Org. Correct me if I'm wrong, but it looks like I can keep using this part of my setup, because biblatex supports the .bib format: #+BEGIN_QUOTE biblatex can be used with or without BibTeX the program since its default backend Biber uses fully supports the BibTeX file format (bib) and users should be able to move to biblatex will little or no changes to their BibTeX data files when using Biber as a backend. (from section 2 of the biblatex manual at http://mirror.hmc.edu/ctan/macros/latex/contrib/biblatex/doc/biblatex.pdf) #+END_QUOTE So it looks like switching to biblatex is just a matter of changing my compilation process and the bibliography commands in my documents. Does that sound right? Thanks for your advice! Best, Richard
Re: [O] [OT] Don't use BibTeX!
Hi Richard, If you're just starting out, I encourage you to use biblatex. It will take a few minutes to make the switch and then you won't have to think about it. A biblatex site you find googling should tell you what you need to know. There are several differences, but a big one is that biblatex supports a much more informative database and so can handle almost any bibliographic situation. For those of us with large legacy bibtex databases, the database differences are a real issue, but for someone just getting started this isn't such a consideration. Biblatex is the wave of the future in the LaTeX world. hth, Tom Richard Lawrence writes: > Marcin Borkowski writes: > >> Dnia 2014-04-05, o godz. 09:46:39 >> Richard Lawrence napisał(a): >> >>> I have sometimes run into problems (mostly with BibTeX) when the >> >> Sorry for being off-topic, but I can't resist: *please* *don't* *use* >> *BibTeX*. On the scale of "tools that solve problems" vs. "tools that >> create problems" (cf. http://xkcd.com/1343/ ;)), it is located on the >> far right. > > Now now, the first sentence on http://www.bibtex.org/Using/ says that to > use Bibtex, "Just create a plain text file and apply what has been > explained in section BibTeX File Format."! It doesn't say anything > about how to use the manual. ;) > >> (For instance, to be able to customize its bibliography style, you >> could (a) give up, (b) use some user-friendly (or not) front-end, >> having less power than BibTeX itself (obviously!), or (c) learn >> BibTeX's own, very peculiar, stack-based ad-hoc language grown to >> describe bibliography styles. Not good. Also, if you're unlucky and >> you write in some non-English language, well, you're unlucky with >> BibTeX, especially if e.g. your name starts with a non-Latin letter. >> Etc.) > > I mostly use bibtex because that's what I learned, and none of these > issues apply to me at this (early) stage in my career. I have no need > for customizing my bibliography style. I suppose this will matter more > to me when I start sending things out for publication, but at this point > I'm still just trying to write the damn dissertation... > >> Use biblatex instead. It's more modern, it's being supported, it >> knowns that there exist things like UTF-8 and non-English languages, >> it supports more citation styles etc. > > I have heard this, but haven't investigated biblatex because I haven't > yet really felt the need. > > I keep my reading list and notes in Org, then export them to a .bib file > using org-bibtex. Does biblatex support .bib files? If not, what would > be required to support a biblatex-based workflow in Org? > > Thanks for keeping me honest! > > Best, > Richard > > > -- Thomas S. Dye http://www.tsdye.com
Re: [O] Prepare release 8.2.6
On Sat, Apr 5, 2014 at 3:18 PM, Nicolas Goaziou wrote:
> Hello,
>
> "R. Michael Weylandt" writes:
>
>>> 1) Tell Emacs not to break inline source blocks when filling paragraphs:
>
> I suggest not to use `org-in-regexp' here but `org-element-context'.
I'm not as familiar with org-element-context, but I think the attached
is what you had in mind.
> Besides inline source blocks, ISTR there was other places where filling
> was inappropriate (verbatim, code, export snippet, macro...). A single
> `org-element-context' will find them all.
Verbatim seems to work over multiple lines so I've left them out.
Macros and inline source blocks don't so I've included them. Not sure
what other elements to look at:
>
> Another option for the problem at hand is to simply remove newline
> characters in inline source blocks before executing them.
>
That might be better but would require a bit more work: at present,
inline source blocks can't extend over multiple lines so org wouldn't
recognize a construct like
src_python[:exports results]{1 + 2 +
3 + 4}
as an inline source block in the first place. Looking at
org-inline-src-block-regexp I'm not sure why though.
Patch also attached to improve link handling
Michael
0001-org.el-Don-t-fill-on-inline-source-blocks-or-macros.patch
Description: Binary data
0002-org.el-Remove-and-from-org-link-escape-chars.patch
Description: Binary data
Re: [O] Kill ring contains non-killed output after an export
Konstantin Kliakhandler writes: > Richard Lawrence writes: >> The behavior you are seeing is as expected, though I agree that this >> behavior is usually not all that useful. See the variable >> org-export-copy-to-kill-ring if you want to turn it off. > > Thanks! Now the export is much more usable for me. Out of curiousity, > what is the use case of the default behavior? I have no idea...if I had to take a guess, it would be that when exporting a region as a LaTeX *snippet*, such as a table, it could be useful to yank the resulting code into another buffer. But I really can't think of a situation where yanking a whole .tex document from the kill ring is preferable to just visiting the exported file/buffer. So I'm all for changing the default behavior. Best, Richard
Re: [O] [OT] Don't use BibTeX!
Marcin Borkowski writes: > Dnia 2014-04-05, o godz. 09:46:39 > Richard Lawrence napisał(a): > >> I have sometimes run into problems (mostly with BibTeX) when the > > Sorry for being off-topic, but I can't resist: *please* *don't* *use* > *BibTeX*. On the scale of "tools that solve problems" vs. "tools that > create problems" (cf. http://xkcd.com/1343/ ;)), it is located on the > far right. Now now, the first sentence on http://www.bibtex.org/Using/ says that to use Bibtex, "Just create a plain text file and apply what has been explained in section BibTeX File Format."! It doesn't say anything about how to use the manual. ;) > (For instance, to be able to customize its bibliography style, you > could (a) give up, (b) use some user-friendly (or not) front-end, > having less power than BibTeX itself (obviously!), or (c) learn > BibTeX's own, very peculiar, stack-based ad-hoc language grown to > describe bibliography styles. Not good. Also, if you're unlucky and > you write in some non-English language, well, you're unlucky with > BibTeX, especially if e.g. your name starts with a non-Latin letter. > Etc.) I mostly use bibtex because that's what I learned, and none of these issues apply to me at this (early) stage in my career. I have no need for customizing my bibliography style. I suppose this will matter more to me when I start sending things out for publication, but at this point I'm still just trying to write the damn dissertation... > Use biblatex instead. It's more modern, it's being supported, it > knowns that there exist things like UTF-8 and non-English languages, > it supports more citation styles etc. I have heard this, but haven't investigated biblatex because I haven't yet really felt the need. I keep my reading list and notes in Org, then export them to a .bib file using org-bibtex. Does biblatex support .bib files? If not, what would be required to support a biblatex-based workflow in Org? Thanks for keeping me honest! Best, Richard
Re: [O] Insert UUID with org-insert-todo-heading
this kind of does what you want: #+BEGIN_SRC emacs-lisp (require 'org-id) (add-hook 'org-insert-heading-hook #'(lambda () (org-entry-put (point) "UUID" (org-id-uuid #+END_SRC at least it works if you use the menu to insert a new heading. it does not work if you type the heading by hand. org-insert-heading-hook you can probably write a little function that sets a uuid property. John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Sun, Apr 6, 2014 at 2:21 PM, Esben Stien wrote: > I'm using the following to have a CREATED field in the PROPERTIES field > of a TODO: > > ;; advice org-insert-todo-heading to insert a created timestamp using > org-expiry > (defadvice org-insert-todo-heading (after mrb/created-timestamp-advice > activate) > "Insert a CREATED property using org-expiry.el for TODO entries" > (mrb/insert-created-timestamp) > ) > (ad-activate 'org-insert-todo-heading) > > So, I get: > > TODO > :PROPERTIES: > :CREATED: [2014-04-06 sø. 20:11] > :END: > > Is there any way to insert a UUID as well?, like: > > TODO > :PROPERTIES: > :CREATED: [2014-04-06 sø. 20:11] > :UUID: 70f273b5-8bce-315f-6f31-6d9ec9a8b739 > :END: > > Any pointers as to how I can achieve this? > > -- > Esben Stien is b0ef@e s a > http://www. s tn m > irc://irc. b - i . e/%23contact >sip:b0ef@ e e >jid:b0ef@n n > >
Re: [O] Export arrays for 'sh' code blocks when using bash
Hi Eric,
Please find attached a new patch that contains the same changes of the
ob-shell.el exporter as before, but also contains unit tests for checking
that it works.
Let me know if you need some changes in there, and how the google-wide
copyright issues comes along. My information came from Chris DiBona (our
master of open-source licenses), is this helps to find the relevant
documents.
Thanks,
Pascal
On Sat, Mar 29, 2014 at 8:37 PM, Eric Schulte wrote:
> Thanks for making these changes. Once they're in and Bastien figures
> out how the google-wide copyright attribution works we should be good to
> go.
>
> Thanks!
>
> Pascal Fleury writes:
>
> > Hi Eric, see comments inline.
> >
> >
> > On Thu, Mar 27, 2014 at 6:43 PM, Eric Schulte >wrote:
> >
> >> Hi Pascal,
> >>
> >> This looks like a good patch. If I could make three changes/requests.
> >>
> >>
> > Thanks, I am happy to see it makes sense.
> >
> >
> >> 1. This patch should also work for "begin_src bash" code blocks. After
> >>a very quick glance it doesn't appear to.
> >>
> >> I have actually tried this with the latest org-mode release (8.2.5h) and
> > it did plainly not accept 'begin_src bash'. Maybe that's new with the
> > ob-shell.el (I noticed it has been renamed :-)
> >
> >
> >> 2. Could you include one or two tests ensuring that this patch does what
> >>it intends with bash code blocks, and does not affect code blocks
> >>executed with bin/sh?
> >>
> >
> > Will do, seeing it has some traction.
> >
> >
> >>
> >> 3. Large contributions like this require some FSF paperwork. Please see
> >>the following page for information on requirements to contribute.
> >>
> >>
> > I checked internally, and apparently, Google has already such a signed
> > document. It would run on the same document, as I am a google employee.
> >
> >
> >>http://orgmode.org/worg/org-contribute.html
> >>
> >> Thanks, and I look forward to seeing this merged into Org-mode!
> >> Eric
> >>
> >> Pascal Fleury writes:
> >>
> >> > Hello,
> >> >
> >> > I'dl like to propose a patch for inclusion into org-mode (ob-shell.el
> in
> >> > particular).
> >> >
> >> > *TL;DR:* use arrays and associative arrays when exporting variables to
> >> bash
> >> > in 'sh' code blocks.
> >> >
> >> > *Details:*
> >> > When variables are defined in a 'sh' code block, they are exported as
> >> > strings. when the variable itself is an array or a table, then we
> simply
> >> > get a shell variable that contains the list of all values in a
> >> > non-structured form. E.g.
> >> >
> >> > #+NAME: my_list
> >> > | one |
> >> > | two |
> >> > | three |
> >> >
> >> > #+NAME: experiment
> >> > | name | first_attempt|
> >> > | date | [2014-03-27 Thu] |
> >> > | user | fleury |
> >> >
> >> > #+BEGIN_SRC sh :var scalar="some value" :var array=my_list :var
> >> table=config
> >> > echo ${scalar} # -> prints 'some value'
> >> > echo ${array} # -> prints 'one two three'
> >> > echo ${table} # -> prints 'first attempt [2014-03-27 Thu] fleury'
> >> > #+END_SRC
> >> >
> >> > This will print simple strings. Also, there is no easy way to access
> the
> >> > date of the experiment, for example. Now bash has things like arrays
> and
> >> > associative arrays, but the current ob-shell.el does not use these.
> >> > Probably because their syntax is bash-specific, and ob-shell.el is
> >> > shell-agnostic.
> >> >
> >> > My patch (attached) changes this in the case you have
> >> > (setq org-babel-sh-command "bash")
> >> > in your emacs config somewhere. If any other value is used, it
> continues
> >> to
> >> > export them as we do today (I don't know enough about other shells).
> >> >
> >> > In that case, it will export the list as an array, the table as an
> >> > associative array, and the scalar as it does already. So the 'sh' code
> >> > block could then use
> >> >
> >> > #+BEGIN_SRC sh :var scalar="some value" :var array=my_list :var
> >> table=config
> >> > echo ${scalar}
> >> > echo ${array[1]} # -> prints "two"
> >> > echo ${table[user]} # -> prints "fleury"
> >> > #+END_SRC
> >> >
> >> > In the case we have a bigger table, then the first row is used as key,
> >> the
> >> > others are represented as a string with all the values (as it is for
> >> array
> >> > currently). bash does not have multi-dimensional arrays, so it needs
> to
> >> be
> >> > a string.
> >> >
> >> > This makes writing shell snippets much easier in my experience, and
> there
> >> > I'd like to propose this fix for the org-mode community at large.
> >> >
> >> > --paf
> >> >
> >> > diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
> >> > index 3ede701..0a691e2 100644
> >> > --- a/lisp/ob-shell.el
> >> > +++ b/lisp/ob-shell.el
> >> > @@ -106,6 +106,30 @@ This function is called by
> >> `org-babel-execute-src-block'."
> >> >
> >> > ;; helper functions
> >> >
> >> > +(defun org-babel-variable-assignments:bash_array (varname values
> >> &optional sep hline)
> >> > + "Returns a list of statements declaring the v
Re: [O] emphasis borders, double quotes, and export
Nicolas Goaziou writes: > Alan Schmitt writes: > >> Thanks, I'm aware this works. I was trying not to manually set some >> default values so that, if default changes, I would benefit from the >> change. But from what I understand there is not really a choice here >> without changing org. > > I guess the next stop for this variable will be, hopefully, the dustbin. ... and there will be great rejoicing throughout the land. -- Nick
[O] Is `org-preview-latex-fragment` sensitive to alignment specified by document class options?
Hi,
Is there a way to make `org-preview-latex-fragment` sensitive to LaTeX
class options? I have a simple example to demonstrate where it does
not:
%%%
#+LaTeX_CLASS: article
#+LaTeX_CLASS_OPTIONS: [fleqn]
#+LATEX_HEADER: \usepackage{amsmath}
\begin{gather}
b := (a \oplus s_1) \oplus s_2 \\
e := 0 \\
\end{gather}
%%%
If LaTeX is generated for this document with
`org-latex-export-to-latex`, which is compiled to a PDF with pdflatex,
the "b :=" and the "e :=" are left aligned i.e. the "b" and "e" are
vertically aligned.
However, if `org-preview-latex-fragment` is called within emacs, the
left alignment specified with the `[fleqn]` class option is not
honoured. Thus, the two lines in the `gather` block are centrally
aligned, which is the default case for `gather` blocks.
This is a screenshot of the PDF: http://imgur.com/YVRAlYP
This is a screenshot of the preview within emacs: http://imgur.com/S6BNm0K
So, is there a way to make `org-preview-latex-fragment` sensitive to
LaTeX class options?
Thanks,
--
Rob
Re: [O] Exporting to multiple files
Marcin Borkowski writes: Hello, Marcin, all! >> > I'd like to export an Org-mode file to /multiple/ HTML files. For >> > instance, I might want to convert all first and second level ... > Thanks a lot! Your code seems inspiring - I've only skimmed through it > now, but e.g. the org-map-entries is something very useful I had no > idea existed... This might also be useful: https://github.com/iani/org-publish-meta It seems to allow you to export subtrees to different projects. Hope that helps! Sacha
Re: [O] emphasis borders, double quotes, and export
Alan Schmitt writes: > Thanks, I'm aware this works. I was trying not to manually set some > default values so that, if default changes, I would benefit from the > change. But from what I understand there is not really a choice here > without changing org. I guess the next stop for this variable will be, hopefully, the dustbin. So, if I were you, I wouldn't worry much about future changes. Regards, -- Nicolas Goaziou
Re: [O] emphasis borders, double quotes, and export
Nicolas Goaziou writes:
> Hello,
>
> Alan Schmitt writes:
>
>> I assume the problem is that I want to change only one field of
>> `org-emphasis-regexp-components' but it's not possible to do so because
>> it's not defined before org is loaded.
>>
>> I guess one way to proceed is to split up
>> `org-emphasis-regexp-components' into its four components, to be able to
>> change only the one I need. Would such a patch be accepted?
>
> This is not needed. You can redefine the four components with an initial
> setq:
>
> (setq org-emphasis-regexp-components
>'(" \t('\"{" "- \t.,:!?;'\")}\\" your-own-string "." 1))
Thanks, I'm aware this works. I was trying not to manually set some
default values so that, if default changes, I would benefit from the
change. But from what I understand there is not really a choice here
without changing org.
Thanks again,
Alan
Re: [O] Compiling Org Mode on Windows - "date" Bug?
Wow, I sure feel silly now. This is so much easier than trying to get the damn thing compiled under Windows. Thanks! - Will On Sun, Apr 6, 2014 at 2:23 PM, Achim Gratz wrote: > William Kunkel writes: > > Does the ELPA package include packages not bundled with Emacs (Those > > marked "C" in customize-variable org-modules)? > > The org-plus-contrib package does. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > SD adaptation for Waldorf microQ V2.22R2: > http://Synth.Stromeko.net/Downloads.html#WaldorfSDada > > >
Re: [O] Compiling Org Mode on Windows - "date" Bug?
William Kunkel writes: > Does the ELPA package include packages not bundled with Emacs (Those > marked "C" in customize-variable org-modules)? The org-plus-contrib package does. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Insert UUID with org-insert-todo-heading
I'm using the following to have a CREATED field in the PROPERTIES field of a TODO: ;; advice org-insert-todo-heading to insert a created timestamp using org-expiry (defadvice org-insert-todo-heading (after mrb/created-timestamp-advice activate) "Insert a CREATED property using org-expiry.el for TODO entries" (mrb/insert-created-timestamp) ) (ad-activate 'org-insert-todo-heading) So, I get: TODO :PROPERTIES: :CREATED: [2014-04-06 sø. 20:11] :END: Is there any way to insert a UUID as well?, like: TODO :PROPERTIES: :CREATED: [2014-04-06 sø. 20:11] :UUID: 70f273b5-8bce-315f-6f31-6d9ec9a8b739 :END: Any pointers as to how I can achieve this? -- Esben Stien is b0ef@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n
Re: [O] Images not showing up in PDF output
Thanks Richard and Eric!
After running it in MikTex by itself, and doing some look-ups, I found that I
needed:
1) To use unix style directories in the file paths
2) To use #+LATEX_HEADER: \usepackage[multidot]{grffile} in order to
accommodate the extra dot
in the file name.
Thanks!
Mark
On Sat, 4/5/14, Richard Lawrence wrote:
Subject: Re: [O] Images not showing up in PDF output
To: emacs-orgmode@gnu.org
Cc: "Mark S."
Date: Saturday, April 5, 2014, 9:46 AM
Hi Mark,
> On Saturday, 5 Apr 2014 at 05:59, Mark S. wrote:
>> Hello,
>>
>> I was able to export a subtree as PDF, but the
images don't show
>> up. The images do export in HTML, and I can see
that there is LaTeX
>> code for it. It looks like this:
>>
>>
>>\includegraphics[width=10em]{./Periodicals.org_20140402_202538_4928DjL.png}
>>
>> Are there settings or additional add-ons that I
need to produce the images?
In addition to Eric's advice, I would recommend that you
check that this
image is in the right directory, relative to where the .tex
file lives,
and relative to where LaTeX is being run. (Check the
compile log to see
if there are errors about not finding the image, or try to
compile the
exported .tex by hand, without the -interaction nonstopmode
option which
I believe is Org's default.)
I have sometimes run into problems (mostly with BibTeX) when
the
exported .tex file doesn't exist in the directory where
org-latex-pdf-process is run: even though the paths may look
right in
the .tex file, if the other files used in the compilation
(.aux, etc.)
don't end up in the right place, relative paths can break.
Best,
Richard
(If possible, please encrypt your reply to me using my PGP
key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for
more information.)
Re: [O] Compiling Org Mode on Windows - "date" Bug?
Does the ELPA package include packages not bundled with Emacs (Those marked "C" in customize-variable org-modules)? Installing it didn't seem to make the org-drill module available. As for the date problem, I guess it's trying to use cmd as my default shell and generating the temporary batch script automatically; I'll try to get that sorted out somehow. Thanks, Will On Sun, Apr 6, 2014 at 3:02 AM, Achim Gratz wrote: > William Kunkel writes: > > I've traced the problem to the fact that make is trying to run a > > temporary batch script with cmd, with the contents: > > > > @echo off > > date +%Y-%m-%d > > There is no such batch script in the entire Org distribution, nor should > the build system ever try to run cmd for anything (you really need a > POSIX shell for anything make doesn't use built-ins for), so it seems > you're using some strange make and/or have the PATH set incorrectly. If > you're not using a recent GNU Make, you can try to compile Org without > one (as described in the FAQ on Worg), however I'd suggest you use the > ELPA package instead. > > That said, the result of the particular invocation that requires date is > only used in the documentation, so if you really want to see how far you > can progress beyond that, simply remove the "$(shell date +%Y-%m-%d)" in > mk/targets.mk and replace it with the current date like "2014-04-06". > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: > http://Synth.Stromeko.net/Downloads.html#WaldorfSDada > > >
Re: [O] Prepare release 8.2.6
"R. Michael Weylandt" writes: > Thanks for taking the time to review my patches (2 attached): > hopefully these are formatted to org standards. Thank you. They look good. I applied the first one. I'll let Eric, or Bastien, decide about it. > * ob-core.el: Add a function `org-babel-remove-result-one-or-many' > which wraps `org-babel-remove-result' to map unto all src blocks when > called with a prefix arg Small note: this should simply be: * ob-core.el (org-babel-remove-result-one-or-many): New function. Regards, -- Nicolas Goaziou
Re: [O] Prepare release 8.2.6
On Sat, Apr 5, 2014 at 3:27 PM, Nicolas Goaziou wrote: > Hello, > > Would you mind adding a commit message, TINYCHANGE at its end, and send > it again with "git format-patch"? Hi Nicolas, Thanks for taking the time to review my patches (2 attached): hopefully these are formatted to org standards. > >>> 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. >>> (Discussed on list but I can't find the reference) > > [...] > > > Regards, > > -- > Nicolas Goaziou 0001-ox-latex.el-downcase-language-name-in-minted-blocks.patch Description: Binary data 0002-ob-core.el-ob-keys.el-Add-a-keybinding-to-remove-res.patch Description: Binary data
Re: [O] Kill ring contains non-killed output after an export
Hi Richard, Richard Lawrence writes: > ... > The behavior you are seeing is as expected, though I agree that this > behavior is usually not all that useful. See the variable > org-export-copy-to-kill-ring if you want to turn it off. Thanks! Now the export is much more usable for me. Out of curiousity, what is the use case of the default behavior? Best, Kosta
Re: [O] emphasis borders, double quotes, and export
Hello,
Alan Schmitt writes:
> I assume the problem is that I want to change only one field of
> `org-emphasis-regexp-components' but it's not possible to do so because
> it's not defined before org is loaded.
>
> I guess one way to proceed is to split up
> `org-emphasis-regexp-components' into its four components, to be able to
> change only the one I need. Would such a patch be accepted?
This is not needed. You can redefine the four components with an initial
setq:
(setq org-emphasis-regexp-components
'(" \t('\"{" "- \t.,:!?;'\")}\\" your-own-string "." 1))
Regards,
--
Nicolas Goaziou
Re: [O] emphasis borders, double quotes, and export
Nicolas Goaziou writes: > Hello, > > Alan Schmitt writes: > >> Thank you for the suggestion. How can I do that? Add an "(org-reload)" >> in my async init file? Is there a more efficient way than loading org, >> setting the variable, and immediately reloading org again? > > You can set the variable before loading Org for the first time. I just tried it and I get the following error at start-up time: > Warning (initialization): An error occurred while loading > `/Users/schmitta/.emacs.d/init.el': > > Symbol's value as variable is void: org-emphasis-regexp-components My init.el is quite short (as most of my configuration is in an org file). --8<---cut here---start->8--- ;; Turn off mouse interface early in startup to avoid momentary display (if (fboundp 'tool-bar-mode) (tool-bar-mode -1)) (if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1)) ;; remember this directory (setq emacsd-dir (file-name-directory (or load-file-name (buffer-file-name ;; set this up before loading org (setcar (nthcdr 2 org-emphasis-regexp-components) " \t\n,") ;; org-setup (add-to-list 'load-path (concat emacsd-dir "org/emacs/site-lisp/org")) (require 'org) ;; Then tangle and load the file (org-babel-load-file (expand-file-name "myconfig.org" emacsd-dir)) --8<---cut here---end--->8--- I assume the problem is that I want to change only one field of `org-emphasis-regexp-components' but it's not possible to do so because it's not defined before org is loaded. I guess one way to proceed is to split up `org-emphasis-regexp-components' into its four components, to be able to change only the one I need. Would such a patch be accepted? Thanks, Alan
Re: [O] PATCH -- ox-latex.el . sideways figure in latex export
Hello, Greg Tucker-Kellogg writes: > Thanks for the guidance. I think this is it. Applied. Thank you. Regards, -- Nicolas Goaziou
[O] How to properly convert duration to time?
Hi List, I would like to export CLOCK with html5 tag. I can output :duration as for example: 1:23 (1 hour 23 minutes) This format is not valid according to w3org specification. http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-duration-string How to convert duration to valid time string? Regards, Marcin
Re: [O] PATCH -- ox-latex.el . sideways figure in latex export
Thanks for the guidance. I think this is it.
Cheers,
Greg
On Sun, Apr 6, 2014 at 4:46 PM, Nicolas Goaziou wrote:
> Hello,
>
> Greg Tucker-Kellogg writes:
>
> > I think this covers it. ":float sideways" now works for both tables and
> > figures, but ":float sidewaystable" is kept for backwards compatibility.
> I
> > updated org.texi, and mentioned that the use of ":float sideways" will
> make
> > the ":placement" option irrelevant.
> >
> > Attached are the two patches; the one from yesterday and the one that
> > updates as described above.
>
> Thank you. Here are a few comments.
>
> > +The @code{:float} specifies the float environment for the table.
> Possible values are @code{sideways},
> > +(or equivalently @code{sidewaystable}), @code{multicolumn}, @code{t}
> and @code{nil}. When unspecified, a table with
> > +a caption will have a @code{table} environment. Moreover, the
> @code{:placement}
> > +attribute can specify the positioning of the float. Note:
> @code{:placement} is
> > +ignored for sidewaystable.
>
> In Texinfo, you need to add two spaces after a period.
>
> Also, providing backwards compatibility for "sidewaystable" in code is
> fine, but I don't think we need to talk about it anymore as an
> alternative option in the documentation. If you feel uncomfortable about
> it, I think it's better to add a footnote:
>
> Possible values are @code{sideways}@footnote{Formerly, the value was
> @code{sidewaystable}. This is deprecated since Org 8.3.},
> @code{multicolumn}...
>
> Also, could you provide a proper commit message, with "TINYCHANGE" at
> its end. For more information, see
>
> http://orgmode.org/worg/org-contribute.html
>
> I think you can also merge both patches. But that's your call.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
0001-ox-latex.el-support-sideways-float-options-for-table.patch
Description: Binary data
Re: [O] PATCH -- ox-latex.el . sideways figure in latex export
Hello,
Greg Tucker-Kellogg writes:
> I think this covers it. ":float sideways" now works for both tables and
> figures, but ":float sidewaystable" is kept for backwards compatibility. I
> updated org.texi, and mentioned that the use of ":float sideways" will make
> the ":placement" option irrelevant.
>
> Attached are the two patches; the one from yesterday and the one that
> updates as described above.
Thank you. Here are a few comments.
> +The @code{:float} specifies the float environment for the table. Possible
> values are @code{sideways},
> +(or equivalently @code{sidewaystable}), @code{multicolumn}, @code{t} and
> @code{nil}. When unspecified, a table with
> +a caption will have a @code{table} environment. Moreover, the
> @code{:placement}
> +attribute can specify the positioning of the float. Note: @code{:placement}
> is
> +ignored for sidewaystable.
In Texinfo, you need to add two spaces after a period.
Also, providing backwards compatibility for "sidewaystable" in code is
fine, but I don't think we need to talk about it anymore as an
alternative option in the documentation. If you feel uncomfortable about
it, I think it's better to add a footnote:
Possible values are @code{sideways}@footnote{Formerly, the value was
@code{sidewaystable}. This is deprecated since Org 8.3.},
@code{multicolumn}...
Also, could you provide a proper commit message, with "TINYCHANGE" at
its end. For more information, see
http://orgmode.org/worg/org-contribute.html
I think you can also merge both patches. But that's your call.
Regards,
--
Nicolas Goaziou
Re: [O] Compiling Org Mode on Windows - "date" Bug?
William Kunkel writes: > I've traced the problem to the fact that make is trying to run a > temporary batch script with cmd, with the contents: > > @echo off > date +%Y-%m-%d There is no such batch script in the entire Org distribution, nor should the build system ever try to run cmd for anything (you really need a POSIX shell for anything make doesn't use built-ins for), so it seems you're using some strange make and/or have the PATH set incorrectly. If you're not using a recent GNU Make, you can try to compile Org without one (as described in the FAQ on Worg), however I'd suggest you use the ELPA package instead. That said, the result of the particular invocation that requires date is only used in the documentation, so if you really want to see how far you can progress beyond that, simply remove the "$(shell date +%Y-%m-%d)" in mk/targets.mk and replace it with the current date like "2014-04-06". Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
