Re: [O] [PATCH] ox-latex: Add scrartcl LaTeX class
On Mon, Sep 21, 2015 at 11:45:08PM +0200, Rasmus wrote:
> Nicolas Goaziou writes:
>
> > Sebastian Boehm writes:
> >
> >> I would like to propose adding the KOMA-script scrartcl class to the
> >> list of supported ox-latex classes. scrartcl is one of the most
> >> popular "article" alternatives out there and it would be great to be
> >> able to pass org files using scrartcl to other Org mode users without
> >> having to explain ox-latex custom settings.
> >>
> >> The attached patch changes ox-latex.el to include scrartcl in
> >> org-latex-classes.
> >
> > Thank you. But can't users needing a non-default class customize their
> > own `org-latex-classes? Or is there an entitling reason to offer it out
> > of the box?
>
> It's absolutely a much more pleasant experience than article, at least if
> you agree with the KOMA-guys' margin opinion (e.g. top:bottom margin is
> fixed at 1:2). [I've been using the KOMA-bundle for years and years].
>
> The patch is also subjective, e.g. it does not feature \minisec[.]{.}.
>
> ox-koma-article.el would be awesome but until then, there's no point in
> adding it.
I use scrartcl, but I think this should be left up to the end user.
ox-koma-article.el would be great though :).
--
Suvayu
Open source is the future. It sets us free.
Re: [O] A book produced using Org
On Mon, Sep 21, 2015 at 02:51:13PM -0500, Grant Rettke wrote:
> Where is your Emacs+OrgMode configuration file?
>
> I want to see what it takes to compile using xelatex; utf8 support
> seems like a great idea.
Until recently, it used be just this:
;; remove "inputenc" from default packages as it clashes with xelatex
(setf org-latex-default-packages-alist
(remove '("AUTO" "inputenc" t) org-latex-default-packages-alist))
;; replace fontenc, with fontspec
(let ((pos (position '("T1" "fontenc" t) ; T1 -> utf8 for pdflatex
org-latex-default-packages-alist
:test 'equal)))
(if pos
(setf (nth pos org-latex-default-packages-alist)
'("" "fontspec" t
(setq org-latex-pdf-process ; -shell-escape needed for minted
'("xelatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"xelatex -shell-escape -interaction nonstopmode -output-directory %o %f"
"xelatex -shell-escape -interaction nonstopmode -output-directory %o
%f")
;; org-latex-pdf-process '("sh -v -x texi2dvi -p -b -c -V %f") ;
historical
;; TODO: maybe use arara, that probably requires export changes
)
After this patch from Rasmus:
it's as simple as adding a
#+latex_program: xelatex
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Agenda Tag filtering - has the behaviour changed?
On Thu, Sep 17, 2015 at 12:16:44PM -0400, Bernt Hansen wrote: > Nicolas Goaziou writes: > > > Hello, > > > > Robert Klein writes: > > > >> Looking through the commit messages this may come from commit > >> 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8 > > > > Indeed. It seems related to this NEWS entry > > > > *** Minor refactoring of ~org-agenda-filter-by-tag~ > > Now uses the argument arg and optional argument exclude instead of > > strip and narrow. ARG because the argument has multiple purposes and > > makes more sense than strip now. The term narrowing is changed to > > exclude. > > > > The main purpose is for the function to make more logical sense when > > filtering on tags now when tags can be structured in hierarchies. > > Thanks both. > > So was this an intended usability change? I can probably live with it - > I just need to retrain my fingers -- but it does take longer to achieve > the result I want now since I have to clear the agenda tags before > selecting a new filter and wait for the agenda update each time (my > agenda has lots of entries). > > The old behaviour was faster to use. > > I haven't done anything with hierarchical tags yet. FWIW, I think hierarchical tags should be opt-in. The current behaviour is a very nice feature, but probably a less common use case than the old behaviour. Maybe there can be a toggle? I tried looking at the source, but it looked non-trivial. -- Suvayu Open source is the future. It sets us free.
Re: [O] http address for cloning org-mode git
On Wed, Sep 23, 2015 at 03:03:42PM -0400, Kaushal Modi wrote: > Hi all, > > I cannot access the git: repo address and so had been using the http: > version till now ( http://repo.or.cz/r/org-mode.git/ ). That is a mirror, a relic from the old days when that used to be the official repo. Maybe try: http://orgmode.org/org-mode.git http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development -- Suvayu Open source is the future. It sets us free.
Re: [O] http address for cloning org-mode git
On Wed, Sep 23, 2015 at 09:29:06PM +0200, Achim Gratz wrote: > Suvayu Ali writes: > > On Wed, Sep 23, 2015 at 03:03:42PM -0400, Kaushal Modi wrote: > >> I cannot access the git: repo address and so had been using the http: > >> version till now ( http://repo.or.cz/r/org-mode.git/ ). > > > > That is a mirror, a relic from the old days when that used to be the > > official repo. Maybe try: http://orgmode.org/org-mode.git > > No, that never was the official repo. I've set up that mirror. Didn't we used to have the Org repo hosted on repo.or.cz way, way back in the old days, pre-2010? Maybe I'm just confusing a different repo because it was on the same domain? -- Suvayu Open source is the future. It sets us free.
Re: [O] [ ] Checkboxes or count of completed TODOs in subtree?
On Thu, Sep 24, 2015 at 10:41:19AM +0200, Rainer M Krug wrote: > > I would like to be able to use something like checkboxes in a tree of > headers. > > I understand that checkboxes only work in simple lists, i.e. not on > headers and trees of headers. > > But I would like to see in my document (an ongoing analysis, of which > certain parts in each subtree are completed and others still need to > be done) which subtree contains how many TODO subheaders, effectively as > I can do with simple lists and checkboxes. > > But as this is the basis for a paper, I want to keep the headers and not > use simple lists. > > Is this possible? Is there a way to see how many active TODOs are still > under each header? You can use statistics cookies for TODO states on the parent headline. * Parent [1/3] ** TODO Section 1 ** WInP Section 2 ** DONE Section 3 Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] help debugging org-element crashes?
On Thu, Sep 24, 2015 at 04:30:13PM -0400, Peter Salazar wrote: > Hey everyone, > > I'm finding my Emacs crashing a lot; other times I get errors like these > which I assume are related to the crashes: > http://pastebin.com/Tncs79r0 > http://pastebin.com/jfdEYwVk > > I mean total Emacs crashes, where I have to force quit Emacs itself. It's > happened in various org-mode situations including: > - pasting text from OSX clipboard > - promoting/demoting org-headings > - moving subtree up or down (i.e. using org-metadown org org-metaup) [...chomp...chomp...chomp...] > Any suggestions on how I can track this down and fix it? You could use this minor mode to track down the cache issue: https://github.com/suvayu/.emacs.d/blob/master/lisp/org-element-debug.el Once you know what triggers the crash, you can probably come-up with a minimal example and post it here. @Nicolas, others, do you think this should be on an FAQ on worg? Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] help debugging org-element crashes?
On Fri, Sep 25, 2015 at 01:34:50PM +0200, Nicolas Goaziou wrote: > Hello, > > Suvayu Ali writes: > > > @Nicolas, others, do you think this should be on an FAQ on worg? > > Not yet, please. I plan to change the internals of the cache at some > point, when I get sufficient spare time. Sure! -- Suvayu Open source is the future. It sets us free.
Re: [O] Exporter aborts upon encountering even one unresolvable link
On Fri, Sep 25, 2015 at 09:04:29AM +0200, Rainer M Krug wrote: > > Look at publishing instead of exporting to html which works with > missing links. That sounds a bit fishy. AFAIK, ox-publish just wraps around the usual org-export-as functions from ox.el. I could be wrong of course. -- Suvayu Open source is the future. It sets us free.
Re: [O] bug: latex exporter
On Tue, Sep 29, 2015 at 05:37:30AM -0400, Charles Millar wrote: > Since Monday morning (New York time) I have not been able to export to > pdflatex (worked OK the night before). Instead the message buffer reads > > symbol's value as variable is void - compile > > GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7) of 2014-03-07 on > lamiak, modified by Debian > Org-mode version 8.3.1 (release_8.3.1-283-gf6187d @ > /usr/share/emacs/site-lisp/org-mode/lisp/) You do not provide enough information. Did you reload Org? How do you export? Did you try to produce a backtrace? What does that show? Maybe try with minimal settings? Please see: http://orgmode.org/manual/Feedback.html#Feedback -- Suvayu Open source is the future. It sets us free.
Re: [O] "Symbol’s value as variable is void: compile" when export to latex
On Tue, Sep 29, 2015 at 11:11:09AM +0200, Rainer M Krug wrote: > > Exporting to latex of the simple file below results in an error: > > , > | mapcar: Symbol’s value as variable is void: compile > ` [...chomp...chomp...chomp...] > #+LATEX_COMPILER: pdflatex Are you trying to use Rasmus's latex variant facility? I'll update and test soon. Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Per command org-agenda-prefix-format
Hi,
I wanted to prefix the results of a tags-todo agenda command with
scheduling information. But I can't seem to figure out the correct way
to do this. This is what I tried:
(setq org-agenda-custom-commands
'(("J" "Type1/Type2"
((tags-todo "CATEGORY=\"foo\"+type1"
((org-agenda-overriding-header "Type1")))
(tags-todo "CATEGORY=\"foo\"+type2"
((org-agenda-overriding-header "Type2"
((org-agenda-files (list "~/tmp/org/tasks.org"))
(org-agenda-prefix-format " % s")
(org-agenda-compact-blocks t)
With the attached Org file, the agenda buffer looks like this:
Type1
foo:TODO Item 1 :type1::
foo:TODO Item 3 :type1::
Type2
foo:TODO Item 8 :type2::
Anyone any thoughts? Actually I have wanted a view like "Timeline" for
many years for my agenda searches. Is that possible? That would be
even better.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Per command org-agenda-prefix-format
On Wed, Oct 07, 2015 at 05:24:50PM +0200, Suvayu Ali wrote: > > With the attached Org file, the agenda buffer looks like this: Forgot to attach the file :-p. -- Suvayu Open source is the future. It sets us free. #+OPTIONS: toc:nil #+STARTUP: content * Foo :PROPERTIES: :CATEGORY: foo :END: ** Type 1 [0/2] :type1: *** TODO Item 1 DEADLINE: <2016-01-31 Sun> *** TODO Item 3 DEADLINE: <2015-10-31 Sat> ** Type 2 [2/3] :type2: *** DONE Item 4 CLOSED: [2015-09-22 Tue 15:36] SCHEDULED: <2015-09-14 Mon> *** DONE Item 6 CLOSED: [2015-10-02 Fri 13:36] SCHEDULED: <2015-09-07 Mon> *** TODO Item 8 SCHEDULED: <2015-09-02 Wed>
Re: [O] Per command org-agenda-prefix-format
On Wed, Oct 07, 2015 at 02:52:24PM -0400, Nick Dokos wrote:
> Suvayu Ali writes:
>
> > Hi,
> >
> > I wanted to prefix the results of a tags-todo agenda command with
> > scheduling information. But I can't seem to figure out the correct way
> > to do this. This is what I tried:
> >
> > (setq org-agenda-custom-commands
> > '(("J" "Type1/Type2"
> > ((tags-todo "CATEGORY=\"foo\"+type1"
> > ((org-agenda-overriding-header "Type1")))
> > (tags-todo "CATEGORY=\"foo\"+type2"
> > ((org-agenda-overriding-header "Type2"
> > ((org-agenda-files (list "~/tmp/org/tasks.org"))
> > (org-agenda-prefix-format " % s")
>
> org-agenda-prefix-format is an alist, not a string.
Forgot to mention in my earlier post, I tried that too! Something like
this:
(org-agenda-prefix-format '(tags " % s"))
Same result.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Latex strikethrough or cancel?
Hi Lawrence,
On Thu, Oct 08, 2015 at 03:35:43AM +, Lawrence Bottorff wrote:
> I've got a fraction done this way in an org file:
>
> \[
> \frac{1}{(2^3)(5)}
> \]
>
> and I'd like to strike though or cancel the (5) part. The Latex method I've
> found says do it this way:
>
> ...
> \usepackage[makeroom]{cancel}
> ...
>
> \[
> \frac{1}{(2^3)\cancel{(5)}}
> \]
>
> But it's ignored and comes back verbatim. Of course +(5)+ doesn't work
> either, again, coming back verbatim with the pluses. How can I do this?
Unless the \cancel{..} is not exported properly, this is a LaTeX
question. I think you will have better luck finding an answer if you
ask a community dedicated to LaTeX, e.g. TeX.SX.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Per command org-agenda-prefix-format
Hi Nick,
On Thu, Oct 08, 2015 at 03:02:02AM -0400, Nick Dokos wrote:
> Suvayu Ali writes:
>
> > On Wed, Oct 07, 2015 at 02:52:24PM -0400, Nick Dokos wrote:
> >> Suvayu Ali writes:
> >>
> >> > Hi,
> >> >
> >> > I wanted to prefix the results of a tags-todo agenda command with
> >> > scheduling information. But I can't seem to figure out the
> correct way
> >> > to do this. This is what I tried:
> >> >
> >> > (setq org-agenda-custom-commands
> >> > '(("J" "Type1/Type2"
> >> > ((tags-todo "CATEGORY=\"foo\"+type1"
> >> > ((org-agenda-overriding-header "Type1")))
> >> > (tags-todo "CATEGORY=\"foo\"+type2"
> >> > ((org-agenda-overriding-header "Type2"
> >> > ((org-agenda-files (list "~/tmp/org/tasks.org"))
> >> > (org-agenda-prefix-format " % s")
> >>
> >> org-agenda-prefix-format is an alist, not a string.
> >
> > Forgot to mention in my earlier post, I tried that too! Something like
> > this:
> >
> > (org-agenda-prefix-format '(tags " % s"))
> >
> > Same result.
>
> Although that's not the right form (it should be '((tags . " % s")) -
> and according to the doc it should be the whole 5-element alist), you
> are right: it does not make any difference. Also, internally, the string
> form is accepted just as well as the alist form by
> org-compile-prefix-format, so I was wrong about the alist vs string
> distinction.
Actually I went through these steps too! I am not too familiar with the
agenda code, so I wasn't sure whether I was understanding it correctly.
> IIUC (do I?), you expect the format to produce the Deadline: or Scheduled:
> prefixes that you get in the timeline. Unfortunately, that code is
> completely separate from the code that gets executed here. In the
> timeline, we go
>
> org-timeline -> org-agenda-get-scheduled (or org-agenda-get-deadlines)
> -> org-agenda-format-item("Scheduled: " )
>
> with the first argument providing the appropriate prefix.
> But with the custom agenda, we go a different way:
>
> org-tags-view -> org-scan-tags -> org-agenda-format-item("" ...)
>
> and org-scan-tags calls org-agenda-format-item with a hardwired empty
> string for the "extra" argument - it does not matter that %s has been
> specified in org-agenda-prefix-format. So I don't think you can do what
> you want (again IIUC).
Hmm, I was hoping for the timeline like prefix, but even a normal prefix
as in the usual agenda ("Sched. 2x") would also have worked for me.
> Presumably, stealing the code that calculates whether the entry should
> get a scheduling prefix from org-agenda-get-scheduled and grafting it
> into org-scan-tags would do the trick, but that's not the way things are
> today.
Thanks for clearly outlining the code path for me. Maybe if I find some
time, I'll hack around a bit.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [ANN] Export block syntax change
Hi,
On Sun, Dec 20, 2015 at 10:06:44PM +0100, Nicolas Goaziou wrote:
>
> I just finalized the syntax change for export blocks. As a reminder, the
> new syntax is:
>
> #+BEGIN_EXPORT backend
> ...
> #+END_EXPORT
>
> instead of
>
> #+BEGIN_backend
> ...
> #+END_backend
This seems to not work for me. The following block is completely
missing from the exported tex source.
#+begin_export latex
\begin{equation}
ct = (S.V. - P.V.) \times m/p.
\end{equation}
#+end_export
Am I missing something?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [ANN] Export block syntax change
On Sat, Jan 02, 2016 at 11:54:42AM +0100, Nicolas Goaziou wrote:
> Hello,
>
> Suvayu Ali writes:
>
>
> > On Sun, Dec 20, 2015 at 10:06:44PM +0100, Nicolas Goaziou wrote:
> >>
> >> I just finalized the syntax change for export blocks. As a reminder, the
> >> new syntax is:
> >>
> >> #+BEGIN_EXPORT backend
> >> ...
> >> #+END_EXPORT
> >>
> >> instead of
> >>
> >> #+BEGIN_backend
> >> ...
> >> #+END_backend
> >
> > This seems to not work for me. The following block is completely
> > missing from the exported tex source.
> >
> > #+begin_export latex
> > \begin{equation}
> > ct = (S.V. - P.V.) \times m/p.
> > \end{equation}
> > #+end_export
> >
>
> Fixed. Thank you.
Thanks! It works now.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] The power of '-'
On Fri, Jun 24, 2016 at 01:24:44PM -0400, Brenda Butler wrote: > I'm not super advanced in org-mode, so take what I have to say as > "non-authoritative", but: > > I don't think you need any prefix on lines in your org-mode file. > Lines with some number of * are headers as you noted > Lines that start with a - make a list of items. > > I'm not sure what you can do with lists ... but probably that has an effect > on formatting. > So you can have a paragraph (no prefix), then a list (list items start with > -) then another paragraph ... You may take a look here for an authoritative source: http://orgmode.org/manual/Document-structure.html#Document-structure > I haven't tried to "export" my org files so I don't know how it would > look. I just use the files as a todo/done list/database/thing. Here are some export tutorials: http://orgmode.org/worg/exporters/ The canonical reference is of course the manual. You can also find a plethora of tutorials here: http://orgmode.org/worg/org-tutorials/. Note, some are quite outdated though. That said, you need not go through them all. The central idea behind getting started with Org mode is: explore as your need broadens. Welcome to Org mode, and happy exploring :) Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] org-link-edit.el --- Slurp and barf with Org links
On 19 February 2015 at 06:24, Kyle Meyer wrote: > Rasmus wrote: >> Kyle Meyer writes: >> >>> remove description words like Paredit lets you do with S-expressions. >>> I've put these Paredit-inspired slurping and barfing commands for Org >>> link descriptions in org-link-edit.el >> >> That's so need! >> >> Did you/will you add it to contrib? > > I'm glad you think it looks useful. I haven't added it contrib (I don't > have push access and wasn't sure if others would be interested), but I'd > be happy for it to be in contrib. I think this is a great addition to contrib/. Great command names, btw ;). -- Suvayu Open source is the future. It sets us free.
Re: [O] [RFC] Repeat Heading movement commands
On 29 March 2015 at 23:43, Xavier Maillard wrote: > > John Kitchin writes: > >> This kind of repeated command seems to be a good application for hydra. > > Excuse me if this is a FAQ but: what's hydra ? https://github.com/abo-abo/hydra/ -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH]Extend export hook example for removing headlines with tag ignore_heading
Hi, I would like to chime in here. On Mon, Apr 13, 2015 at 09:42:58PM +0200, Nicolas Goaziou wrote: > > Please keep in mind this is an example to illustrate > `org-export-before-parsing-hook', not really a place to document some > hack. Is it a good idea to promote org-export-before-parsing-hook in the manual? As shown by this example, most solutions would be case specific with unforeseen consequences. I believe this was one of the reasons the original ignoreheading hack from pre-8.0 days was converted to filter. I think Worg is a more appropriate place for such content. In-fact, exactly this particular use is already being documented by someone in exporters/ox-overview.org. At the moment it is under noexport, so only visible on the git repo. http://orgmode.org/w/worg.git?p=worg.git;a=blob;f=exporters/ox-overview.org;h=98976fc65e3c4d2a55650651091d2e12e194a581;hb=HEAD#l294 WDYT? -- Suvayu Open source is the future. It sets us free.
[O] Target and link text normalised to `orgtargetn'
Hello everyone,
I am exporting Org files to LaTeX. I noticed something strange
happening. The text of all my target text gets changed to `orgtargetn'
where n is some number. This breaks a lot of my LaTeX specific links.
For example, I use the varioref package to get entity specific
references, so \secref{sec:foo}, \figref{fig:bar}, \tabref{sec:baz} (it
even takes care of language, or punctuation as needed!). Now if the
target text changes from sec:foo to orgtarget1, of course the link
breaks.
I thought I would simply put the references into a normal org link,
[[sec:foo]], and use a filter to put the sec, fig, tab, etc. But of
course that doesn't work since I can't tell which is which as the text
has changed!
Is this intended? What is the rational? Can I switch this off with a
setting somewhere? I think this is a very recent change, afaict, it was
working as expected before.
Thanks for any response,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
Hi,
I found a partial answer.
On Tue, Apr 14, 2015 at 11:25:30AM +0200, Suvayu Ali wrote:
>
> I am exporting Org files to LaTeX. I noticed something strange
> happening. The text of all my target text gets changed to `orgtargetn'
> where n is some number. This breaks a lot of my LaTeX specific links.
>
> For example, I use the varioref package to get entity specific
Typo here, the package name is actually refstyle.
> references, so \secref{sec:foo}, \figref{fig:bar}, \tabref{sec:baz} (it
> even takes care of language, or punctuation as needed!). Now if the
> target text changes from sec:foo to orgtarget1, of course the link
> breaks.
The commit 4bbc054 introduces a variable org-latex-prefer-user-labels.
which is reponsible for this behaviour. Setting this variable to t
doesn't entirely solve my problem though. Normal targets like
<> are still altered.
I think the docstring hints at that already.
For headlines that do not define the CUSTOM_ID property or elements
without a NAME, Org will continue to use its default labeling scheme
to generate labels and resolve links into proper references.
I guess a bare target is an element without a NAME. I find this a bit
strange, since the user already adds the target manually. So I think it
is already the user's responsibility to ensure it is consistent.
Shouldn't then Org leave this unchanged?
Thanks,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
Hi Rasmus, On Thu, Apr 16, 2015 at 12:57:46AM +0200, Rasmus wrote: > > Could you try the attached patches and see if they solve your issues? Seems to work nicely. I'll keep using them rest of the week. Thanks, :) -- Suvayu Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
Hi Nicolas,
On Sat, Apr 18, 2015 at 11:53:01PM +0200, Nicolas Goaziou wrote:
> Hello,
>
> Rasmus writes:
>
> > Suvayu Ali writes:
> >
> >> Hi Rasmus,
> >>
> >> On Thu, Apr 16, 2015 at 12:57:46AM +0200, Rasmus wrote:
> >>>
> >>> Could you try the attached patches and see if they solve your issues?
> >>
> >> Seems to work nicely. I'll keep using them rest of the week.
> >
> > Pushed.
> >
> > I removed support for radio targets as I don't really see the point in
> > those supporting custom labeling. They are transcoded as
> >
> > <<>
> > →
> > \hyperref{label}{target}
> >
> > It makes little sense to label be the same as target, though it probably
> > would not create problems.
>
> I don't see the point of this change. The naming scheme is internal
> anyway. Users are not supposed to use it directly.
Sorry, I don't think I quite understand. AFAIU, targets like
<> have to be unique even inside the Org buffer for links
like this to work: [[interesting][very cool]], regardless of export. So
then why rename them during export?
> If you want \label{foo} in the output, you can write
> @@latex:\label{foo}@@.
>
> Targets are for Org links and are expected to work across all back-ends,
> so the problem they solve is slightly different.
How does the above solve the issue? I was not having problems with
getting to export \label{foo}, my problem was what do I put as `foo'
since in the exported TeX file foo was different.
Hopefully I made myself clear, or I'm not misunderstanding something.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
Hi Nicolas,
On Sun, Apr 19, 2015 at 02:57:09PM +0200, Nicolas Goaziou wrote:
> Suvayu Ali writes:
>
> > Sorry, I don't think I quite understand. AFAIU, targets like
> > <> have to be unique even inside the Org buffer for links
> > like this to work: [[interesting][very cool]], regardless of export. So
> > then why rename them during export?
>
> There's no guarantee that, e.g., \label{interesting} is a valid syntax.
> Think about <<100%>> for LaTeX. Actually such links were broken for
> non-ASCII characters before the patch.
>
> Note that this is transparent for the user: if <> becomes
> \label{foo}, [[interesting][very cool]] automatically becomes
> \hyperref[foo]{very cool}.
>
> Your problem is different AFAIU. You are relying on the internal pattern
> of generated labels, i.e., you are eating Org's dog food. I advise
> against it.
Yes indeed. I wanted to use the location information provided by
refstyle, and varioref. By using \secref or \vpageref I would get
references like: section §3, on page 5, etc.
> If you need explicitly "\label{interesting}", ask Org to write it with,
> e.g., "@@latex:\label{foo}@@" or even better
>
> #+MACRO: lbl @@latex:\label{$1}@@
>
> {{{lbl(foo)}}}
>
Okay I see it now, in your last email I got a bit confused, but now I
follow. With your solution I use both label and reference using LaTeX,
bypassing Org. Of course this leaves me with links not working inside
Org. I was eventually going to use filters to transform the ref
commands to the alternate ones from refstyle and varioref to get both
LaTeX and Org side working as I wanted. Something like this:
<>
[[sec:interesting]]
Then transform \ref{sec:interesting} → \secref{sec:interesting} with a
filter; that way I would have my cake and eat it too! I see your point
though.
Thanks a lot for the comments. :)
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
Hi Nicolas,
On Sun, Apr 19, 2015 at 03:40:07PM +0200, Nicolas Goaziou wrote:
> Suvayu Ali writes:
>
> > Okay I see it now, in your last email I got a bit confused, but now I
> > follow. With your solution I use both label and reference using LaTeX,
> > bypassing Org. Of course this leaves me with links not working inside
> > Org. I was eventually going to use filters to transform the ref
> > commands to the alternate ones from refstyle and varioref to get both
> > LaTeX and Org side working as I wanted. Something like this:
> >
> > <>
> >
> > [[sec:interesting]]
> >
> > Then transform \ref{sec:interesting} → \secref{sec:interesting} with a
> > filter; that way I would have my cake and eat it too! I see your point
> > though.
>
> You can do that with a non-nil `org-latex-prefer-user-labels'.
> Otherwise, <> becomes \label{whatever}, defeating your
> filter.
Ah, that was my report, that option did not work for me completely.
See: http://thread.gmane.org/gmane.emacs.orgmode/96887/focus=96888.
To summarise quickly, with the above option set to t all
references/links behave as I expect, except the ones where the target is
a `bare target'.
Does that mean there was indeed a bug?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Target and link text normalised to `orgtargetn'
On Sun, Apr 19, 2015 at 03:56:22PM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > Ah, that was my report, that option did not work for me completely. > > See: http://thread.gmane.org/gmane.emacs.orgmode/96887/focus=96888. > > > > To summarise quickly, with the above option set to t all > > references/links behave as I expect, except the ones where the target is > > a `bare target'. > > > > Does that mean there was indeed a bug? > > Yes, Rasmus fixed it in f1548e11fe2972819bc48b88c6094b11150e5c8a. I just > fixed Rasmus' fix wrt radio targets. Ah, okk. Up to speed now. Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Resolving conflicts with ediff and folding
Hi, Something that has been bugging me for many years now, everytime I resolve conflicts in Org files with ediff, it's a pain. All the buffers keep folding the outlines, hiding the conflicts. I keep going to the buffers manually (which can be somewhat of a pain in a text terminal), and unfolding them manually. But of course the PROPERTY drawers, LOGBOOKs, and other DRAWERs are still folded! And then after I have jumped through hoops, and resolved the conflicts, I realise I could have just switched to text-mode before invoking ediff! Is there a way where I don't have to remember to switch the major mode before invoking ediff[1]? Or maybe an ediff experience where the buffers are forced to unhide text. I guess it should be possible to just temporarily remove all overlays or invisible properties. Any thoughts, ideas? Footnotes: [1] I guess I can advice ediff*, but compiling a comprehensive list of all such functions might be bit of a chore. -- Suvayu Open source is the future. It sets us free.
Re: [O] A Microsoftesque detail in org
On Mon, May 18, 2015 at 06:33:51PM +1000, Brett Witty wrote: > > While there can be a bit of a culture shock getting used to org's "do the > useful thing" as opposed to "do the literal thing", I think it's an > advantage of the system, not a disadvantage. Headers are sacred in > org-mode, so breaking headers with RET seems suboptimal when there's vastly > more things you'd care about. Similarly in tables, or drawers or timestamps > or... Actually, the headline behaviour was a shock to me as a long time user! I would have reported it if only I had some time to be more involved. As for headlines being sacred, I realise they may have a lot of meta information. However the keyword is "may", they are all optional. Even the most primary candidate for "protection", tags, are optional! As long as we can undo, I do not think any hand holding is necessary. As for Rasmus's examples of similar behaviour in other modes, I don't like them either. Unfortunately again, I'm too short on time to fix the behaviour in my setup. That said, this is just my personal opinion. As long as there ways to get the "normal" behaviour back, I'm happy. If there are no easy ways to get it back, I'll live with it. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] A Microsoftesque detail in org
Hi Rasmus, On Mon, May 18, 2015 at 05:39:36PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > As for Rasmus's examples of similar behaviour in other modes, I don't > > like them either. Unfortunately again, I'm too short on time to fix the > > behaviour in my setup. > > So far nobody has felt strongly enough about this to supply a patch, even > to org.texi or, I think, worg. > > Here's an untested start to get rid of those pesky Microsoftesque detail > in org-mode > > (with-eval-after-load 'org > (add-hook 'org-mode-hook > (defun org-keyboard-purist () > (org-defkey org-mode-map (kbd "RET") nil) > (mapc (lambda (key) > (org-defkey org-mode-map key nil)) > (list [(control return)] > [(shift control return)] > [(meta return)]) I didn't realise it is this simple! I'm always afraid of fiddling with Org key bindings because of all the context sensitive magic going on. Thank you. -- Suvayu Open source is the future. It sets us free.
Re: [O] use of 'system in ox-odt.el
On Tue, May 19, 2015 at 02:19:10PM -0400, Matt Price wrote: > On Tue, May 19, 2015 at 10:57 AM, Rasmus wrote: > > > Matt Price writes: > > > > > When I export-and-open to odt, org doesn't open the resultant odt, even > > > though I get a message: > > > > > > Running xdg-open /home/matt/RLG231/RLG231Syllabus.odt...done > > > > > > org-open-file works fine on links in an org buffer, and an anser on the > > > following stackoverflow page suggests the issue is in ox-odt.el: > > > > With your change it open the odt file as a tar-mode file from Emacs -q. > > Without your change it doesn't open it at all. BTW: My Emacs also doesn't > > open html exports in Fx files when I use C-c C-e h-o. I never tried to > > debug it though... > > > > > Yeah, I just got that too -- I realized I hadn't been testing it in the > right environment, shoot. this modification worked for me (also form the > same forum): > > > (setcdr (assq 'system org-file-apps-defaults-gnu ) '(call-process > "xdg-open" nil 0 nil file)) > > Not sure why this should work when the default fails. Fx opens html > exports for me with C-c C-e h-o -- also not sure why that should work and > odt fail. Do you have a mailcap which says otherwise? That's what I would suspect given the doc string for org-file-apps and the default value of org-file-apps-defaults-gnu on my system. -- Suvayu Open source is the future. It sets us free.
Re: [O] How to export to pdf and link to other pdf-files?
On Wed, May 20, 2015 at 11:43:13AM +0200, Rasmus wrote:
> Dov Grobgeld writes:
>
> > What do I need to do to inhibit the inclusion of pdf files as graphics
> > files, when exporting an org file to pdf?
> >
> > Ideally I would like to have links to referenced pdf files and not have
> > them treated as embedded graphics.
>
> A very quick look suggests it's hardcoded in org-latex--inline-image.
> Thus, the easiest thing may be to use a filter and be sure to include the
> pdf extension. I think you might have to use
> org-export-filter-paragraph-functions,
I think the OP can simply add a description to the links. AFAIK, links
with descriptions are exported as links during LaTeX export.
Okay I can confirm this. The following:
[[file:/tmp/foo.pdf][A link]]
is exported as:
\href{file:///tmp/foo.pdf}{A link}
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] use of 'system in ox-odt.el
On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: > Suvayu Ali writes: > > > Do you have a mailcap which says otherwise? That's what I would suspect > > given the doc string for org-file-apps and the default value of > > org-file-apps-defaults-gnu on my system. > > I have this in my mailcap > > application/msword; antiword %s; > application/pdf; evince %s; > application/vnd.lotus-organizer; emacsclient -ca '' %s; > application/zip file-roller %s; > > Org does not open my html and odt files. It does open pdf files. This is > using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the > terminal. There should also be a system-wide setting in /etc/mailcap. On my Fedora machine, the system-wide settings all look like this: text/html; /usr/bin/xdg-open %s ; copiousoutput If yours doesn't, you could override it in ~/.mailcap. If that doesn't fix things, I'm out of ideas :-|. GL, > May contains speling mistake > Funnny ;) -- Suvayu Open source is the future. It sets us free.
Re: [O] use of 'system in ox-odt.el
On Wed, May 20, 2015 at 01:21:34PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > On Wed, May 20, 2015 at 11:50:03AM +0200, Rasmus wrote: > >> Suvayu Ali writes: > >> > > > >> > Do you have a mailcap which says otherwise? That's what I would suspect > >> > given the doc string for org-file-apps and the default value of > >> > org-file-apps-defaults-gnu on my system. > >> > >> I have this in my mailcap > >> > >> application/msword; antiword %s; > >> application/pdf;evince %s; > >> application/vnd.lotus-organizer; emacsclient -ca '' %s; > >> application/zip file-roller %s; > >> > >> Org does not open my html and odt files. It does open pdf files. This is > >> using emacs -q. I use Gnome 3.16 and xdg-open works as expected from the > >> terminal. > > > > There should also be a system-wide setting in /etc/mailcap. On my > > Fedora machine, the system-wide settings all look like this: > > > > text/html; /usr/bin/xdg-open %s ; copiousoutput > > > > If yours doesn't, you could override it in ~/.mailcap. If that doesn't > > fix things, I'm out of ideas :-|. > > Now it get the message > > Running /usr/bin/xdg-open /tmp/test.html ...done > > But it doesn't actually open the file... The same happens when I mark the > file in dired and says & xdg-open. From the terminal it works fine. You are on Gnome, rt? I think there is a long standing "bug" in gvfs-open (which is called by xdg-open). See the following: http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00279.html https://bugzilla.gnome.org/show_bug.cgi?id=652262 I came across this a long time ago trying to investigate why xdg-open didn't work when running asynchronously like your example. http://thread.gmane.org/gmane.emacs.help/93430 Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] org-mode, tikz and beamer
On Thu, May 21, 2015 at 04:40:33PM +0200, cédric ody wrote: > Dear org-mode users, > > I have used org-mode for some months now. I find it very useful. I > have recently used it to prepare mathematic teaching lessons using the > beamer exporter. > > I wanted to combine org-mode and tikz latex's package from latex In > order to insert some kind of mind-mapping from the headlines between > the main parts of the lesson. I enclose an example so that you can see > what I am talking about. Note that you can move forth and back through > the presentation with hyperlinks. Note also only the chapter "Droites > dans le plan" is filled so most of links fail. Some of the links in that chapter are not working properly I think, but otherwise it's a very impressive start! If you post your current shell script with the Org file, I think others can suggest what is and is not possible. To put it in more words, we don't know what you are thinking. If we can see the Org source and the shell script, it is easier to understand how you map Org elements to beamer/tikz environments. I think you have started a very interesting project! Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] org-notmuch: how to open-link-at-point in other window?
On Thu, May 21, 2015 at 11:41:07AM -0400, Kyle Meyer wrote: > Gregor Zattler wrote: > > Dear org-moders, > > > > I want to open-link-at-point (C-c C-o) in other window. With > > file links this is standard behaviour (at least with my > > configuration). But I don’t know how to do so with notmuch: > > links. Universal argument won’t help. > > org-notmuch-follow-link calls notmuch-show, which uses switch-to-buffer. > You can set org-notmuch-open-function to a function that behaves the way > you want. There are probably cleaner ways to handle this, but below > seems to work. > > #+begin_src elisp > (setq org-notmuch-open-function 'org-notmuch-follow-link-other-window) > > (defun org-notmuch-follow-link-other-window (search) > "Like `org-notmuch-follow-link', but use other window." > (pop-to-buffer (save-window-excursion > (notmuch-show (org-link-unescape search) > #+end_src I think this (writing your own defun) is the cleanest way to handle this. There is no way for Org to ensure a consistent behaviour for all possible link types, there are too many. Org can ensure consistency only for physical files, and even then when they are opened inside Emacs. There is no shortage of links to binary files! For what it's worth, I have customised notmuch open function to use the notmuch-tree interface. -- Suvayu Open source is the future. It sets us free.
Re: [O] org-mode, tikz and beamer
Hello Cédric, First, apologies for the delay. I am swamped with a lot of things for a while now, makes my responses rather irregular. On Thu, May 21, 2015 at 10:33:13PM +0200, cédric ody wrote: > Thank you for your answer. > > Here is the shell script (many comments are in english except the > beginning) and the org file I use. To see how I call it, you can have > a look at the enclosed Makefile. Note that it uses specific > configurations files as well tex macros so it won't work without these > files. I can prepare a short example which generates the tex and pdf > files if needed. The script probably gives for now a good idea. You > can also look at the enclosed generated tex file to see how the tikz > language. I think you forgot the Makefile. Aside from that, I looked at the script, and the Org file, albeit not very thoroughly. My impression is, it is a really nice effort but I think it's unsustainable. You have to duplicate a lot of work, and since you do it in a shell script, you are limited. Here are a few particular points: - You reimplement the Org parser. This of course means you do not support a large part of the standard syntax[1]. It's not future proof either. For the same reasons, it is very brittle. Org-element does a great job of parsing, you should use it. - You seem to rely on specific cookies, like `%%%' (and maybe "abusing" tags like noexport?). This is introducing _new_ syntax. Again, since this is outside of org-element, there is no way to ensure robustness and reproducibility. > Basically, the shell script looks recursively into the org file and > creates nodes for the tikz headline mindmaps. Thus, there are parent > nodes and children nodes. > > During that excursion, two kinds of files are created: the "tree" > files and the "contents" files. > > The first ones are tex files with tikz mindmaps that must be inserted > at specific locations at the final latex compilation step. One tree > file contains the parent node with all the children files. This part sounds good. > The "contents" files are org files and are converted into tex files > via the org-mode export command in a batch way. In the shell script, > hyperlinks are added to these newly converted tex files. This, I'm not completely certain. If I got this right, you export one file per beamer frame? Is that right? I also see you do a bit of editing with sed. Again, I think this makes it too brittle, too many assumptions about what is present and what is not. > At the end, the assembly of all these files is done before compiling. > > Numbering of sections through the recursive call is important so that > links work properly as you notice. Links allow one to go back and > forth the document. To go back, the idea is to click on the headline. > If a node exists without content, the links sends you the beginning of > the file or something like that. This part I'm not sure I quite understand. Shouldn't normal LaTeX referencing mechanisms (à la \label and \ref) be able to handle this? Anyway, after looking at the script I'm convinced this endeavour is better pursued in lisp. I think it would help if you draft a document outlining the Org elements you want to map to which specific tikz features/commands. You will then have a list of leftover info that tikz still needs to achieve the end goal. At this point others can suggest how you could communicate these missing info to tikz. E.g. you already have one suggestion from Bernhard, but I think it is probably too generic. If you manage to pursue this, I think the outcome will be a new Org backend, possibly derived from ox-latex or ox-beamer. Please don't be afraid to learn lisp, although it is hard to master, it's easy to pick up. I think the list will be more than willing to help you with that. Also, I think this is not a easy project. It will take some iterations to get to a version that can be test widely (by say putting in an experimental branch or something). While proof reading my email, I just realised ox-koma-letter might be a really nice place for you to get familiar with how to repurpose Org syntax to translate info to the backend in different ways. Have a look. Hope this helps, Footnotes: [1] Do not underestimate this aspect, Org users have a way to come up with interesting ways to use features that were not envisioned during development! -- Suvayu Open source is the future. It sets us free.
Re: [O] ob-sed
Hi Bjarte, On Fri, May 29, 2015 at 03:32:51PM +0200, Bjarte Johansen wrote: > > > >> +(defun org-babel-execute:sed (body params) > >> + "Execute a block of sed code with Org Babel. > >> +BODY is the source inside a sed source block and PARAMS is an > >> +association list over the source block configurations. This > >^^^ > > two spaces I think Nicolas means there should be two spaces after the period after "configurations". Something like this: configurations. This It is probably clearer to see, once you read his email in a fixed width font. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] resize table in latex
On Mon, Jun 01, 2015 at 10:51:24AM +, Zhihao Ding wrote:
> Hi there,
>
> I am trying to find a way to automatically resize tables
> in the latex output.
>
> When doing slides in beamer, I use this to resize tables
> to fit in a frame
>
> #+LaTeX: \scriptsize{\resizebox{\textwidth}{!}{
> | . | . |
> #+LaTeX: }}
>
> While when writing reports, I use the following instead
> as I need to cross reference it by the name
>
> #+CAPTION: table caption
> #+NAME: table:label
> | . | . |
>
> then I loose the resize facility. How could I combine
> the two? I tried to fiddle with
> #+ATTR_LATEX but didn’t mange to make it work.
I don't follow. Why do you say you lose the facility? The following:
#+LaTeX: \scriptsize{\resizebox{\textwidth}{!}{
#+CAPTION: table caption
#+NAME: table:label
| . | . |
| . | . |
#+LaTeX: }}
exports as:
\scriptsize{\resizebox{\textwidth}{!}{
\begin{table}[htb]
\caption{\label{tab:orgtable1}
table caption}
\centering
\begin{tabular}{ll}
. & .\\
. & .\\
\end{tabular}
\end{table}
}}
Isn't that exactly what you want?
--
Suvayu
Open source is the future. It sets us free.
Re: [O] resize table in latex
On Tue, Jun 02, 2015 at 08:43:07AM +, Zhihao Ding wrote:
> Thanks very much for your reply. The proposed method
> in this reply won’t work. It needs to be in the following
> structure where this line
>
> “\scriptsize{\resizebox{\textwidth}{!}{“
>
> is after “\begin{table}[htb]” and immediately before
> “\begin{tabular}{rr}”.
Why is that? Is it because table is a float?
You could try repurposing the :caption attribute. See:
(info "(org) LaTeX specific attributes")
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Specifying ATTR_LATEX document wide?
On Tue, Jun 02, 2015 at 12:17:04PM +0200, Rainer M Krug wrote:
>
> Hi
>
> In one document, I would like to make two changes how images are
> inserted in LaTeX / pdf documents, namely:
>
> 1) have no re-sizing, i.e.
>
> ,
> | \includegraphics[]{./output/fig_crossValidationDefaultByUA.pdf}
> `
Does the following work equivalently for you?
#+attr_LaTeX: :width \linewidth
> Is there a way of setting this globally fir the actual document
> (document header?), so that I don't have to add this line to all my
> hundred images (OK - only about 70 - but still to many)?
Maybe use babel blocks for this? Input files from a list or table, echo
them back with a common #+attr_latex line?
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
[O] Possible cache problems
Hi, I have been noticing a strange heisenbug. From time to time, Org starts eating CPU for certain specific tasks: org-end-of-line, fill-paragraph, folding or unfolding trees, or adding/changing properties with org-set-property. However these happen only after I have been using Org for a while. I think I also see similar CPU eating symptoms when I have buffers editing version controlled files. I have auto-revert-mode enabled for files under version control, I think that is related. I'm not entirely sure though, I don't know how to narrow it down either. I say it is cache related since all this magically goes away, once I go to the top of my current tree, and call org-element-cache-reset. However, once the symptoms start showing, it happens more frequently despite my cache resets. It's very hard to reproduce this though. I see it when I have been using the same Emacs session over several days. I always run emacs as a daemon, so sessions lasting a week or more is quite common. To see the symptoms I have to wait about half a week to a whole week, hence the hard to reproduce comment. However, once the symptoms show, it gets bad rather fast. I end up restarting when the need to reset the cache gets too frequent. Any thoughts? Thanks, -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
Hi Nicolas, On Tue, Jun 02, 2015 at 10:26:54PM +0200, Nicolas Goaziou wrote: > Hello, > > Suvayu Ali writes: > > > I have been noticing a strange heisenbug. From time to time, Org starts > > eating CPU for certain specific tasks: org-end-of-line, fill-paragraph, > > folding or unfolding trees, or adding/changing properties with > > org-set-property. However these happen only after I have been using Org > > for a while. > > This is typical for cache breakage. Okay, good that it is not as mysterious as I was thinking :). > > I think I also see similar CPU eating symptoms when I have buffers > > editing version controlled files. I have auto-revert-mode enabled for > > files under version control, I think that is related. I'm not entirely > > sure though, I don't know how to narrow it down either. > > > > I say it is cache related since all this magically goes away, once I go > > to the top of my current tree, and call org-element-cache-reset. > > However, once the symptoms start showing, it happens more frequently > > despite my cache resets. > > Usually, a cache breakage is a specific action applied to some specific > document structure that induces an incorrect computation of the parts of > the cache to clear and to update. > > If you encountered the problem, it means the problematic document > structure is already in the current buffer. So, the chances are high > that you will repeat the problematic editing action on it again, even > after resetting the cache. IOW, all the ingredients are there for the > problem to repeat again and again. > > Finding the problematic action is not easy. I wrote a basic minor mode > (element-debug-mode) for that: after each change to the buffer, it > checks if the cache and pending updates match the parse tree. It sends > a message anytime they differ, which happens as soon as a problematic > action was triggered. I have enabled the mode on my document. Let's see how this goes. Btw, since you warn against large documents, would it help if I narrowed a large document before enabling the mode? Thanks a lot :). -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
On Tue, Jun 02, 2015 at 11:27:55PM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > Btw, since you warn against large documents, would it help if > > I narrowed a large document before enabling the mode? > > It wouldn't: cache ignores narrowing anyway. Okay thanks :) -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
Hi Nicolas,
On Tue, Jun 02, 2015 at 11:27:55PM +0200, Nicolas Goaziou wrote:
> Suvayu Ali writes:
>
> > I have enabled the mode on my document. Let's see how this goes.
>
> OK. You have to keep an eye on the *Messages* buffer so that warning
> don't go unnoticed.
I do not see anything happening. In the modeline I see OrgCacheD, so
the mode is definitely enabled. However to enable it, I had to do one
of these two:
(setq ngz-debug-mode nil)
(setq ngz-debug-mode t)
I do not see any messages with either. Here is a sample of messages
with nil,
Wrote /home/user/org/LHCb-Bs2Dsh/gamma/cpv.org
Saving file /home/user/org/LHCb-Bs2Dsh/gamma/WIN2015/cpv_flavour_suvayu.tex...
Wrote /home/user/org/LHCb-Bs2Dsh/gamma/WIN2015/cpv_flavour_suvayu.tex
Searched 1 buffer; 11 matches for `em]'
Mark saved where search started
Saving file /home/user/org/LHCb-Bs2Dsh/gamma/cpv.org...
Wrote /home/user/org/LHCb-Bs2Dsh/gamma/cpv.org
Saving file /home/user/org/LHCb-Bs2Dsh/gamma/WIN2015/cpv_flavour_suvayu.tex...
Wrote /home/user/org/LHCb-Bs2Dsh/gamma/WIN2015/cpv_flavour_suvayu.tex
I'm exporting to LaTeX and compiling from a shell. Everytime I export,
Emacs starts eating CPU after export. This is apart from the random
hangs during editing. I usually keep doing C-g several times to get
back a responsive interface; the last few times I waited for it to
finish though, and it does finish but no messages (as you see above).
Am I missing something?
I also see some folding anomalies:
After 1 :
asl & phi:BMCOL:
:PROPERTIES:...
* φ_{s} measurements
:B_boldH:...
After 2 s:
asl & phi:BMCOL:
:PROPERTIES:...
:PROPERTIES:...
- B⁰ → D^{\ast}Xlν (\BaBar) :: PRL 111 101802 (2013)
- B → X_{s}ll (\BaBar) :: PRL 112 211802
- B → X_{s}γ (\BaBar) :: PRD 90 092001
* φ_{s} measurements:B_boldH:
:PROPERTIES:
:BEAMER_env: boldH
:END:
- B_{s} → J/ψKK,ππ (LHCb) :: PRD 87 (2013) 112010
And this is the Org source:
asl & phi:BMCOL:
:PROPERTIES:
:BEAMER_col: 0.33
:END:
* a_{sl}/A_{\CP} measurements :B_boldH:
:PROPERTIES:
:BEAMER_env: boldH
:END:
#+attr_LaTeX: :options [style=nextline]
- B⁰ → D^{\ast}Xlν (\BaBar) :: PRL 111 101802 (2013)
- B → X_{s}ll (\BaBar) :: PRL 112 211802
- B → X_{s}γ (\BaBar) :: PRD 90 092001
* φ_{s} measurements:B_boldH:
:PROPERTIES:
:BEAMER_env: boldH
:END:
- B_{s} → J/ψKK,ππ (LHCb) :: PRD 87 (2013) 112010
I have to go unfold the property drawer for "asl & phi", go to the end
of the :END: line, and hit tab to reveal the next headline. I don't
think this one is cache related, maybe I should start different thread
for this.
Any thoughts?
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On Sat, Jun 06, 2015 at 09:28:12AM +0200, Nicolas Goaziou wrote: > Titus von der Malsburg writes: > > > Thee can be handled by protectedtexttt. The obvious questions is of > > course: Wouldn’t it be more consistent to handle all instances of ~code~ > > using protectedtexttt? > > One option would be indeed to remove \verb altogether. Note that it is > also used in inline source blocks. > > However, I assume \verb put less limitations than \texttt on its > contents, so I'd rather keep \verb around. This TeX.SX post discourages the use of \verb. http://tex.stackexchange.com/a/83894/4416 It cites the following FAQ from UK TeX. http://www.TeX.ac.uk/cgi-bin/texfaq2html?label=verbwithin Maybe it is worth to consider dropping \verb entirely? Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
On Sun, Jun 07, 2015 at 01:29:04AM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > I do not see anything happening. In the modeline I see OrgCacheD, so > > the mode is definitely enabled. However to enable it, I had to do one > > of these two: > > > > (setq ngz-debug-mode nil) > > (setq ngz-debug-mode t) > > My bad, it should be > > (define-minor-mode element-debug-mode > "Minor mode to debug Org Element cache." > nil " OrgCacheD" nil > (if element-debug-mode > (progn (setq org-element-cache-sync-idle-time 3600) > (add-hook 'after-change-functions 'element-check-cache t t)) > (setq org-element-cache-sync-idle-time 0.6) > (remove-hook 'after-change-functions 'element-check-cache t))) I should have caught that! I guess I'm too distracted from everything else at the moment :-p. Thanks a lot. Let's see how this goes ... Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
Hi Nicolas, On Sun, Jun 07, 2015 at 01:29:04AM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > I do not see anything happening. In the modeline I see OrgCacheD, so > > the mode is definitely enabled. However to enable it, I had to do one > > of these two: > > > > (setq ngz-debug-mode nil) > > (setq ngz-debug-mode t) > > My bad, it should be > > (define-minor-mode element-debug-mode > "Minor mode to debug Org Element cache." > nil " OrgCacheD" nil > (if element-debug-mode > (progn (setq org-element-cache-sync-idle-time 3600) > (add-hook 'after-change-functions 'element-check-cache t t)) > (setq org-element-cache-sync-idle-time 0.6) > (remove-hook 'after-change-functions 'element-check-cache t))) I got a message like the following one quite a few times. Partially completed == WARNING. Corrupted element (table-row) at 34386 Real: (table-row (:type standard :begin 34386 :end 34430 :contents-begin 34387 :contents-end 34429 :post-blank 0 :post-affiliated 34386 :parent (table (:begin 34327 :end 34431 :type org :tblfm nil :contents-begin 34342 :contents-end 34430 :value nil :post-blank 1 :post-affiliated 34342 :attr_latex () :parent nil Cached: (table-row (:type standard :begin 34386 :end 34430 :contents-begin 34387 :contents-end 34429 :post-blank 0 :post-affiliated 34386 :parent (table (:begin 34328 :end 34417 :type org :tblfm nil :contents-begin 34328 :contents-end 34416 :value nil :post-blank 1 :post-affiliated 34328 :parent nil Last request: [34926 34372 34328 14 (property-drawer (:begin 34276 :end 34328 :contents-begin 34294 :contents-end 34316 :post-blank 1 :post-affiliated 34276 :parent nil)) (table (:begin 34327 :end 34431 :type org :tblfm nil :contents-begin 34342 :contents-end 34430 :value nil :post-blank 1 :post-affiliated 34342 :attr_latex () :parent nil)) 2] I was trying to edit the attr_latex line for the following table: #+attr_latex: | year | 2012 | 2018 | 2022 | 2028 | 2035 | | γ(°) |7 |4 | 1.3 | 0.9 | 0.6 | Right now I'm not working with Org for a few days, but next week I'll start again. So maybe I'll get a few other data points soon. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
On Thu, Jun 11, 2015 at 09:00:39AM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > I was trying to edit the attr_latex line for the following table: > > > > #+attr_latex: > > | year | 2012 | 2018 | 2022 | 2028 | 2035 | > > | γ(°) |7 |4 | 1.3 | 0.9 | 0.6 | > > I can reproduce it. I will look into it before the end of the week. Great, I wasn't expecting to get a reproducible case so soon! Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Possible cache problems
On Sun, Jun 14, 2015 at 02:58:25PM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > I was trying to edit the attr_latex line for the following table: > > > > #+attr_latex: > > | year | 2012 | 2018 | 2022 | 2028 | 2035 | > > | γ(°) |7 |4 | 1.3 | 0.9 | 0.6 | > > Fixed in 182ff104b77d1c4cd03a2749472d9da0c7733116. Thank you. Thanks a lot! > This change requires a modification to `element-check-cache' function > I sent you earlier, if you plan to use it again: Thank you. I'll most definitely use it to debug problems :). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Add LaTeX to SVG support to org-mode
Hi Adam, As others mentioned, diffs are easier to work with. Please see the instructions on the how to contribute page on Worg. That said, if you do not want to checkout the latest Org (the version you sent looks like a version that was shipped with Emacs). You can still generate a diff. Copy the original somewhere, and then edit the copy. Once done editing, you can generate a diff like this: $ diff -u /path/to/original/org.el /path/to/edited/org.el > org.el.diff If you then send the org.el.diff file, people would be happy to look at it and help you get to a good solution. Hope this email ecourages you to put in the extra effort :). Cheers, On Sat, Jun 13, 2015 at 06:45:51PM +0200, Adam Sneller wrote: > > Out of the box, emacs supports two methods for rendering LaTeX previews in > orgmode: dvipng and imagemagick. I want to add a third method, using dvisvgm. > I have modified the org.el file to add org-create-formula-image-with-dvisvg. > Everything seems to work fine, except that orgmode is unable to find the SVG > file and errors "Failed to create svg file from ...". But the file it is > looking for does exist. > > Any ideas? -- Suvayu Open source is the future. It sets us free.
[O] Custom column environment in beamer export
Hi,
Is it possible to define a custom column like environment? At the
moment I'm hacking around the need with this:
(add-to-list 'org-beamer-environments-extra
'("minipage" "m" "\\begin{minipage}%H" "\\end{minipage}%"))
With the above I can export the following
* 0.1\linewidth :B_minipage:
:PROPERTIES:
:BEAMER_env: minipage
:END:
+/cFit/+
to
\begin{minipage}{0.1\linewidth}
\structure{\emph{cFit}}
\end{minipage}%
However within Org, not being able to specify a descriptive headline
sacrifices readability. It would be great if I could write something
like this:
* Fitting technique :B_minipage:
:PROPERTIES:
:BEAMER_env: minipage
:BEAMER_arg: 0.1\linewidth
:END:
+/cFit/+
I seem to recall this was possible in the past. Is there any chance to
get something like this going?
Thanks for any thoughts.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Custom column environment in beamer export
On Tue, Jun 16, 2015 at 12:30:09AM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > * Fitting technique :B_minipage:
> > :PROPERTIES:
> > :BEAMER_env: minipage
> > :BEAMER_arg: 0.1\linewidth
> > :END:
> > +/cFit/+
>
> The closest would probably be something like
>
> (add-to-list 'org-beamer-environments-extra
> '("minipage"
>"m"
>"\\begin{minipage}%o%a\n\\structure{%h}"
>"\\end{minipage}"))
>
> Which would afford you something like
>
> * slide
> ** Fitting technique:B_minipage:
> :PROPERTIES:
> :BEAMER_env: minipage
> :BEAMER_OPT: [t]{0.1\linewidth}
> :BEAMER_ACT: <5>
> :END:
> /cFit/
Well, I would rather keep the formatting in the org file, so no
\structure in the template. But otherwise your suggestion seems exactly
what I need :).
> Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to
> org-beamer--normalize-argument, so the above won't actually work (see
> org-beamer--format-block). From the looks of it I'd be willing to call it
> a bug, but Nicolas may have had something in mind.
I was thinking the same. That's why I felt the need for the old
BEAMER_arg property!
> Perhaps these days it would be nice to allow the third element of
> org-beamer-environments-extra to be a λ taking either the object or so.
> Then again, perhaps this is an overkill and too low-level.
This might be nice, but as you say could be overkill. Although, there
are a few other cases which is harder to use with the current syntax.
Take minipage as an example, it takes 3 optional arguments[1].
Presently there is no way of dealing with something like that. Removing
the autowrapping of brackets would allow such cases, but it would
probably break a few Org files in the wild. From that perspective, a
lambda might be the way to go.
> Personally, I'd use a block, e.g.
>
> #+attr_latex: :options [t]{.1\textwidth}
> #+begin_minipage
> Cfit
> #+end_minipage
Nice idea. I have never really explored using blocks (other than for
raw latex), maybe I should ...
Thanks,
Footnotes:
[1] https://en.wikibooks.org/wiki/LaTeX/Boxes#minipage_and_parbox
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Custom column environment in beamer export
Hi Nicolas, On Tue, Jun 16, 2015 at 01:57:06PM +0200, Nicolas Goaziou wrote: > Rasmus writes: > > > Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to > > org-beamer--normalize-argument, so the above won't actually work (see > > org-beamer--format-block). From the looks of it I'd be willing to call it > > a bug, but Nicolas may have had something in mind. > > IIRC it was a pre-8.0 feature already. In any case, it allows sloppy > writing for options, i.e., with or without square brackets. Yes, I think so. > > Perhaps these days it would be nice to allow the third element of > > org-beamer-environments-extra to be a λ taking either the object or so. > > Then again, perhaps this is an overkill and too low-level. > > More simply, we can also add placeholders in templates, e.g., > > %R raw action specification > %O raw options argument Indeed, that would work well I think. One can wrap the raw arguments anyway you wish in the template. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Custom column environment in beamer export
On Tue, Jun 16, 2015 at 03:33:03PM +0200, Nicolas Goaziou wrote:
> Rasmus writes:
>
> > Indeed. That's the incremental fix.
>
> Done in cf5fd31f0c4f18bd0256157adb98306d53f8a52c.
Works great! I went with this template:
(add-to-list 'org-beamer-environments-extra
'("minipage" "m" "\\begin{minipage}%O{%R}" "\\end{minipage}%"))
For my use case, I rarely use overlay actions, so I repurposed it for
environment arguments.
Thanks a lot!
PS: OT, within beamer I find minipage is easier to manage than columns.
--
Suvayu
Open source is the future. It sets us free.
[O] Bug with label names in beamer export
Hi,
I encountered a strange problem today, exporting to beamer didn't
produce any pages eventhough it compiled just fine! It turns out it's
how Org exported the labels. They should be wrapped in {..}. See this
TeX.SX question for more: http://tex.stackexchange.com/q/250640/4416
The attached patch should fix the issue.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
>From e82cd7bf86dc01d1038a442fd66ba8b97ec7a23e Mon Sep 17 00:00:00 2001
From: Suvayu Ali
Date: Tue, 16 Jun 2015 21:04:21 +0200
Subject: [PATCH] ox-beamer: Wrap labels in braces in beamer export
* lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
The `:' in the label name causes an argument parsing problem, for more
see <http://tex.stackexchange.com/q/250640/4416>.
---
lisp/ox-beamer.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index dafadb3..3119bd4 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -337,7 +337,7 @@ function assumes HEADLINE will be treated as a frame."
(if (and (stringp opt)
(string-match "\\(?:^\\|,\\)label=\\(.*?\\)\\(?:$\\|,\\)" opt))
(match-string 1 opt)
- (concat "sec:" (org-export-get-reference headline info)
+ (format "{sec:%s}" (org-export-get-reference headline info)
(defun org-beamer--frame-level (headline info)
"Return frame level in subtree containing HEADLINE.
--
2.4.3
Re: [O] Links
Hi Nicolas, Fabrice, On Tue, Jun 16, 2015 at 11:30:06PM +0200, Nicolas Goaziou wrote: > Fabrice Popineau writes: > > > Ideally, url encoded links should have been prefixed with some kind of uri > > syntax. > > This way, you could know what to decode and what not. > > The encoded link could be copied from somewhere else. Also, there are > numerous links in the wild without this prefix. Would it make sense to "promote" these kind of encoded links to almost their own sub-types? I would guess, almost no one enters these encoded links by hand. It's either via copy paste in the prompt from org-insert-link, or by entering [[encoded-link][description]] by hand. I think it is a reasonable inconvenience to ask the user to prefix it with something like uri:. I mostly see advantages for a minor inconvenience. Although, you still have to handle the ambiguous case for existing Org files. Unless this double maintenance is cumbersome, I would vote for introducing such a scheme. What do others think? -- Suvayu Open source is the future. It sets us free.
Re: [O] Bug with label names in beamer export
On Tue, Jun 16, 2015 at 09:36:26PM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > The attached patch should fix the issue.
>
> Pushed, thanks. I changed the commit message slightly.
>
> > * lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
>
> You don't need the "lisp/" prefix. Capitalize after the colon. Should
> end with period.
Thank you!
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Links
On Wed, Jun 17, 2015 at 11:47:38AM +0200, Nicolas Goaziou wrote: [... description of the issues trimmed ...] > > Although, you still have to handle the ambiguous case for existing Org > > files. Unless this double maintenance is cumbersome, I would vote for > > introducing such a scheme. > > The double maintenance is not possible. Either we take into > consideration the prefix or the heuristic rule above, and some links are > going to break, or we allow to bypass it and it doesn't improve the > situation. This is tricky indeed. I guess the heuristic is the safest bet when it comes to compatibility. -- Suvayu Open source is the future. It sets us free.
[O] Special blocks with options in LaTeX export
Hi,
I am trying to export special blocks with options. But it seems the
options part is being ignored completely. I expect the following:
#+begin_aside :options {Combinatorial background}
It is all random!
#+end_aside
to be exported as:
\begin{aside}{Combinatorial background}
It is all random!
\end{aside}
However what I get is without the extra argument to the environment.
Am I missing something, or is this a bug?
Thanks,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Special blocks with options in LaTeX export
Hi Rasmus, On Sun, Jun 28, 2015 at 01:30:33PM +0200, Rasmus wrote: > > Options are read via > > (org-export-read-attribute :attr_latex special-block :options). > > As to whether special blocks should support options via a keyword like in > your example, I do not know. FWIW ox-html also reads attributes for > special blocks via an ATTR_BACKEND line. I expected it to work because the manual says so, see "Special blocks in LaTeX export" in (info "(org) LaTeX specific attributes"). A brief quote: In LaTeX back-end, special blocks become environments of the same name. Value of ‘:options’ attribute will be appended as-is to that environment’s opening string. For example: [...] Cheers, -- Suvayu Open source is the future. It sets us free.
[O] LaTeX filter for captions
Hi, I wanted to apply a filter to normal text and captions. So I initially used org-export-filter-body-functions, however this also applies on the section title. Handling that case would make my filter a bit more complicated. So I switched to using org-export-filter-paragraph-functions. However I can't find what would be the corresponding filter list for captions (both figures and tables). Any ideas? Thanks, -- Suvayu Open source is the future. It sets us free.
Re: [O] LaTeX filter for captions
On Sun, Jun 28, 2015 at 11:52:06PM +0200, Nicolas Goaziou wrote: > Suvayu Ali writes: > > > I wanted to apply a filter to normal text and captions. So I initially > > used org-export-filter-body-functions, however this also applies on the > > section title. Handling that case would make my filter a bit more > > complicated. So I switched to using > > org-export-filter-paragraph-functions. However I can't find what would > > be the corresponding filter list for captions (both figures and > > tables). > > There is no such filter. By the time filters are called, captions have > already been merged with their element. IOW, > `org-export-filter-paragraph-functions' is applied to a string > containing both the caption and the paragraph. Indeed, this makes sense. I was mistaken about what I was looking at. When I noticed my filter was not being applied to captions, I had forgotten those particular figures were exported via latex blocks, not as usual figures! Adding my filter to org-export-filter-export-block-functions solved my issue. Thanks! -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
Hi Rasmus,
On Tue, Jul 07, 2015 at 04:53:35PM +0200, Rasmus wrote:
>
> If it's a means to archive "high-quality" paragraphs, maybe microtype is
> probably the 'proper' fix...
I would like to second microtype. In fact as far as I know, now a days
it is recommended to load that for almost all documents with significant
text on TeX.SX.
I would also suggest removing inputenc. At the moment, it is loaded
with the AUTO option. AFAIK, this is redundant since most recent
(meaning for quite a few years) TeX engines already use the encoding of
the file if nothing is specified.
The next one would be fontenc, now it is loaded with T1. I'm not sure
if this is needed. Maybe LaTeX experts like Marcin or Fabrice could
comment.
> * Fixltx2e
>
> This packages is depreciated with TL2015 cf. LaTeX News 22. We can use
> \RequirePackage[current]{latexrelease} but there's no point in that
> AFAIK latexrelease only useful for backwards compatibility.
Didn't know about this. Thank you. I would vote for dropping it.
> * marvosym¹
> * Wasysym²
Agreed. On top of this, wasysym also interferes with integral symbols
from amsmath[1].
We could also take this opportunity to provide users an easy way to
switch between TeX engines. I have been using XeLaTeX with Org and
outside for quite a few years now. Originally what used to be very
hacky, is now simply replacing a couple of packages in the header and
calling xelatex instead of pdflatex. And the list of packages is pretty
much identical for LuaLaTeX. This is what I would use:
\usepackage{fontspec}
\usepackage{microtype}
\usepackage{polyglossia} % instead of babel
% of course this should be something appropriate for the buffer
\setdefaultlanguage[variant=british]{english}
So an option like tex-engine:xelatex or tex-engine:lualatex adds the
above to the default packages and the right binaries. Just an idea.
Cheers,
Footnotes:
[1] At least that's what comments in my setup tell me :-p:
https://github.com/suvayu/.emacs.d/blob/master/org-mode-config.el#L136
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Tue, Jul 07, 2015 at 10:05:06PM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > \usepackage{polyglossia} % instead of babel
>
> You can use babel with xelatex.
Yes, but polyglossia is recommended. In the interest of minimal work on
the part of Org, this could just be ignored. I don't think we add babel
anyway, or do we?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Wed, Jul 08, 2015 at 02:53:46PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > We could also take this opportunity to provide users an easy way to > > switch between TeX engines. > > These two patches goes some of the way towards what you want. > org-latex-pdf-process would also have to patched as well, though. [...chomp...chomp...chomp...] > From 54bcf8f1ae26c91fa856b64071dca65d3f31e1f2 Mon Sep 17 00:00:00 2001 > From: Rasmus > Date: Wed, 8 Jul 2015 14:44:56 +0200 > Subject: [PATCH 9/9] ox-latex: Support TeX variants This one fails to apply for me. I'm on c76fef6 org-clock: Add `untilnow' time block Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Wed, Jul 08, 2015 at 02:54:41PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > I would also suggest removing inputenc. At the moment, it is loaded > > with the AUTO option. AFAIK, this is redundant since most recent > > (meaning for quite a few years) TeX engines already use the encoding of > > the file if nothing is specified. > > A colleague of mine were missing her umlaut today cause she hadn't loaded > inputenc with utf8. So I guess removing inputenc is premature. Interesting, I'll keep this in mind. -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Wed, Jul 08, 2015 at 03:53:32PM +0200, Rasmus wrote: > Suvayu Ali writes: > > >> From 54bcf8f1ae26c91fa856b64071dca65d3f31e1f2 Mon Sep 17 00:00:00 2001 > >> From: Rasmus > >> Date: Wed, 8 Jul 2015 14:44:56 +0200 > >> Subject: [PATCH 9/9] ox-latex: Support TeX variants > > > > This one fails to apply for me. I'm on > > You probably need the other patches posted in OP due to changes in > org-latex-default-packages-alist. Indeed, and it works very nicely! -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Wed, Jul 08, 2015 at 04:26:56PM +0200, Rasmus wrote: > > I'm trying to think of an elegant way to map from a tex-variant to a > command. Perhaps change the variant names to the latex variants and input > that. I think that would be a good way to go. -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
Hi Rasmus,
On Wed, Jul 08, 2015 at 02:53:46PM +0200, Rasmus wrote:
>
> +(defun org-latex-guess-polyglossia-language (header info)
> + "Set the Polyglossia language according to the LANGUAGE keyword.
I'm in two-minds about this. On the one had it is a nice thing, but on
the other hand, it prevents the more fine grained control offered by
polyglossia. For example, I used this in my setup before:
\setdefaultlanguage[variant=british]{english}
I don't see an easy way of passing the optional argument. But on the
other hand
\setmainlanguage{english}
is plain, simple, and works in most (almost all) cases. I'm thinking
whether to leave the babel/polyglossia features entirely up to the user.
That said, I like the feature very much. For people who write in
multiple languages, if they load polyglossia, it should "just work" for
all their documents. Which is great!
WDYT? What do others think?
--
Suvayu
Open source is the future. It sets us free.
[O] ox-koma bug in subtree export
Hi,
I'm using subtree export to write letters using ox-koma. Everything
works except, all the closing statements from different subtrees get
accumulated when I export one of the subtrees.
So with the attached Org file, when I export either of the subtrees, I
get a closing line like this: \closing{Regards, Kind Regards,}.
This used to work before. That said, I never found it quite consistent
when using `#+closing:'. I would have thought one should use a headline
like: to, enclosed, etc.
Is this a bug?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-koma bug in subtree export
On Wed, Jul 15, 2015 at 01:20:57PM +0200, Suvayu Ali wrote:
>
> I'm using subtree export to write letters using ox-koma. Everything
> works except, all the closing statements from different subtrees get
> accumulated when I export one of the subtrees.
>
> So with the attached Org file, when I export either of the subtrees, I
> get a closing line like this: \closing{Regards, Kind Regards,}.
>
> This used to work before. That said, I never found it quite consistent
> when using `#+closing:'. I would have thought one should use a headline
> like: to, enclosed, etc.
>
> Is this a bug?
Of course I forgot to attach the file!
--
Suvayu
Open source is the future. It sets us free.
* letter 1
:PROPERTIES:
:EXPORT_FILE_NAME: letter_1.pdf
:EXPORT_LATEX_CLASS: scrlttr2
:EXPORT_OPTIONS: ':t foldmarks:nil
:EXPORT_TITLE:
:EXPORT_SUBJECT: Some subject
:EXPORT_LCO: DIN
:END:
** To:to:
Mr. Foo Bar
Some place, Else
** Dear Mr. Bar,
Lots of stuff
#+closing: Regards,
* letter 2
:PROPERTIES:
:EXPORT_FILE_NAME: letter_2.pdf
:EXPORT_LATEX_CLASS: scrlttr2
:EXPORT_OPTIONS: ':t foldmarks:nil
:EXPORT_TITLE:
:EXPORT_SUBJECT: Some other subject
:EXPORT_LCO: DIN
:END:
** To:to:
Miss Foo Baz
Some place, Else
** Dear Miss Baz,
Lot more stuff
#+closing: Kind Regards,
Re: [O] ox-koma bug in subtree export
On Wed, Jul 15, 2015 at 01:46:59PM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > I'm using subtree export to write letters using ox-koma. Everything
> > works except, all the closing statements from different subtrees get
> > accumulated when I export one of the subtrees.
> >
> > So with the attached Org file, when I export either of the subtrees, I
> > get a closing line like this: \closing{Regards, Kind Regards,}.
>
> For your purpose you can add an :export_closing: property to your
> top-level heading.
>
> * letter 1
> :PROPERTIES:
> :export_subject: Some subject
> :export_closing: Regards,
> :END:
Great, this works very well.
> > This used to work before. That said, I never found it quite consistent
> > when using `#+closing:'. I would have thought one should use a headline
> > like: to, enclosed, etc.
>
> Maybe:
>
>* Regards,:closing:
> Signature
Something like that would be a lot more logical indeed.
> > Is this a bug?
>
> From you example, I'd say 'no'. Keywords are shared. E.g. if you have
>
> #+latex_header: my important package
>
> You'd want it to be loaded even when using a subtree.
> [OTOH, #+title is changed in subtree export]
Hmm, makes sense. I wonder how it was working though.
Thanks a lot.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-latex: default packages cleaning
On Wed, Jul 08, 2015 at 08:35:28PM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> >> +(defun org-latex-guess-polyglossia-language (header info)
> >> + "Set the Polyglossia language according to the LANGUAGE keyword.
> >
> > I'm in two-minds about this. On the one had it is a nice thing, but on
> > the other hand, it prevents the more fine grained control offered by
> > polyglossia. For example, I used this in my setup before:
> >
> > \setdefaultlanguage[variant=british]{english}
>
> The attached supports Polyglossia better. Note, the last loaded language
> is the main one (as babel). Perhaps org-latex-variant-file-string should
> be less annoying (not a file-variable).
The polyglossia bits work well. The file local variable prompt for
every export is quite annoying though. Same goes for the exported file,
opening it brings up the same prompt again. I guess it is a one time
thing to mark that variable as safe, then it should be good.
I have a few other questions:
- how does one change the variant when doing a subtree export? By
setting EXPORT_LATEX_VARIANT?
- Is it possible to set a default variant?
- How does one insert a line in the package list which is not
usepackage. I guess the normal case is still valid:
"\\somedirective", but inserting a similar variant specific directive
isn't possible.
I'm starting to wonder, all these complications, is it really worth it?
What do you think?
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-koma bug in subtree export
Hi,
On Thu, Jul 16, 2015 at 12:47:29AM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > Something like that would be a lot more logical indeed.
>
> The attached patch allows the Romeo letter to have a heading like this:
>
> * Yours truly,:closing:
> Romeo of House Capulet
>
> Outputting:
>
> \setkomavar{signature}{Romeo of house Capulet}
> ...
> \closing{Yours truly,}
The closing bit works well, the signature however does not work for me.
Do I need any special config to enable it?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] ox-koma bug in subtree export
On Thu, Jul 16, 2015 at 11:40:06AM +0200, Rasmus wrote: > Suvayu Ali writes: > > > The closing bit works well, the signature however does not work for me. > > Do I need any special config to enable it? > > Maybe it was not robust enough. Try this patch. [...chomp...chomp...chomp...] > * Yours truly, > :closing: > Romeo of house Montague Strange, I tried subtree export with my example, and a normal file export with yours, neither exports the signature, closing works fine. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-koma bug in subtree export
On Thu, Jul 16, 2015 at 12:44:26PM +0200, Rasmus wrote: > Suvayu Ali writes: > > > Strange, I tried subtree export with my example, and a normal file > > export with yours, neither exports the signature, closing works fine. > > I think I didnt't run format-patch correctly Sorry! I'm trying to > get used to do things that I'd normally do from the terminal (like > format-patch) from magit. No worries. > > I checked and it work from your previous example. Worked nicely for both examples, normal export and subtree export. :) -- Suvayu Open source is the future. It sets us free.
Re: [O] ox-koma bug in subtree export
On Thu, Jul 16, 2015 at 10:20:27PM +0200, Rasmus wrote: > Suvayu Ali writes: > > >> I checked and it work from your previous example. > > > > Worked nicely for both examples, normal export and subtree export. > > Pushed in a9855380931885d0dbfcbb8fcc6622850ac4bbda. The Worg page is also > updated. Thanks! -- Suvayu Open source is the future. It sets us free.
Re: [O] basename of exported subtree?
On Mon, Jul 20, 2015 at 09:58:26AM -0400, Matt Price wrote: > Is it possible to set the basename of an exported subtree to something > *other* than the name of the parent file -- to, say, the subtree headline, > or some property thereof? Thank you! Doesn't setting the EXPORT_FILE_NAME property work? -- Suvayu Open source is the future. It sets us free.
Re: [O] basename of exported subtree?
Hi Matt, On Mon, Jul 20, 2015 at 02:12:17PM -0400, Matt Price wrote: > > Neither of these changed the actual file name, but Suvayu's euggestion -- > setting the EXPORT_FILE_NAME property -- did the trick. Thank you both! I > was unable to find this in the org documentation on my own, though now that > I am able to search it I find that it is listed in 12.3, export settings. The first guess for most subtree export properties is, prepend EXPORT_ to whatever was the keyword for a normal export. So you can have, EXPORT_TITLE, EXPORT_AUTHOR, EXPORT_OPTIONS, etc. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] meta commands and Info manual
On Mon, Jul 20, 2015 at 06:08:56PM -0400, Nick Dokos wrote: > Or maybe showing the indirection explicitly: > > ‘M-S- (org-shiftmetaright) --> (org-table-insert-column)’ Particularly this suggestion would be very helpful, even for long time Org users such as myself. -- Suvayu Open source is the future. It sets us free.
Re: [O] meta commands and Info manual
On Tue, Jul 21, 2015 at 10:26:15PM -0400, Nick Dokos wrote: > > For my part I'm happy (and I suspect Suvayu is as well), so I > guess it's back to the OP: what, if anything, should be > changed? Indeed! I happily shut up :). As to the OP, the discussion towards the end of this section should cover the subtlety for a new user, (info "(org) Conventions"). WDYT? -- Suvayu Open source is the future. It sets us free.
Re: [O] [DEV] Bump Emacs requirement to 24.4?
On Wed, Aug 05, 2015 at 09:39:19PM +0200, Nicolas Goaziou wrote: > Hello, > > Just to be sure, can we require Emacs 24.4 for development version > (a.k.a. Org 8.4)? As a data point, Debian stable provides it. > > Also, what is the status of XEmacs support? AFAIU Org 8.3 doesn't build > on XEmacs but no one is complaining. We may as well drop it and ignore > most of "org-compat.el". Agreed to both :). -- Suvayu Open source is the future. It sets us free.
[O] Exporting multiple images in a float (LaTeX)
Hi,
Is there an easy way to export multiple images wrapped in a single
floating environment (e.g. figure) when exporting to LaTeX? For how
many years I have been doing this:
#+name: fig:myfig1
#+caption: This is a single figure, entered in the usual way.
file:myfig1.pdf
#+begin_latex
\begin{figure}[htb]
\centering
\includegraphics[width=0.8\linewidth]{myfig2.pdf}
\includegraphics[width=0.8\linewidth]{myfig3.pdf}
\caption{\label{fig:myfig23} Two images in one floating environment.}
\end{figure}
#+end_latex
It would be great if I could avoid the LaTeX block for the second case.
An intuitive way might be, when two figures are not separated by empty
lines, treat them as part of the same float. The above would translate
to:
#+name: fig:myfig23
#+caption: Two images in one floating environment.
#+attr_latex: :width 0.8\linewidth
file:myfig2.pdf
file:myfig3.pdf
Presently the above is exported as:
\begin{figure}[htb]
\centering
\includegraphics[width=.8\linewidth]{myfig2.pdf}
\caption{\label{fig:myfig23} Two images in one floating environment.}
\end{figure}
\begin{figure}[htb]
\centering
\includegraphics[width=.8\linewidth]{myfig3.pdf}
\caption{\label{fig:myfig23} Two images in one floating environment.}
\end{figure}
Actually, the above could probably be considered incorrect. The figures
have the same caption and labels, which is for all practical purposes
incorrect. Am I missing something? Is my "expectation" reasonable?
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [OFF TOPIC] almost giving up on emacs email..looking for advice?
On Thu, Aug 06, 2015 at 08:21:15PM +0300, Xebar Saram wrote: > thank so much everyone for your great tips and comments > > you gave me more energy to further pursue gnus and or mu4e There is also notmuch. In fact, notmuch seems to have an edge over mu4e when it comes to performance, at least that's my understanding. I would like to say something though. I think you should not blindly keep on trying all these options, that would probably end up in frustration all over again. First you need to answer, how you use email, how do you want to access it, and what kind of features do you want. You shouldn't limit yourself to Emacs either. Eventhough Emacs can do many things, often there are other tools which are better suited. - Email could be a means for discussions, in that case it's a reference - Then you might want searchability, or someway to refer back to messages. - It could be a todo list for you, in that case you want some way to filter and carry over your emails to your todo lists. - Do you want filtering for other purposes? - You might want access to your emails over IMAP (it's immediate), or available locally (always there, not immediate). - Local disk space constraints. - Do you want access to your emails from multiple interfaces? - Do you prefer using the terminal or a GUI? As you see, there are lots of points to think about. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] 8.3 hangs
On Thu, Aug 06, 2015 at 06:42:49PM -0700, Samuel Wales wrote: > just now occurred when refiling from remember subtree to other agenda > files. maybe i did a ^G or an isearch or both. > > Error running timer `org-element--cache-sync': (wrong-type-argument > integer-or-marker-p nil) > > > On 8/6/15, Samuel Wales wrote: > > nothing special stands out as something i can try to keep doing to > > make it occur. > > > > On 8/6/15, Nicolas Goaziou wrote: > >> Do these errors start to appear a short while after you do something > >> typical in your workflow (e.g., sorting a table)? > > If it is a cache issue, you can try this minor mode from Nicolas. It helped me file a more useful cache related bug report. https://github.com/suvayu/.emacs.d/blob/master/lisp/org-element-debug.el -- Suvayu Open source is the future. It sets us free.
Re: [O] Exporting multiple images in a float (LaTeX)
Hi Rasmus,
On Fri, Aug 07, 2015 at 12:31:37AM +0200, Rasmus wrote:
> Rasmus writes:
> > Suvayu Ali writes:
> >
> >> #+name: fig:myfig1
> >> #+caption: This is a single figure, entered in the usual way.
> >>
> >> file:myfig1.pdf
> >>
> >> #+begin_latex
> >> \begin{figure}[htb]
> >> \centering
> >> \includegraphics[width=0.8\linewidth]{myfig2.pdf}
> >> \includegraphics[width=0.8\linewidth]{myfig3.pdf}
> >> \caption{\label{fig:myfig23} Two images in one floating environment.}
> >> \end{figure}
> >> #+end_latex
> >
> >
> > You should probably use subcaption for that. If so see maybe here:
> >
> > http://thread.gmane.org/gmane.emacs.orgmode/92820
I usually don't need multiple captions, just one caption for a float
with multiple very closely related images.
> > For archiving the above you could just use a special block
> >
> > #+caption: foo
> > #+attr_latex: :options [htb]
> >
> > #+begin_figure
> > [[file:fig2.png]]
> > [[file:fig3.png]]
> > #+end_figure
This is very nice, thank you! I think this will do it for me. I have a
small question, is there a better way to add a % after the first image
in the above case other than adding a snippet?
#+begin_figure
#+attr_latex: :width 0.45\linewidth
[[file:myfig2.pdf]]@@l:%@@
[[file:myfig3.pdf]]
#+end_figure
> Also, note that :float nil now handles captions and that you should be
> able to give arbitrary citations commands. Thus, you should be able to
> recreate any old latex structure for images.
I'm not sure I understand the comment about arbitrary citation commands.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] What is the best way to set #+DATE to today's date?
On Thu, Aug 06, 2015 at 01:00:31PM -0400, Kaushal wrote: > > Why don't you just use a timestamp? > > But that would need me to insert the timestamp manually each time before > exports > > > You can update whenever you want or using > >(org-insert-time-stamp (current-time)) > > at the right spot. > > Wouldn't that too need manual navigation to #+date: and then eval that > elisp form? Why are you setting it if you want it to be today? If no DATE field is set, date is today, at least for LaTeX export. -- Suvayu Open source is the future. It sets us free.
Re: [O] Exporting multiple images in a float (LaTeX)
On Fri, Aug 07, 2015 at 02:28:58PM +0100, Eric S Fraga wrote: > On Friday, 7 Aug 2015 at 06:24, Suvayu Ali wrote: > > [...] > > > This is very nice, thank you! I think this will do it for me. I have a > > small question, is there a better way to add a % after the first image > > in the above case other than adding a snippet? > > > > #+begin_figure > > #+attr_latex: :width 0.45\linewidth > > [[file:myfig2.pdf]]@@l:%@@ > > [[file:myfig3.pdf]] > > #+end_figure > > If you want the % simply to have LaTeX ignore the line end, you could > put the figures on the same line, such as > > #+begin_figure > #+attr_latex: :width 0.45\linewidth > [[file:myfig2.pdf]][[file:myfig3.pdf]] > #+end_figure Cool, that works :). Thanks a lot Eric. -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH] Re: What is the best way to set #+DATE to today's date?
On Fri, Aug 07, 2015 at 10:01:42AM -0400, Kaushal wrote:
> @Fabrice Thanks for sharing your examples!
>
> @Suvayu I tried removing #+DATE: line.. but with that I don't see the date
> stamp in html exports. The advantage of {{{time(FORMAT)}}} is that I can
> also control the formatting of the date-time stamp.
I just tested it, I get the following at the end of the exported html
document:
Author: Suvayu Ali
Created: 2015-08-07 Fri 16:14
http://validator.w3.org/check?uri=referer";>Validate
I don't know any html, were you expecting something else? About the
format, take a look at org-time-stamp-custom-formats and
org-time-stamp-formats; eventhough they are for timestamps in the
document, maybe they honour the document creation timestamp.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Exporting multiple images in a float (LaTeX)
On Fri, Aug 07, 2015 at 04:23:48PM +0200, Rasmus wrote:
> Suvayu Ali writes:
> > On Fri, Aug 07, 2015 at 02:28:58PM +0100, Eric S Fraga wrote:
> >> On Friday, 7 Aug 2015 at 06:24, Suvayu Ali wrote:
> >>
> >> > This is very nice, thank you! I think this will do it for me. I have a
> >> > small question, is there a better way to add a % after the first image
> >> > in the above case other than adding a snippet?
> >> >
> >> > #+begin_figure
> >> > #+attr_latex: :width 0.45\linewidth
> >> > [[file:myfig2.pdf]]@@l:%@@
> >> > [[file:myfig3.pdf]]
> >> > #+end_figure
> >>
> >> If you want the % simply to have LaTeX ignore the line end, you could
> >> put the figures on the same line, such as
> >>
> >> #+begin_figure
> >> #+attr_latex: :width 0.45\linewidth
> >> [[file:myfig2.pdf]][[file:myfig3.pdf]]
> >> #+end_figure
> >
> > Cool, that works :). Thanks a lot Eric.
>
> I guess there would also be no loss from actually inserting a "%" after
> \includegraphics[·]{·} in ox-latex.
I would agree with that :).
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Exporting multiple images in a float (LaTeX)
On Fri, Aug 07, 2015 at 05:19:18PM +0100, Eric S Fraga wrote:
> On Friday, 7 Aug 2015 at 16:23, Rasmus wrote:
>
> [...]
>
> > I guess there would also be no loss from actually inserting a "%" after
> > \includegraphics[·]{·} in ox-latex.
>
> Except that then the suggestion I just made would not work and would in
> fact be quite confusing as the second figure would be lost in the
> export?
True, I guess the question is which is more natural.
file:foo.pdf
file:bar.pdf
or,
[[file:foo.pdf]] [[file:bar.pdf]]
One thing I can think of, the second option can be confusing in the Org
buffer when you do not want the space in between.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Beamer environment properties highlighting and shortcut
On Fri, Aug 07, 2015 at 05:40:55PM -0500, John Hendy wrote: > > It states that =C-c C-b= will prompt for beamer specific headlines; > this does not appear to work with the new ox-beamer export engine. I > see the command is =org-beamer-select-environment=. Did this get > mapped to something else now? This requires you to enable the `org-beamer-mode'. [...] > I noted that B_col creates some sort of special fontification (see > attached screenshot), but does not create columns. =beamer_col= *does* > work, but is not syntax highlighted as special in any way. Probably a left over from the old days. -- Suvayu Open source is the future. It sets us free.
Re: [O] Exporting multiple images in a float (LaTeX)
On Sat, Aug 08, 2015 at 09:23:57PM +0200, Rasmus wrote:
> Eric S Fraga writes:
>
> > On Friday, 7 Aug 2015 at 16:23, Rasmus wrote:
> >
> > [...]
> >
> >> I guess there would also be no loss from actually inserting a "%" after
> >> \includegraphics[·]{·} in ox-latex.
> >
> > Except that then the suggestion I just made would not work and would in
> > fact be quite confusing as the second figure would be lost in the
> > export?
>
> But we can insert "%\n" and in the latex end there's no difference between
>
> \includegraphics[]{}%
> \includegraphics[]{}%
>
> And
>
> \includegraphics[]{}\includegraphics[]{}%
>
> To the best of my knowledge.
I think you are correct!
--
Suvayu
Open source is the future. It sets us free.
Re: [O] 8.3.1 and org-latex-with-hyperref
On Sat, Aug 08, 2015 at 03:04:52PM -0400, Scott Randby wrote:
> On 08/08/2015 02:50 PM, Rasmus wrote:
> >Scott Randby writes:
> >
> >>Sorry for the noise, I figured out how to prevent the automatic
> >>insertion of \hypersetup{...} by deleting the settings for
> >>org-latex-hyperref-template
> >
> >I'm curious to know what you are missing in org-latex-hyperref-template?
> >What do you need in order to use the provided method?
>
> Nothing is missing. I had difficulties with the default \hypersetup{...}
> with an old version of org, and my habit became to use my own
> \hypersetup{...} instead. Since I now have a huge number of documents with
> my own setup, it isn't worth it to go and change all of them.
If I understand hyperref correctly, I think it is okay to have multiple
\hypersetup{...} commands, and the last one has precedence. So in the
future, you could simply put yours after the one generated by Org.
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] 8.3.1 and org-latex-with-hyperref
On Sun, Aug 09, 2015 at 09:06:27AM -0400, Scott Randby wrote:
> On 08/09/2015 03:54 AM, Suvayu Ali wrote:
> >
> >If I understand hyperref correctly, I think it is okay to have multiple
> >\hypersetup{...} commands, and the last one has precedence. So in the
> >future, you could simply put yours after the one generated by Org.
>
> Unfortunately, the \hypersetup{...} generated by org is last one in the
> preamble when an org document is exported.
Indeed, you are right.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [OFF TOPIC] almost giving up on emacs email..looking for advice?
On Tue, Aug 11, 2015 at 02:35:57PM +0200, Nicolas Richard wrote: > Peter Davis writes: > > 2) I need a decent editor for replies. I have not found a > > browser-based client that has this. > > > Firefox has an extension, > https://addons.mozilla.org/fr/firefox/addon/its-all-text/, which allows > you to edit any text in your favourite editor (aka emacs) with > emacsclient. Doesn't work anymore with Gmail. https://github.com/docwhat/itsalltext/issues/36 -- Suvayu Open source is the future. It sets us free.
Re: [O] Stable releases
On Tue, Aug 11, 2015 at 02:33:18PM -0400, Ista Zahn wrote:
> On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby wrote:
> >
> > I guess what I want to know, and maybe there is no answer, is how long
> > should I wait before upgrading to a stable release?
>
> One strategy is keeping an eye on the mailing list and waiting for bug
> reports to die down before upgrading.
I would like to add, the community always needs help, and writing code
is not the only way to do that. From your message it seems to me you
have a rather elaborate use for Org. It might serve as a great test
case. If you follow the list regularly, then you could help by testing
the maint branch from time to time (or even master, up to you).
You do not need to know how to use git, you have two options:
- simply download the tarballs from the gitweb interface (see the
"snapshot" links, http://orgmode.org/w/org-mode.git),
- use elpa (either GNU, Org's own)
As for git, I have included the bash function I use to update Org once a
week. If you are interested, feel free to ask me Git questions
off-list.
function update_org() {
pushd ~/build/org-mode # my Org repo and install directory
local dorebase=$(git rev-list origin/master..master|wc -l)
git stash
git checkout master
if [[ $dorebase -gt 0 ]]; then
git pull --rebase --stat
else
git pull
fi
if [ $? == 0 ]; then
echo "+++ Check if merged successfully. +++"
echo "==> Want to continue?"
select yesorno in "Yes" "No"; do
case $yesorno in
Yes)
echo "+++ Building Org-mode $(git branch|egrep '\*')
+++";
make compile autoloads info "$@" &> log
[ $? -ne 0 ] && echo "+++ Build failed
+++" && break;
echo "+++ Installing Info files +++";
make install-info
break;;
No)
echo "Aborting on user command.";
break;;
*)
echo "==> Choose Yes or No by typing 1 or 2."
esac
done
else
echo "Merge failed, aborting."
fi
popd
}
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
