Re: [O] Include lengthy LaTeX in export preamble
On Sun, Jul 27, 2014 at 10:08 PM, Ken Mankoff wrote:
> Hi Jacob,
>
> #+LATEX_HEADER: does work on export (when else would it work?)
>
> Agreed. If I said otherwise it was a mistake.
2) From Aaron Ecay, put your header in a #+BEGIN_SRC latex section, and
> then run a bit of lisp to export that section, and then include the
> exported file in a #+LATEX_HEADER: \include{preamble}. This is the
> approach I use.
>
> ,
> | #+begin_src emacs-lisp
> | (org-babel-goto-named-src-block "preamble")
> | (org-babel-tangle)
> | #+end_src
> |
> | #+name: preamble
> | #+begin_src latex :tangle preamble.tex
> | % code goes here
> | #+end_src
> `
>
This looks handy. Thanks!
My elisp ability is minimal, but if someone can point me towards where I
would look to try to create an export analogue to org-format-latex-header,
I would at least take a look and try to come up with a patch.
Thanks,
Jake
Re: [O] beginner agenda question
Steven Arntson writes: > Simple question, I think, but it has me stumped. I'm wondering what > variable controls the org-agenda function that gives you upcoming > events, a la: > > todo: In 2 d.: TODO Friend's Birthday > todo: In 4 d.: TODO Rehearsal > todo: In 4 d.: TODO Happy Hour > todo: In 9 d.: TODO Some other thing > > I'd like to get rid of all of that, actually. For me, it clutters things > up too much. > > Thank you! > steven It looks like you've put a DEADLINE cookie on those events -- the advance warning only kicks in in that case, if I recall correctly. For plain old events (birthdays, doctors appointments, etc), it's often best just to use a regular old timestamp, so: * Rehearsal <2014-07-28 Mon> Or you can put the timestamp on the line below the headline. HTH, Eric
Re: [O] Include lengthy LaTeX in export preamble
Hi Jacob,
#+LATEX_HEADER: does work on export (when else would it work?)
I think I recall a space between the ":" and the LaTeX command is
needed. Do you have one?
For more ideas on how to have lengthy custom headers, see thread here:
https://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00734.html
and links therein. There are three general approaches:
1) Make a custom class file and include that, either in your init file
or in the Org file.
2) From Aaron Ecay, put your header in a #+BEGIN_SRC latex section, and
then run a bit of lisp to export that section, and then include the
exported file in a #+LATEX_HEADER: \include{preamble}. This is the
approach I use.
,
| #+begin_src emacs-lisp
| (org-babel-goto-named-src-block "preamble")
| (org-babel-tangle)
| #+end_src
|
| #+name: preamble
| #+begin_src latex :tangle preamble.tex
| % code goes here
| #+end_src
`
3) Implement a patch or pester developers to create a third simpler
solution.
Good luck,
-k.
* On 2014-07-27 at 21:00, Jacob Gerlach wrote:
> I have a lengthy command customization that I want to include in LaTeX
> export. Since it must appear in the preamble,
> #+BEGIN_LATEX
> ...
> #+END_LATEX
>
> didn't work. I had to prepend
> #+LATEX_HEADER:
> to each line in order to achieve my result.
>
> I found C-h v org-format-latex-header RET:
>
> "The document header used for processing LaTeX fragments..."
>
> But it seems that when the docstring says "fragments," it is not referring
> to exporting.
>
> Are there any customizations to do the same during export?
>
> Thanks,
> Jake
[O] beginner agenda question
Simple question, I think, but it has me stumped. I'm wondering what variable controls the org-agenda function that gives you upcoming events, a la: todo: In 2 d.: TODO Friend's Birthday todo: In 4 d.: TODO Rehearsal todo: In 4 d.: TODO Happy Hour todo: In 9 d.: TODO Some other thing I'd like to get rid of all of that, actually. For me, it clutters things up too much. Thank you! steven
[O] Include lengthy LaTeX in export preamble
I have a lengthy command customization that I want to include in LaTeX export. Since it must appear in the preamble, #+BEGIN_LATEX ... #+END_LATEX didn't work. I had to prepend #+LATEX_HEADER: to each line in order to achieve my result. I found C-h v org-format-latex-header RET: "The document header used for processing LaTeX fragments..." But it seems that when the docstring says "fragments," it is not referring to exporting. Are there any customizations to do the same during export? Thanks, Jake
[O] ·Open footnote link definition from reference directly
Hi orgers, I wrote a little snippet below to open footnote link definition directly with a single call. I think it will be very useful when you have a lot of link footnote definitions in you documents. Since I am a newbie to lisp, any advice of improvement will be really appreciate. (defun open-footnote-link () "Open footnote link directly without going to definition" (interactive) (save-excursion (if (org-footnote-at-reference-p) (progn (org-footnote-action) (forward-word) (org-kill-note-or-show-branches) (org-open-at-point)) (message "Must be in footnotes with link definition" (global-set-key (kbd "C-c C-x l") 'open-footnote-link)
[O] Clear non-repeated scheduled time when deadline is repeated
Hi, I'm having the exact same issue as this question on stackoverflow http://stackoverflow.com/questions/18123972/emacs-org-mode-clear-non-repeated-scheduled-time-when-deadline-is-repeated and I've copied it below. The solution provided to the question modifies the source, which I'd like to avoid if possible. Is there a better way of doing this like by setting a variable or a hook? Or does anyone have better ideas about this type of workflow? Question: > I use org-mode to manage some deadlines for repeated tasks. For example, I > may have something like the following: > * TODO My Weekly Task > DEADLINE <2013-08-10 Sat +1w> > If I mark the task as DONE, then the deadline automatically increments to > the next week as expected. However, I also like to use the SCHEDULED time > to indicate when during the week I would like to actually do that task, for > example: > * TODO My Weekly Task > DEADLINE <2013-08-10 Sat +1w> SCHEDULED: <2013-08-08 Thu> > This makes the task show up in the agenda for today (Thursday). However > when I mark the task DONE, I end up with the following: > * TODO My Weekly Task > DEADLINE <2013-08-17 Sat +1w> SCHEDULED: <2013-08-08 Thu> > ...and the task still appears in the agenda view for today, even though it > has been completed. > Is it possible, for tasks that have a repeated DEADLINE, to get Org-Mode > to clear the non-repeated SCHEDULED date? Solution: > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -12835,7 +12835,8 @@ This function is run automatically after each > state change to a DONE state." > (setq type (if (match-end 1) org-scheduled-string > (if (match-end 3) org-deadline-string "Plain:")) > ts (match-string (if (match-end 2) 2 (if (match-end 4) 4 0 > - (when (string-match "\\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\)" ts) > + (if (not (string-match "\\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\)" ts)) > + (org-remove-timestamp-with-keyword org-scheduled-string) > (setq n (string-to-number (match-string 2 ts)) > what (match-string 3 ts)) > (if (equal what "w") (setq n (* n 7) what "d")) Thanks, Phil
Re: [O] [patch] [babel] Patches to fix tangling and variable transfer of tables in R
Rainer M Krug krugs.de> writes: > > Nicolas Goaziou nicolasgoaziou.fr> writes: > > > Hello, > > > > Rainer M Krug krugs.de> writes: > > [snip] > > Amended patches attached. AFAICS, these patches are good to go. Can they be applied, please? Chuck
[O] org-envolve?
Hello, I've some functions in worg/code/elisp/davidam.el, that could be interesting contribute to org-mode (I use davidam-org-src every day). The functions are: + davidam-org-envolve-src(msg) + davidam-org-src(msg) + davidam-org-envolve-check-list() + davidam-org-envolve-numbered-list() My doubt is if is better work more to create a new file, or if someone thinks that can be integrated in some existing org file. Thanks.
[O] Export agenda to HTML with links to body contents
Hi, I upload my agenda on a website, so I can access it from multiple devices. This works nicely with the following in a cron job: emacs --batch -l ~/.emacs.d/init.el -eval '(org-batch-store-agenda-views)' -kill The only thing I'm missing is links to the body of the item. Does Org currently support anything in the HTML export that could enable showing the content on a click? For example: ** Item 1 This text here would be visible when you click on "Item 1" in the HTML-exported document. The link on "Item 1" could lead to a separate page or it could use some fancy CSS/Javascript. Any ideas? Thanks, Sebastian
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Hello, Federico Beffa writes: > In the end of the day the reason why I started looking into this is > the fact that I do not find user friendly that org-mode, when filling > a paragraph, interprets \[...\] as any inline snippet and does not > keep it on a separate line (as recommended by the LaTeX manual, see > attached document). That's it. As explained previously, I'm not against the idea, but it would break existing documents containing "\[...\]" in the middle of a line, even though it is valid LaTeX. In any case, you will not get total LaTeX conformance. Anyway, I can't see any technical limitation to your suggestion. So we might as well ask the ML. I'll write a consultative poll about it. Regards, -- Nicolas Goaziou
[O] [ANN] Merge export-block type within special-block
Hello, Export blocks are blocks dedicated to export back-ends, e.g., "#+BEGIN_LATEX". The way they are currently parsed is flawed. Export blocks are back-end dependent. At the moment, back-ends register their own export block in a variable, `org-element-block-name-alist', so the parser can know if it needs to parse an export block or not. As a consequence, the same block can be parsed differently if a given export back-end is loaded or not. E.g., #+BEGIN_HTML ... #+END_HTML will be parsed as a `special-block' if "ox-html.el" is not loaded, or an `export-block' otherwise. This is slightly... ugly. And it gets worse if we include the cache, which will not update the block if it is not modified. I just committed a set of patches that solve the problem: `export-block' elements do not exist anymore. Instead, such blocks are now parsed as `special-block', always. This does not depend on the libraries loaded so far. Of course, special blocks are not treated exactly as export blocks. The latter's contents are included as-is in the output whereas the former's are interpreted. Therefore, special blocks now include another property, :raw-value, which stores the pristine initial contents of the block, and "ox.el" provides a new function, `org-export-raw-special-block-p', which tells the difference between a former export block and a special block. This makes sense since an "export-block" is clearly, and only, an export concept. This is not related to Org syntax. This is more simple to handle than it sounds, and can be described with two steps: 1. `export-block' elements, translators and filters are now ignored. These can be removed from export back-ends (unless you want to preserve compatibility with Org 8.2, in which case leaving them will not hurt: they will be used in Org 8.2 and ignored in Org 8.3). 2. Translators for special blocks, e.g. `org-BACKEND-special-block' need to be updated and check first if current block is a raw special block or not. The following template is a suggestion. #+BEGIN_SRC emacs-lisp (defun org-latex-special-block (special-block contents info) (if (org-export-raw-special-block-p special-block info) (org-element-property :raw-value special-block) ;; Usual handling for special blocks goes here. )) #+END_SRC Note that if BACKEND is a derived back-end and doesn't implement its own special block translator already, there is nothing to change. The parent back-end will take care of such blocks. All back-ends in core and in contrib have been updated this way already. I included `org-export-raw-special-block-p' in Org 8.2, as a forward-compatibility measure, so back-end maintainers do not have to do the `fboundp' dance. BTW, for those in the back of the room: I didn't remove "#+BEGIN_LATEX"-like constructs. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Hi Nicolas,
I understand that org-mode is not LaTeX and therefore the org-mode
internal representation of LaTeX should not matter to end users like
me. That's fair enough. In the end of the day the reason why I started
looking into this is the fact that I do not find user friendly that
org-mode, when filling a paragraph, interprets \[...\] as any inline
snippet and does not keep it on a separate line (as recommended by the
LaTeX manual, see attached document). That's it.
I've therefore started messing around with
org-element-paragraph-separate, but after a while I thought that it
would be better to look at how the \begin...\end environments are
handled and try to do the same with \[...\]. That's how I noticed the
difference between the two (and perceived it as wrong handling of
\[...\]). I just thought that correcting the filling behavior of
org-mode would be useful to all users of org-mode and not just me.
In any case, if it's just me, I would greatly appreciate an advice on
how to achieve my goal from somebody with a good understanding of the
internals of org-mode. Is there a better way than just changing
org-element-paragraph-separate?
Thank you in advance for any advice.
Best Regards,
Fede
P.S.: I've attached for reference two pages, from the book written by
LaTeX's creator (the book I've mentioned on my first email), on how to
use the various mathematical constructs.
On Sat, Jul 26, 2014 at 11:20 AM, Federico Beffa wrote:
> I understand that. However, using \[...\] inline within a paragraph is
> not the intended use of \[...\]. The use of \[...\] is for
> mathematical expressions which you want to stand out, on their own
> lines.
>
> For inline mathematical expressions there are the constructs \(...\) and
> $...$.
>
> Regards,
> Fede
>
> On Sat, Jul 26, 2014 at 10:26 AM, Nicolas Goaziou
> wrote:
>> Federico Beffa writes:
>>
>>> Of course \[ 1+1 \] is valid LaTeX syntax, just as inline
>>> \begin{displaymath} 1+1 \end{displaymath} is valid.
>>
>> But \begin{displaymath} 1+1 \end{displaymath} isn't valid in an Org
>> paragraph.
>>
>>> In my opinion a construct which will be displayed on a line by itself
>>> and with some space separating it from the preceding and the following
>>> text lines such as "\[ ... \]" would be better represented as a
>>> latex-environment and not an inline latex-fragment. In this way the
>>> org-mode text representation with proper fill-paragraph handling would
>>> be much more readable and consistent with the meaning of the syntax
>>> that it borrowed.
>>
>> That would prevent \[...\] to be recognized within a paragraph, as in
>> the example above. I don't think it's worth removing it as long as there
>> is a latex-environment alternative for it.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
latex-math.pdf
Description: Adobe PDF document
Re: [O] #+header: :post -> Symbol's value as variable is void: *this*
Thorsten Jolitz writes:
> Hi List,
>
> whats wrong with this :post header arg:
>
> #+header: :post (format "#+attr_latex :float :placement {c}{scale=.6}\n%s"
> *this*)
> #+begin_src emacs-lisp
> (+ 2 2)
> #+end_src
>
> When I understand
>
> ,
> | http://orgmode.org/manual/post.html
> `
>
> correctly, *this* should hold the block results, but I get
>
> ,
> | Symbol's value as variable is void: *this*
> `
This works:
#+name: myconcat
#+header: :var x=""
#+begin_src emacs-lisp
(format "Do %sx then quit" x)
#+end_src
#+header: :post myconcat(x=*this*)
#+begin_src emacs-lisp
(+ 2 2)
#+end_src
#+results:
: Do 4x then quit
but how do I interpret the following sentence from the manual:
,
| This variable [*this*] may then be included in header argument forms
| such as those used in var header argument specifications allowing
| passing of results to other code blocks, or direct execution via Emacs
| Lisp.
`
What is meant by 'direct execution via Emacs Lisp' here? I think the
above construct with two src-blocks is a bit heavy for the rather small
task and hoped I could just give an Emacs Lisp expression containing
*this* as value to the :post header arg, but apparently not?
#+header: :post (format "Do %sx then quit" *this*)
#+begin_src emacs-lisp
(+ 2 2)
#+end_src
-> eval: Symbol's value as variable is void: *this*
--
cheers,
Thorsten
