Re: [O] [LaTeX Export] Question: How to import a really long caption in #+CAPTION:
Hi Thomas;
Your solution is exactly what I want.
I am sorry, I was talking about the line break in the Emacs buffer.
Thanks a lot!
Best Regards,
S.
On Thu, Jun 2, 2011 at 3:00 AM, Thomas S. Dye wrote:
> Sunny Srivastava writes:
>
> > Dear org-mode users:
> >
> > I want to export a really long caption in org to latex export.
> >
> > For example:
> >
> > #+CAPTION: A_really_long_caption_that_really_needs_a_line_break
> > #+LABEL: fig:sims
> >
> > Presently, I can do it by just having the really long line in front of
> > #+caption; if I have a line break, it is not exported as a caption. From
> > worg, I know I can use:
> >
> > #+LaTeX: \caption{ }
> >
> > But I was wondering if there is a org-mode way of doing this.
> >
> > Thanks in advance for your help.
> >
> > Best Regards,
> > S.
> > Dear org-mode users:I want to export a really long caption in org to
> latex export.For example:#+CAPTION:
> A_really_long_caption_that_really_needs_a_line_break#+LABEL:
> fig:simsPresently, I can do it by just having the really long line in front
> of #+caption; if I have a line break, it is not exported as a caption. From
> worg, I know I can use:
> > #+LaTeX: \caption{ }But I was wondering if there is a org-mode way
> of doing this.Thanks in advance for your help.Best Regards,S.
>
> Aloha Sunny,
>
> I can't tell from your post what problem you've run into. I can export
> long captions without problems, e.g.:
>
> #+CAPTION: [Polynesian colonization of Hawai`i]{Posterior probability
> for Polynesian colonization of Hawai`i: \textit{left}, estimate based
> on inequality (\ref{eq:no-rat}), with a 95\% highest posterior density
> region of AD 810--1289; \textit{right}, estimate based on inequality
> (\ref{eq:rat}), with a 95\% highest posterior density region of AD
> 780--1119.}
>
> This all resides in one line in the org-mode file. Why does your
> caption need a line break?
>
> All the best,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>
Re: [O] export problems
On Tue, May 31, 2011 at 9:32 AM, Eric Abrahamsen wrote: > Export has recently stopped working for me: any C-c C-e gives me: > > org-export: Symbol's function definition is void: > internal-temp-output-buffer-show > > Instead of an export menu. Org is up to date git, and I get this even > starting with emacs -Q. I haven't seen a chorus of complaints here, so I > assume it still has to be me, somehow, but does anyone know why this > would be happening? I'm on Ubuntu Natty, running: > > GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-04-04 > on rothera, modified by Debian > No issues on GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-04-30 on noorul Org-mode version 7.5 (release_7.5.321.g363a) Thanks and Regards Noorul
Re: [O] [PATCH] latex export - title placement
Sebastian Hofer wrote:
> At Thu, 02 Jun 2011 11:57:07 -0400,
> Nick Dokos wrote:
> >
> > > At Wed, 01 Jun 2011 18:05:28 -0400,
> > > Nick Dokos wrote:
> > > >
> > > > An empty
> > > >
> > > > #+AUTHOR:
> > > >
> > > > disables the insertion of author (assuming that TITLE is not empty -
> > > > see below.)
> > > >
> > > >
> > > > > > - with-date (wdate)
> > > >
> > > > An empty
> > > >
> > > > #+DATE:
> > > >
> > > > disables the insertion of date (same assumption.)
> > > >
> > > > > > - with-maketitle (wmtitle)
> > > >
> > > > An empty
> > > >
> > > > #+TITLE:
> > > >
> > > > disables the insertion of \maketitle.
> > >
> > > To be honest, I didn't try setting empty author and date (which of
> > > course makes sense) I just tried not setting them at all, which gives
> > > default values. The main reason I submitted this patch, however, is
> > > having better control of \maketitle. Personally I would like to be
> > > able to have the title and author at the beginning of the file, just
> > > for the looks, and still be able to produce a customized title. Of
> > > course it is highly debatable if this is a sound reason to introduce
> > > new options (I would argue yes).
> > >
> >
> > Before anybody else wastes their time on this: I'm not sure whether I
> > was in an alternative universe yesterday, or I am in one today, but
> > I can't even reproduce my own results. I'll start again and try to get it
> > right this time, but I'm not going to be able to do that immediately.
> >
> > Apologies for the confusion.
>
> Concerning confusion: What I actually wanted to say above was that the
> main focus of the patch was to provide means for controlling the
> placement of \author, \date, \email etc., not \maketitle.
>
> Apologies for the confusion :)
>
OK, let me restate my current conclusions (or confusions, as the case may be).
First, I have to correct the empty cases:
o an empty #+TITLE: generates a \title{} (in the preamble currently)
but does not generate a \maketitle.
o an empty #+AUTHOR generates an \author{}.
o an empty #+DATE generates a \date{}.
I don't know what I was smoking yesterday, but I was definitely hallucinating.
Then the absent cases:
o an absent #+TITLE: generates a \title{foo} where "foo" is
heuristically obtained either from the buffer (it grabs the first
"text" (i.e. not starting with | or #) line before the first
headline - this seems a somewhat random heuristic to me) or from the
filename.
o an absent #+AUTHOR generates an \author{foo} where foo is generated
from the user-full-name variable (and optionally additional email info).
o an absent #+DATE: generates a \date{\today}.
The author info can be suppressed by using
#+OPTIONS: author:nil
but the other two cannot - if Sebastian wants to modify his patch,
suppressing these two might be useful. For a model to imitate, look
for :auth-info in org-exp.el and org-latex.el, and add e.g. :title-info
and :date-info. I would make them generic, not specific to latex. Only
the latex exporter will use them to begin with, but the other exporters
can do so in the future.
I hope that I have described things correctly, but I'd be happy to
get corrections.
OTOH, none of this is necessary for revtex4-1. The main constituent of
the solution to that problem is that \maketitle is not hardcoded into
the latex exporter: it is instead the value of the variable
org-export-latex-title-command. By redefining this variable, you can put
all the frontmatter stuff where revtex wants it. That does not solve the
whole problem since the exporter puts frontmatter stuff in the preamble as
well and revtex chokes on that. So here's the plan:
- you have a file, ff2.tex, with the front page stuff: \title, \author,
\affiliation etc.
- you have a file, abstract2.tex, with the abstract - this is not
strictly necessary, but I like the separation of the two files
and it's as easy to deal with two files as it is to deal with one.
- you redefine the above variable to be
"\\input{ff2}\\input{abstract2}\\maketitle", so that they all end up
inside the document body and revtex is happy - well, almost.
- there is still the matter of all the stuff (\title, \author, \date)
that the exporter puts in the preamble. But since they are all
redefined later, they don't matter.
- except that revtex still chokes on them because they are in the
"wrong" place. But that is easily dealt with, with the revtexbug.sty
trick I sent out yesterday.
Originally, I had the two files above (then named ff.tex and abstract.tex)
as separate files, but since you mentioned that you were tangling them, I
assume you wanted everything in the same file. So I tacked on the "2" suffix
to distinguish the tangled files from the originals.
Here's the org file:
--8<---cut here---start->8---
#+LaTeX_CLASS: revtex4-1
#+TITLE: foo
#+OPTIONS: author:nil
#+LaTeX_HEADER: \usepackage{revt
Re: [O] Orgmode LaTeX export special character in Title
Xin Shi wrote: > If I want to export to LaTeX with the math symbols in the title: > > #+TITLE: This is a test for $D$ > > I get the $D$ in the PDF. Are there any way to let it behave the same as in > the body for the title? > This works fine here: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) Org-mode version 7.5 (baseline.263.gcf708) Carsten pushed a fix back in November of last year. If your org-mode is older, it's time to upgrade. NB: it's probably a better practice to use the \(...\) inline math delimiters instead of $...$ Nick
[O] Orgmode LaTeX export special character in Title
Hello, If I want to export to LaTeX with the math symbols in the title: #+TITLE: This is a test for $D$ I get the $D$ in the PDF. Are there any way to let it behave the same as in the body for the title? Thanks! Xin
[O] completion of a tag in org-contacts
Hi-- So there is something I don't understand. If I set a tag for an individual in my org-contacts file like so ** Dave Null :dumb: :PROPERTIES: :EMAIL: d...@null.com :END: (I'm stealing this from Julien's homepage) and then I type +dumb followed by in the To: field in message mode, it completes to look like this: To: +dumb:; Dave Null But I don't want the "+dumb:;" part in the To: field when I actually send the mail (I get fussed at by smtp or what have you...) I must by missing something silly...?! thanks, gm -- George McNinch http://gmcninch.math.tufts.edu
[O] org-contacts can deal with alias?
Hi! I've been using org-contacts as a replacement of BBDB and I think is great, but I haven't found a way to use alias instead of names, like BBDB. Is this possible? Thanks! -- Rodrigo Lazo
Re: [O] [bug, babel] export corruption bug and 3 more bugs
Samuel Wales writes: > On 2011-06-02, Eric Schulte wrote: >> Please let me know if the problem remains. Now that this thread is >> on >> my radar I should be more attentive to it. > > Thanks Eric, David. Test case and .emacs seem to work for it so far. > Great, thanks for confirming. > > To anybody: I noticed that the region stays active after export. Is > this intentional? > I have no idea, but it seems to me it is better to preserve the active region than eliminate it. Best -- Eric > > Thanks. > > Samuel -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Problem with make and autoloads
Matt Lundin writes: > They are the default values (i.e., I have not changed anything). [...] > Note: I do not run "make install". My normal routine is to run "make > clean && make". Yes, I noted this, I was just poking around to see where the build process might pick up that extra "lisp/" in org-install. On another note, where is that org-install located? Could it be you have maybe two of them and Emacs picks up the wrong one? The end of the make should look something like this (watch the linewraps: emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"<<$lispdir>>\" load-path)))" --eval "(require 'autoload)" \ --eval '(find-file "org-install.el")' \ --eval '(erase-buffer)' \ --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote (lisp/org.el <<...>> lisp/ob-scheme.el)))' \ --eval '(insert "\n(provide (quote org-install))\n")' \ --eval '(save-buffer)' Loading vc-git... Generating autoloads for lisp/org.el... ... Saving file <<.>>/org-install.el... Wrote <<.>>/org-install.el mv org-install.el lisp ^^^maybe the file is not moved at all or can't be deleted? emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"<<$lispdir>>\" load-path)))" -f batch-byte-compile lisp/org-install.el Wrote <<...>>/lisp/org-install.elc If this does not happen after you've removed both org-install.el and org-install.elc and then do another make, then somethings is very wrong. My guess is that you have a stray org-install.el in <<.>> (make clean probably should remove it both here and in ./lisp, but doesn't). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] [bug, babel] export corruption bug and 3 more bugs
On 2011-06-02, Eric Schulte wrote: > Please let me know if the problem remains. Now that this thread is on > my radar I should be more attentive to it. Thanks Eric, David. Test case and .emacs seem to work for it so far. To anybody: I noticed that the region stays active after export. Is this intentional? Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com I support the Whittemore-Peterson Institute (WPI) === Extreme bigotry against people with deadly serious diseases is still extreme bigotry.
Re: [O] Links and visual-line-mode
Hi all, Scott Randby wrote: >>> One reason I want pop-up-windows to be set to nil is because I >>> frequently use C-x C-b to look at the buffer list. If pop-up-windows is >>> set to t, then C-x C-b opens the buffer list in a pop-up window while >>> the active cursor is in the other window. This is ridiculous. Just on that one point, a trick read in "Emacs Lisp programming" IIRC: #+begin_src emacs-lisp ;; rebind `C-x C-b' (global-set-key (kbd "C-x C-b") 'buffer-menu) ;; `buffer-menu' moves point in the window which lists your buffers #+end_src Best regards, Seb -- Sebastien Vauban
Re: [O] Links and visual-line-mode
Carsten Dominik wrote: > > On 2.6.2011, at 18:41, Nick Dokos wrote: > > > Carsten Dominik wrote: > > > > > >> Thanks Nick. Seems like Emacs is not sure in which > >> buffer it is at that moment, because it has not yet been displayed. > >> Could you please try to following paranoid patch? > >> > >> Thanks. > >> > >> - Carsten > >> > >> diff --git a/lisp/org.el b/lisp/org.el > >> index 1ca03f4..b43a877 100644 > >> --- a/lisp/org.el > >> +++ b/lisp/org.el > >> @@ -8889,7 +8889,8 @@ Use TAB to complete link prefixes, then RET for = > >> type-specific completion support > >> (reverse org-stored-links) "\n" > >> (let ((cw (selected-window))) > >>(select-window (get-buffer-window "*Org Links*" 'visible)) > >> - (setq truncate-lines t) > >> + (with-current-buffer "*Org Links*" > >> +(set (make-local-variable 'truncate-lines) t)) > >>(unless (pos-visible-in-window-p (point-max)) > >> (org-fit-window-to-buffer)) > >>(and (window-live-p cw) (select-window cw))) > >> > > > > Both this and the simpler > > > >> - (setq truncate-lines t) > >> + (with-current-buffer "*Org Links*" > >> +(setq truncate-lines t)) > > > > seem to work in my simple test. > > OK, I pushed your version. > The test is still passing, so I guess things are OK. Thanks, Nick
Re: [O] "git describe" in version of info file with "make info_git_describe"
The patch is ready and attached. Michael On Thu, Jun 2, 2011 at 17:05, Michael Brand wrote: [...] > Since I would like to give the more often used "git describe" > precedence I will make org-version and "make info_git_describe" > consistent with git. The ".dirty" postfix of org-version I will leave > untouched in org-version of course and support also in "make > info_git_describe". 0001-Use-git-describe-in-version-of-info-file-with-make-i.patch Description: Binary data
Re: [O] [PATCH] latex export - title placement
At Thu, 02 Jun 2011 11:57:07 -0400, Nick Dokos wrote: > > Sebastian Hofer wrote: > > > At Wed, 01 Jun 2011 18:05:28 -0400, > > Nick Dokos wrote: > > > > > > Thomas S. Dye wrote: > > > > > > > Sebastian Hofer writes: > > > > > > > > > Hi all, > > > > > > > > > > This patch addresses the problem of ambiguous conventions for the > > > > > placement of the title related macros (\author, \date,...) with > > > > > respect to the main document body in different latex classes. It > > > > > introduces the following changes: > > > > > > > > > > * org-exp.el: > > > > > - added the following options: > > > > > - title-position (tpos) > > > > > - with-title (wtitle) > > > > > - with-author (wauth) > > > > > > [This is mostly addressed to Sebastian even though I'm replying to Tom's > > > reply.] > > > > > > An empty > > > > > > #+AUTHOR: > > > > > > disables the insertion of author (assuming that TITLE is not empty - > > > see below.) > > > > > > > > > > > - with-date (wdate) > > > > > > An empty > > > > > > #+DATE: > > > > > > disables the insertion of date (same assumption.) > > > > > > > > - with-maketitle (wmtitle) > > > > > > An empty > > > > > > #+TITLE: > > > > > > disables the insertion of \maketitle. > > > > To be honest, I didn't try setting empty author and date (which of > > course makes sense) I just tried not setting them at all, which gives > > default values. The main reason I submitted this patch, however, is > > having better control of \maketitle. Personally I would like to be > > able to have the title and author at the beginning of the file, just > > for the looks, and still be able to produce a customized title. Of > > course it is highly debatable if this is a sound reason to introduce > > new options (I would argue yes). > > > > Before anybody else wastes their time on this: I'm not sure whether I > was in an alternative universe yesterday, or I am in one today, but > I can't even reproduce my own results. I'll start again and try to get it > right this time, but I'm not going to be able to do that immediately. > > Apologies for the confusion. Concerning confusion: What I actually wanted to say above was that the main focus of the patch was to provide means for controlling the placement of \author, \date, \email etc., not \maketitle. Apologies for the confusion :) Sebastian
Re: [O] [PATCH 1/2] lisp/ob.el: Fix org-babel-result-regexp to match users
Applied, Thanks -- Eric Lawrence Mitchell writes: > * lisp/ob.el (org-babel-result-regexp): Use non-shy group around > org-babel-data-names. > > By default regexp-opt returns a shy group around its arguments. But > users of org-babel-result-regexp expect the third match-string to > contain the hash. With a shy group, the second match-string contains > the hash. > --- > lisp/ob.el |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/lisp/ob.el b/lisp/ob.el > index 27f005c..e1f4372 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -310,7 +310,7 @@ specific header arguments as well.") > > (defvar org-babel-result-regexp >(concat "^[ \t]*#\\+" > - (regexp-opt org-babel-data-names) > + (regexp-opt org-babel-data-names t) > "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*") >"Regular expression used to match result lines. > If the results are associated with a hash key then the hash will -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it
Hi Lawrence, Is there a reason to make this copy? Given that params is used like a hash/dictionary the order of it's elements should not matter. Is there a case where this patch is necessary to avoid buggy behavior? If so then I'm happy to apply the patch, but if there is no need then I'd rather avoid the (admittedly small) overhead of making a copy of the params list. Thanks -- Eric Lawrence Mitchell writes: > * lisp/ob.el (org-babel-sha1-hash): Don't modify info argument by > side-effect when sorting result-params list. > > copy-sequence only does shallow copies, so if we're going to modify a > sub-list, we need to make sure we copy it first. > --- > lisp/ob.el |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/lisp/ob.el b/lisp/ob.el > index e1f4372..36649f0 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -767,7 +767,7 @@ the current subtree." > (cond > ((and (listp v) ; lists are sorted >(member (car arg) '(:result-params))) > - (sort v #'string<)) > + (sort (copy-sequence v) #'string<)) > ((and (stringp v) ; strings are sorted >(member (car arg) '(:results > :exports))) > (mapconcat #'identity (sort (split-string v) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bug, babel] export corruption bug and 3 more bugs
Hi David, Sorry it took me a while to notice this thread -- incidentally after a patch to this effect was shared by Lawrence Mitchell in a separate thread. I've just applied Lawrence's patch, which should resolve this issue as well. Please let me know if the problem remains. Now that this thread is on my radar I should be more attentive to it. Thanks -- Eric David Maus writes: > At Wed, 25 May 2011 09:58:03 -0700, > Samuel Wales wrote: >> >> Minimal .emacs and test case for export corruption bug. > > Okay, I can reproduce the args out of range with Emacs 22. Turns out > that `regexp-opt` behaves different when creating > `org-babel-result-regexp'. > > (regexp-opt org-babel-data-names) > > encloses the regexp for babel data names in a shy grouping construct > in Emacs 23 > > (regexp-opt org-babel-data-names) => > "\\(?:DATA\\|RES\\(?:NAME\\|ULTS\\)\\|TBLNAME\\)" > > While it does not in Emacs 22 > > (regexp-opt org-babel-data-names) => "DATA\\|RES\\(?:NAME\\|ULTS\\)\\|TBLNAME" > > Thus the literal string "results" in the example file is matched by > Org Babel in `org-exp-res/src-name-cleanup'. > > Looks like setting up `org-babel-result-regexp' should do a check for > the Emacs version and explictly add the shy grouping construct if > version < 23 -- I'm really not familar with all the Babel parts so Cc: > Erik Schulte who I assume knows Babel better than me. > > I'll check the other (compatibilty) problems during the weekend. > > Best, > -- David > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber dmj...@jabber.org > Email. dm...@ictsoc.de -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Links and visual-line-mode
On 2.6.2011, at 18:41, Nick Dokos wrote: > Carsten Dominik wrote: > > >> Thanks Nick. Seems like Emacs is not sure in which >> buffer it is at that moment, because it has not yet been displayed. >> Could you please try to following paranoid patch? >> >> Thanks. >> >> - Carsten >> >> diff --git a/lisp/org.el b/lisp/org.el >> index 1ca03f4..b43a877 100644 >> --- a/lisp/org.el >> +++ b/lisp/org.el >> @@ -8889,7 +8889,8 @@ Use TAB to complete link prefixes, then RET for = >> type-specific completion support >>(reverse org-stored-links) "\n" >> (let ((cw (selected-window))) >> (select-window (get-buffer-window "*Org Links*" 'visible)) >> -(setq truncate-lines t) >> +(with-current-buffer "*Org Links*" >> + (set (make-local-variable 'truncate-lines) t)) >> (unless (pos-visible-in-window-p (point-max)) >>(org-fit-window-to-buffer)) >> (and (window-live-p cw) (select-window cw))) >> > > Both this and the simpler > >> -(setq truncate-lines t) >> +(with-current-buffer "*Org Links*" >> + (setq truncate-lines t)) > > seem to work in my simple test. OK, I pushed your version. - Carsten > > Nick >
Re: [O] Links and visual-line-mode
On 06/02/2011 12:41 PM, Nick Dokos wrote: > Carsten Dominik wrote: > > >> Thanks Nick. Seems like Emacs is not sure in which >> buffer it is at that moment, because it has not yet been displayed. >> Could you please try to following paranoid patch? >> >> Thanks. >> >> - Carsten >> >> diff --git a/lisp/org.el b/lisp/org.el >> index 1ca03f4..b43a877 100644 >> --- a/lisp/org.el >> +++ b/lisp/org.el >> @@ -8889,7 +8889,8 @@ Use TAB to complete link prefixes, then RET for = >> type-specific completion support >>(reverse org-stored-links) "\n" >>(let ((cw (selected-window))) >> (select-window (get-buffer-window "*Org Links*" 'visible)) >> -(setq truncate-lines t) >> +(with-current-buffer "*Org Links*" >> + (set (make-local-variable 'truncate-lines) t)) >> (unless (pos-visible-in-window-p (point-max)) >>(org-fit-window-to-buffer)) >> (and (window-live-p cw) (select-window cw))) >> > > Both this and the simpler > >> -(setq truncate-lines t) >> +(with-current-buffer "*Org Links*" >> + (setq truncate-lines t)) > > seem to work in my simple test. I looked at several different scenarios using Nick's solution and they all worked fine. I didn't try Carsten's solution. Scott > > Nick > >
Re: [O] [Orgmode] Re: [Feature Request] Cross headings in tables
On 31.5.2011, at 20:01, Achim Gratz wrote: > Hi Carsten, > > Carsten Dominik writes: >> I think a better strategy would be to find these additional >> header lines right before this section of the recalculate function: > [...] > > I'll have a look (probably not today), but I'd rather tag them with an > "org-header" property and arrange it so that this can be used in other > places as well. This property is not attached to these lines for long - it is just a temporary way of marking fields that should not be overwritten by column formulas. The property is added, and also removed again (I think) during the recalculation process. > >> Another part which might need a look to support this >> would be `orgtbl-to-generic'. > > Noted. > >> Finally: this patch goes clearly beyond the TINYCHANGE >> limits. What is yours, and Lawrence's copyright status with the FSF? > > My status with the FSF is succinctly and fully characterized as > "non-existing". I've sent that mail form to the FSF and I'll see what > happens next — it seems I'll get snail mail in a few weeks? Thank you. Please let us know when the process gets stuck or completes. - Carsten
Re: [O] Links and visual-line-mode
On 2.6.2011, at 17:51, Nick Dokos wrote:
> Carsten Dominik wrote:
>
>>> Yes, with pop-up-windows set to nil, I can reproduce it too.
>>> The problem is that truncate-lines is set to t inside org-insert-link.
>>
>> Yes, but only after the focus was switched to the *Org Link* buffer which is
>> shown in order to select a link. truncate-lines is automatically
>> buffer-local,
>> so it should not effect its value in other buffers. Is truncate-lines
>> modified after inserting a link
>>
>
> Here's what I see with a minimal .emacs and a simple org file (both of them
> appended):
>
> - emacs -Q -l minimal.emacs
> - check truncate-lines: it is nil in the foo.org buffer
> - TAB to expand the heading - I get a wrapped line as expected
> - go to the end, C-c C-l foo bar
> - by the time of the first I am back at the foo.org buffer and the line
> is truncated;
> checking truncate-lines shows it to be t.
Thanks Nick. Seems like Emacs is not sure in which
buffer it is at that moment, because it has not yet been displayed.
Could you please try to following paranoid patch?
Thanks.
- Carsten
diff --git a/lisp/org.el b/lisp/org.el
index 1ca03f4..b43a877 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8889,7 +8889,8 @@ Use TAB to complete link prefixes, then RET for
type-specific completion support
(reverse org-stored-links) "\n"
(let ((cw (selected-window)))
(select-window (get-buffer-window "*Org Links*" 'visible))
- (setq truncate-lines t)
+ (with-current-buffer "*Org Links*"
+ (set (make-local-variable 'truncate-lines) t))
(unless (pos-visible-in-window-p (point-max))
(org-fit-window-to-buffer))
(and (window-live-p cw) (select-window cw)))
>
> Nick
>
> GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
> 2011-04-13
> Org-mode version 7.5 (baseline.261.g3433)
>
> minimal.emacs:
> --8<---cut here---start->8---
> ;;; -*- mode: emacs-lisp -*-
> ;;; constant part
> (add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/lisp"))
> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" .
> org-mode))
> (require 'org-install)
> (global-set-key "\C-cl" 'org-store-link)
> (global-set-key "\C-ca" 'org-agenda)
>
> (setq org-startup-truncated nil)
> (setq pop-up-windows nil)
> (setq-default truncate-lines nil)
> (find-file "~/src/org/visual/scott-randby/foo.org")
> (visual-line-mode 1)
> --8<---cut here---end--->8---
>
>
> foo.org:
> --8<---cut here---start->8---
>
> * foo
>
> [[foo][bar]]
> bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
> bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
> bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
> bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
> bar bar bar bar bar bar bar bar bar bar
>
> [[foo][bar]] [[foo][bar]]
> --8<---cut here---end--->8---
>
>
Re: [O] Links and visual-line-mode
Carsten Dominik wrote: > Thanks Nick. Seems like Emacs is not sure in which > buffer it is at that moment, because it has not yet been displayed. > Could you please try to following paranoid patch? > > Thanks. > > - Carsten > > diff --git a/lisp/org.el b/lisp/org.el > index 1ca03f4..b43a877 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -8889,7 +8889,8 @@ Use TAB to complete link prefixes, then RET for = > type-specific completion support > (reverse org-stored-links) "\n" >(let ((cw (selected-window))) > (select-window (get-buffer-window "*Org Links*" 'visible)) > - (setq truncate-lines t) > + (with-current-buffer "*Org Links*" > + (set (make-local-variable 'truncate-lines) t)) > (unless (pos-visible-in-window-p (point-max)) > (org-fit-window-to-buffer)) > (and (window-live-p cw) (select-window cw))) > Both this and the simpler > - (setq truncate-lines t) > + (with-current-buffer "*Org Links*" > + (setq truncate-lines t)) seem to work in my simple test. Nick
Re: [O] [PATCH] latex export - title placement
Sebastian Hofer wrote: > At Wed, 01 Jun 2011 18:05:28 -0400, > Nick Dokos wrote: > > > > Thomas S. Dye wrote: > > > > > Sebastian Hofer writes: > > > > > > > Hi all, > > > > > > > > This patch addresses the problem of ambiguous conventions for the > > > > placement of the title related macros (\author, \date,...) with > > > > respect to the main document body in different latex classes. It > > > > introduces the following changes: > > > > > > > > * org-exp.el: > > > > - added the following options: > > > > - title-position (tpos) > > > > - with-title (wtitle) > > > > - with-author (wauth) > > > > [This is mostly addressed to Sebastian even though I'm replying to Tom's > > reply.] > > > > An empty > > > > #+AUTHOR: > > > > disables the insertion of author (assuming that TITLE is not empty - > > see below.) > > > > > > > > - with-date (wdate) > > > > An empty > > > > #+DATE: > > > > disables the insertion of date (same assumption.) > > > > > > - with-maketitle (wmtitle) > > > > An empty > > > > #+TITLE: > > > > disables the insertion of \maketitle. > > To be honest, I didn't try setting empty author and date (which of > course makes sense) I just tried not setting them at all, which gives > default values. The main reason I submitted this patch, however, is > having better control of \maketitle. Personally I would like to be > able to have the title and author at the beginning of the file, just > for the looks, and still be able to produce a customized title. Of > course it is highly debatable if this is a sound reason to introduce > new options (I would argue yes). > Before anybody else wastes their time on this: I'm not sure whether I was in an alternative universe yesterday, or I am in one today, but I can't even reproduce my own results. I'll start again and try to get it right this time, but I'm not going to be able to do that immediately. Apologies for the confusion. Nick
Re: [O] Links and visual-line-mode
Carsten Dominik wrote:
> > Yes, with pop-up-windows set to nil, I can reproduce it too.
> > The problem is that truncate-lines is set to t inside org-insert-link.
>
> Yes, but only after the focus was switched to the *Org Link* buffer which is
> shown in order to select a link. truncate-lines is automatically
> buffer-local,
> so it should not effect its value in other buffers. Is truncate-lines
> modified after inserting a link
>
Here's what I see with a minimal .emacs and a simple org file (both of them
appended):
- emacs -Q -l minimal.emacs
- check truncate-lines: it is nil in the foo.org buffer
- TAB to expand the heading - I get a wrapped line as expected
- go to the end, C-c C-l foo bar
- by the time of the first I am back at the foo.org buffer and the line
is truncated;
checking truncate-lines shows it to be t.
Nick
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
2011-04-13
Org-mode version 7.5 (baseline.261.g3433)
minimal.emacs:
--8<---cut here---start->8---
;;; -*- mode: emacs-lisp -*-
;;; constant part
(add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/lisp"))
(add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
(require 'org-install)
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(setq org-startup-truncated nil)
(setq pop-up-windows nil)
(setq-default truncate-lines nil)
(find-file "~/src/org/visual/scott-randby/foo.org")
(visual-line-mode 1)
--8<---cut here---end--->8---
foo.org:
--8<---cut here---start->8---
* foo
[[foo][bar]]
bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar bar
bar bar bar bar bar bar
[[foo][bar]] [[foo][bar]]
--8<---cut here---end--->8---
Re: [O] "git describe" in version of info file with "make info_git_describe"
On Thu, Jun 2, 2011 at 16:47, Bernt Hansen wrote: > Michael Brand writes: >> Can I remove this substitution of "release_7.5-350-g3433" -> >> "release_7.5.350.g3433" from org-version in my patch or should "make >> info_git_describe" do the same and why? > > Hi Michael, > > This was purely cosmetic. I didn't like the look of the mixed '.' and > '-' in the version number originally. ... and '_' ... :-) > I think the two reported version > numbers should be consistent between the org-version function and the > documentation version function you are proposing. > > If you want to remove the substitution please also do so in the > org-version code so the reported numbers are consistent. Since I would like to give the more often used "git describe" precedence I will make org-version and "make info_git_describe" consistent with git. The ".dirty" postfix of org-version I will leave untouched in org-version of course and support also in "make info_git_describe". Michael
Re: [O] "git describe" in version of info file with "make info_git_describe"
Michael Brand writes: > Hi Bernt, hi all > > I appreciate that org-version adds the output of "git describe" to the > org-version string if we are running > from a git repository. Thanks to Bernt et al: > http://thread.gmane.org/gmane.emacs.orgmode/16620 > > Now I suggest the same for the info file by using the new target "make > info_git_describe" instead of "make info" for all who are running from > a git repository and are not building a release. I am about to finish > a patch for this but before posting it would like to know the reason > for "(subst-char-in-string ?- ?. git-version t)" in org-version here: > http://orgmode.org/w/?p=org-mode.git;a=blob;f=lisp/org.el;h=1ca03f48d86fac71837079f7c3219cb295a9c795;hb=HEAD#l217 > > Can I remove this substitution of "release_7.5-350-g3433" -> > "release_7.5.350.g3433" from org-version in my patch or should "make > info_git_describe" do the same and why? Hi Michael, This was purely cosmetic. I didn't like the look of the mixed '.' and '-' in the version number originally. I think the two reported version numbers should be consistent between the org-version function and the documentation version function you are proposing. If you want to remove the substitution please also do so in the org-version code so the reported numbers are consistent. Regards, -- Bernt
[O] "git describe" in version of info file with "make info_git_describe"
Hi Bernt, hi all I appreciate that org-version adds the output of "git describe" to the org-version string if we are running from a git repository. Thanks to Bernt et al: http://thread.gmane.org/gmane.emacs.orgmode/16620 Now I suggest the same for the info file by using the new target "make info_git_describe" instead of "make info" for all who are running from a git repository and are not building a release. I am about to finish a patch for this but before posting it would like to know the reason for "(subst-char-in-string ?- ?. git-version t)" in org-version here: http://orgmode.org/w/?p=org-mode.git;a=blob;f=lisp/org.el;h=1ca03f48d86fac71837079f7c3219cb295a9c795;hb=HEAD#l217 Can I remove this substitution of "release_7.5-350-g3433" -> "release_7.5.350.g3433" from org-version in my patch or should "make info_git_describe" do the same and why? Michael
Re: [O] Links and visual-line-mode
On 2.6.2011, at 07:58, Nick Dokos wrote: > Scott Randby wrote: > >> On 06/01/2011 10:49 PM, Nick Dokos wrote: >>> Scott Randby wrote: >>> This is a problem that has been bugging me for some time because I use visual-line-mode a lot when I'm working on my org-mode files. Say I have visual-line-mode turned on when I'm editing an org-mode file. If I do C-c C-l, put in the link address, hit , put in a description, and hit , then the long lines in the document are no longer wrapped even though "(Org Wrap)" still appears on the mode line. The only way I've been able to get wrapping back is to do M-x visual-line-mode twice (which is just leaving the mode and then bringing it back. This is very inconvenient, especially when I want to enter several links. Is this a bug or is there an easy way to remind Emacs that it is in visual-line-mode and that it should wrap long lines? I have org-mode 7.5 on Emacs 23.2.1 >>> >>> Cannot reproduce this either on emacs 23.1.1 or emacs 24.0.50 - the only >>> versions I have available here. org-mode is from earlier today. >>> >>> The word-wrap documentation suggests some interaction with >>> truncate-lines and truncate-partial-width-windows, so that might be a >>> path of investigation. But when I try setting truncate-lines to t >>> (which does truncate long lines even though "Wrap" is still on the mode >>> line) and then do (visual-line-mode 1), the variable is set back to nil >>> again. In any case, inserting links does not cause any other changes, no >>> matter what I set the variable to. >> >> In my .emacs, I have pop-up-windows set to nil. If I change that setting >> to t, then visual-line-mode keeps working when C-c C-l is used to insert >> a link. Changing pop-up-windows back to nil causes the bad behavior. >> >> One reason I want pop-up-windows to be set to nil is because I >> frequently use C-x C-b to look at the buffer list. If pop-up-windows is >> set to t, then C-x C-b opens the buffer list in a pop-up window while >> the active cursor is in the other window. This is ridiculous. >> >> I found this message about org-mode and pop-up windows in the mailing >> list archives: >> >> http://lists.gnu.org/archive/html/emacs-orgmode/2009-04/msg00712.html >> >> While the issue described is not the same as mine, the complaint about >> org-mode not playing nice when pop-up-windows is set to nil is still valid. >> > > Yes, with pop-up-windows set to nil, I can reproduce it too. > The problem is that truncate-lines is set to t inside org-insert-link. Yes, but only after the focus was switched to the *Org Link* buffer which is shown in order to select a link. truncate-lines is automatically buffer-local, so it should not effect its value in other buffers. Is truncate-lines modified after inserting a link > When I comment that out, I get the behavior you expect. The question is: > why is truncate-lines set to t? To get just one line per link, so to get a nicely organized selection buffer. - Carsten > I don't know the answer to that, but it > seems to be unnecessary: I think it could be let-bound instead or explicitly > reset to its former value afterwards. > > The problems described by Samuel in the link you provided may be caused > by the same setting, but I haven't looked in detail. > > Nick >
Re: [O] Links and visual-line-mode
On 06/02/2011 01:58 AM, Nick Dokos wrote: > Scott Randby wrote: > >> On 06/01/2011 10:49 PM, Nick Dokos wrote: >>> Scott Randby wrote: >>> This is a problem that has been bugging me for some time because I use visual-line-mode a lot when I'm working on my org-mode files. Say I have visual-line-mode turned on when I'm editing an org-mode file. If I do C-c C-l, put in the link address, hit , put in a description, and hit , then the long lines in the document are no longer wrapped even though "(Org Wrap)" still appears on the mode line. The only way I've been able to get wrapping back is to do M-x visual-line-mode twice (which is just leaving the mode and then bringing it back. This is very inconvenient, especially when I want to enter several links. Is this a bug or is there an easy way to remind Emacs that it is in visual-line-mode and that it should wrap long lines? I have org-mode 7.5 on Emacs 23.2.1 >>> >>> Cannot reproduce this either on emacs 23.1.1 or emacs 24.0.50 - the only >>> versions I have available here. org-mode is from earlier today. >>> >>> The word-wrap documentation suggests some interaction with >>> truncate-lines and truncate-partial-width-windows, so that might be a >>> path of investigation. But when I try setting truncate-lines to t >>> (which does truncate long lines even though "Wrap" is still on the mode >>> line) and then do (visual-line-mode 1), the variable is set back to nil >>> again. In any case, inserting links does not cause any other changes, no >>> matter what I set the variable to. >> >> In my .emacs, I have pop-up-windows set to nil. If I change that setting >> to t, then visual-line-mode keeps working when C-c C-l is used to insert >> a link. Changing pop-up-windows back to nil causes the bad behavior. >> >> One reason I want pop-up-windows to be set to nil is because I >> frequently use C-x C-b to look at the buffer list. If pop-up-windows is >> set to t, then C-x C-b opens the buffer list in a pop-up window while >> the active cursor is in the other window. This is ridiculous. >> >> I found this message about org-mode and pop-up windows in the mailing >> list archives: >> >> http://lists.gnu.org/archive/html/emacs-orgmode/2009-04/msg00712.html >> >> While the issue described is not the same as mine, the complaint about >> org-mode not playing nice when pop-up-windows is set to nil is still valid. >> > > Yes, with pop-up-windows set to nil, I can reproduce it too. > The problem is that truncate-lines is set to t inside org-insert-link. > When I comment that out, I get the behavior you expect. The question is: > why is truncate-lines set to t? I don't know the answer to that, but it > seems to be unnecessary: I think it could be let-bound instead or explicitly > reset to its former value afterwards. I will set pop-up-windows to t for now, but I hope the matter is investigated further to see if truncate-lines must be set to t in org-insert-link or if the code can be changed as you suggest. Thanks for your help. Scott > > The problems described by Samuel in the link you provided may be caused > by the same setting, but I haven't looked in detail. > > Nick >
[O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it
* lisp/ob.el (org-babel-sha1-hash): Don't modify info argument by side-effect when sorting result-params list. copy-sequence only does shallow copies, so if we're going to modify a sub-list, we need to make sure we copy it first. --- lisp/ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index e1f4372..36649f0 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -767,7 +767,7 @@ the current subtree." (cond ((and (listp v) ; lists are sorted (member (car arg) '(:result-params))) - (sort v #'string<)) + (sort (copy-sequence v) #'string<)) ((and (stringp v) ; strings are sorted (member (car arg) '(:results :exports))) (mapconcat #'identity (sort (split-string v) -- 1.7.4.1
[O] [PATCH 1/2] lisp/ob.el: Fix org-babel-result-regexp to match users
* lisp/ob.el (org-babel-result-regexp): Use non-shy group around org-babel-data-names. By default regexp-opt returns a shy group around its arguments. But users of org-babel-result-regexp expect the third match-string to contain the hash. With a shy group, the second match-string contains the hash. --- lisp/ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 27f005c..e1f4372 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -310,7 +310,7 @@ specific header arguments as well.") (defvar org-babel-result-regexp (concat "^[ \t]*#\\+" - (regexp-opt org-babel-data-names) + (regexp-opt org-babel-data-names t) "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*") "Regular expression used to match result lines. If the results are associated with a hash key then the hash will -- 1.7.4.1
Re: [O] [PATCH] latex export - title placement
At Wed, 01 Jun 2011 19:55:51 -0400,
Nick Dokos wrote:
>
> Nick Dokos wrote:
>
> > IIUC, the only remaining thing is the position of the \title etc macros
> > in the preamble or the body (or both).
> >
> > There are three categories of LaTeX classes: the ones that implement
> > Lamport's dictum that \title etc can come anywhere before \maketitle,
> > the ones like RevTeX that insist on having them in the body and the ones
> > like the thesis document class at Suvayu's university, that insist on
> > having them in the preamble. I consider both of the latter two as buggy:
> > has anybody submitted a bug report on them?
> >
>
> I tried an experiment:
>
> I cannot get at the thesis document class at Suvayu's university but I
> most certainly can get to RevTeX. So I started with a simple org file:
>
> ,
> | #+LATEX_CLASS: revtex4-1
> | #+TITLE: foo
> | #+AUTHOR: nick
> | #+DATE:
> |
> | * foo
> |
> | bar
> `
>
>
> I then added a definition for the revtex4-1 class to org-export-latex-classes.
> I just copied the article class and renamed appropriately:
>
> ,
> | ...
> | ("revtex4-1"
> | "\\documentclass[11pt]{revtex4-1}"
> | ("\\section{%s}" . "\\section*{%s}")
> | ("\\subsection{%s}" . "\\subsection*{%s}")
> | ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
> | ("\\paragraph{%s}" . "\\paragraph*{%s}")
> | ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
> | ...
> `
>
>
> Exporting to latex and compiling gives errors, the first one of which says:
>
> ,
> | ...
> | *hyperref using default driver hpdftex*
> | (/usr/share/texmf-texlive/tex/latex/hyperref/hpdftex.def)
> | ! Undefined control sequence.
> | \collaboration@sw
> | {\advance \c@collab \@ne \@argswap {\CO@grp
> \CO...
> | l.21 \author{nick}
> | ...
> `
>
> Basically, \author{nick} got expanded into something involving
> \collaboration@sw which
> is currently undefined. So off to
> /usr/share/texmf-texlive/tex/latex/revtex/revtex4-1.cls
> I went and found the following expansion sequence:
>
>\author -> \frontmatter@author -> \@author@def -> \move@AU ->
> \collaboration@sw -> ...
>
> So let's see where the latter is initialized:
>
> ,
> | \def\collaboration{% implicit #1
> | \@author@def{\@booleantrue\collaboration@sw}% implicit #2
> | }%
> |
> | \appdef\frontmatter@init{%
> | \@booleanfalse\collaboration@sw
> | }%
> |
> | \def\@author@init{%
> | \let\@author\@author@cleared
> | \@booleanfalse\collaboration@sw
> | }%
> `
>
>
> So \collaboration@sw is a boolean (when it is defined) and I gueesed that the
> most likely place
> was the \frontmatter@init macro. So what happens if we call the macro in the
> preamble just before
> the \title, \author and \date junk?
> To do that, create a revtexbug.sty file with the following contents:
>
> --8<---cut here---start->8---
> \makeatletter
> \frontmatter@init
> \makeatother
> --8<---cut here---end--->8---
>
> and modify the org file to
>
> --8<---cut here---start->8---
> #+LATEX_CLASS: revtex4-1
> #+TITLE: foo
> #+AUTHOR: nick
> #+DATE:
>
> #+LATEX_HEADER: \usepackage{revtexbug}
>
> * foo
>
> bar
> --8<---cut here---end--->8---
>
> Export to latex, process and voilà: no errors.
>
> I don't want to pretend of course that this solves the problem: it might
> cause more problems than it solves, particularly since I know nothing about
> revtex and all the above is (more-or-less informed) guesswork.
>
> Nevertheless, it might be worth trying on a real document and seeing if
> it resolves the problem without causing undue misery. If it does, you
> can have a more-or-less permanent solution by just moving the
> revtexbug.sty file to some directory where latex can find it (don't
> forget to run texhash) and use the above as a template. You can probably
> customize the class template to do the \usepackage for you.
>
> Please report back whether it works or not. If it does, maybe you can
> ask the RevTeX maintainers to fix the package: it's much more likely to
> happen if you tell them how to fix it ;-) And we can add an item to the
> FAQ. I just hope that there are no other classes that misbehave this way...
Unfortunately I couldn't get this to work just right now, also not for
the minimal example you provided. I will probably look into it when I
have more time on my hands.
The real problem, however, is a different one: I use the revtex class
to submit research papers to the American Physical Society. And I
don't think they will be happy with me providing my own package which
works around one of the "features" of their own class. So unless we
can get them to fix the class, we (or I for that matter) are out of
luck. I haven't consider reporting this to them as I thought it would
be useless, but of course one could always try...
I sti
[O] Capture Question
I'm trying to start using Capture, and I'd like to set up a template to capture a TODO to go "right here" --- i.e. at the point where the cursor is when I invoke capture. I can do that OK. EXCEPT that it always sets the headline level of the new element to that of a child of the currently clocking task. I'd LIKE to set it to the level for the current location -- so that it fits in "where I am now". Is there a way to do that? Related question: is there a function that will tell me about the entry that I'm currently in? Robert Robert Inder, 0131 229 1052 / 07808 492 213 Interactive Information Ltd, 3, Lauriston Gardens, Edinburgh EH3 9HH Registered in Scotland, Company no. SC 150689 Interactions speak louder than words
[O] Problem with latest stable org-mode - Lisp error: (void-variable outline-regexp)
Hi, I downloaded the latest stable org-mode (Org-mode version 7.5), and installed it to my emacs system. I'm running AquaEmacs, 2.2 (GNU/Emacs 23.3.1). My previous version 6.7 worked fine. When ever I try to load one of my org files, I get this error, Lisp error: (void-variable outline-regexp). My files will only display in Outline mode. Is this a known error, or does anyone have a work around that I could use? -- ~JT
Re: [O] [PATCH] latex export - title placement
At Wed, 01 Jun 2011 18:05:28 -0400,
Nick Dokos wrote:
>
> Thomas S. Dye wrote:
>
> > Sebastian Hofer writes:
> >
> > > Hi all,
> > >
> > > This patch addresses the problem of ambiguous conventions for the
> > > placement of the title related macros (\author, \date,...) with
> > > respect to the main document body in different latex classes. It
> > > introduces the following changes:
> > >
> > > * org-exp.el:
> > > - added the following options:
> > > - title-position (tpos)
> > > - with-title (wtitle)
> > > - with-author (wauth)
>
> [This is mostly addressed to Sebastian even though I'm replying to Tom's
> reply.]
>
> An empty
>
> #+AUTHOR:
>
> disables the insertion of author (assuming that TITLE is not empty -
> see below.)
>
>
> > > - with-date (wdate)
>
> An empty
>
> #+DATE:
>
> disables the insertion of date (same assumption.)
>
> > > - with-maketitle (wmtitle)
>
> An empty
>
> #+TITLE:
>
> disables the insertion of \maketitle.
To be honest, I didn't try setting empty author and date (which of
course makes sense) I just tried not setting them at all, which gives
default values. The main reason I submitted this patch, however, is
having better control of \maketitle. Personally I would like to be
able to have the title and author at the beginning of the file, just
for the looks, and still be able to produce a customized title. Of
course it is highly debatable if this is a sound reason to introduce
new options (I would argue yes).
> So if TITLE is not empty, you can get what you want with existing
> machinery. I could not find a way to make the title empty and still
> have author and/or date fields.
>
> Given all this, I think the only things you need is title-position and
> with-title, the latter in the unlikely event that you want a title page
> with author or date but without a title. Personally, I'd consider this
> last one unimportant and not worry about it, but you may disagree.
I agree concerning the author but no title case, this also does not
seem interesting to me.
> > >
> > > * org-latex.el:
> > > - implemented handling of new options (see above):
> > > - title-position controls placement of \title, \author, \date;
> > > possible values are "b" = before \begin{document},
> > > any other values default to after \begin{document}
> > > - with-* controls if the corresponding macro is exported at all
> > > this can be convenient for more complex titles (e.g. several
> > > authors including affiliations,...)
> > >
> > > The patch seems to work for me so far. What do you all think? IMO it
> > > would be useful to integrate this, as it gives slightly more control
> > > over the export process. Of course one might want to think about
> > > better option names. The diff is done against commit
> > > bc161ded3693f752616dcd247fc9d638789025ee.
> > >
> > > Let me briefly describe my current use case:
> > > I disable all commands except \title, use babel to created a title.tex
> > > file (including several authors and affiliations) by tangling latex
> > > code and then include the file (into the main body of the document,
> > > not the preamble). That's the only decent way I've found to do this,
> > > if anyone knows an easier way (I have the feeling that I might be
> > > overlooking an obvious solution) please let me know!
> > >
>
> I'm not sure what problem you are trying to solve here: can you explain?
> It seems to me that all this can be done in standard ways.
>
I'm using revtex4-1 at the moment. I need a title which looks like
this (within the document environment):
\begin{abstract}
some blabla
\end{abstract}
\author{First author}
\affiliation{First affiliation}
\affiliation{Second affiliation}
\author{Second author}
\affiliation{Third affiliation}
...
\keywords{optional keywords}
\pacs{optional pacs}
\maketitle
How would you solve this problem?
> > > Cheers
> > > Sebastian
> > >
> > >
> > Aloha Sebastian,
> >
> > Your patch should prove useful in the situation where one has to use a
> > particular class file that requires \title and friends to be declared in
> > the body of the document rather than the preamble. That functionality
> > is a welcome addition to the LaTeX exporter, IMO.
> >
>
> IIUC, the only remaining thing is the position of the \title etc macros
> in the preamble or the body (or both).
>
> There are three categories of LaTeX classes: the ones that implement
> Lamport's dictum that \title etc can come anywhere before \maketitle,
> the ones like RevTeX that insist on having them in the body and the ones
> like the thesis document class at Suvayu's university, that insist on
> having them in the preamble. I consider both of the latter two as buggy:
> has anybody submitted a bug report on them?
>
> Has anybody researched the prevalence of these bugs? Are there lots of
> classes in one or the other of the buggy categories?
>
> Be that as it may, it seems that org nee
Re: [O] Google Analytics tracking code for org-export-as-html
Oh, I see. It's a simple reason. Thanks for pointing it out. I will be careful. soichi 2011/6/2 Tomas Hlavaty > Hi soichi, > > > May I ask why I shouldn't do this ? > > data protection, privacy. Some people don't like being spied on, esp by > untrusted third-parties not related to your website content. But this > goes beyond your original technical question. > > Cheers, > > Tomas >
Re: [O] Bug: build problems [7.5 (release_7.5.343.ge05a)]
At Wed, 01 Jun 2011 08:00:20 -0400,
Dave Abrahams wrote:
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen. You don't know how to make a good report? See
>
> http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
>
>
> /Applications/Emacs.app/Contents/MacOS/Emacs -batch -q -no-site-file -eval
> "(setq load-path (cons (expand-file-name \"./lisp/\") (cons
> \"/usr/local/share/emacs/site-lisp\" load-path)))" -f batch-byte-compile
> lisp/org.el
>
> is ending with these errors:
>
> (cd doc && makeinfo --no-split org.texi -o org)
> org.texi:10224: Misplaced {.
> org.texi:10224: Misplaced }.
> org.texi:10226: Misplaced {.
> org.texi:10226: Misplaced }.
Fixed. Thanks for the report.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
pgpgrNIXuabaU.pgp
Description: PGP signature
Re: [O] [LaTeX Export] Question: How to import a really long caption in #+CAPTION:
Sunny Srivastava writes:
> Dear org-mode users:
>
> I want to export a really long caption in org to latex export.
>
> For example:
>
> #+CAPTION: A_really_long_caption_that_really_needs_a_line_break
> #+LABEL: fig:sims
>
> Presently, I can do it by just having the really long line in front of
> #+caption; if I have a line break, it is not exported as a caption. From
> worg, I know I can use:
>
> #+LaTeX: \caption{ }
>
> But I was wondering if there is a org-mode way of doing this.
>
> Thanks in advance for your help.
>
> Best Regards,
> S.
> Dear org-mode users:I want to export a really long caption in org to latex
> export.For example:#+CAPTION:
> A_really_long_caption_that_really_needs_a_line_break#+LABEL:
> fig:simsPresently, I can do it by just having the really long line in front
> of #+caption; if I have a line break, it is not exported as a caption. From
> worg, I know I can use:
> #+LaTeX: \caption{ }But I was wondering if there is a org-mode way of
> doing this.Thanks in advance for your help.Best Regards,S.
Aloha Sunny,
I can't tell from your post what problem you've run into. I can export
long captions without problems, e.g.:
#+CAPTION: [Polynesian colonization of Hawai`i]{Posterior probability
for Polynesian colonization of Hawai`i: \textit{left}, estimate based
on inequality (\ref{eq:no-rat}), with a 95\% highest posterior density
region of AD 810--1289; \textit{right}, estimate based on inequality
(\ref{eq:rat}), with a 95\% highest posterior density region of AD 780--1119.}
This all resides in one line in the org-mode file. Why does your
caption need a line break?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
