Re: [O] [latex] Problems with old exporter (for Beamer) and with new exporter
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: With the new exporter, most things work. What does not work: - macro does not get executed (no string in orange color), Macro are meant to produce contents, not to talk to back-ends. Every text they produce will be protected. Do you mean the template must be pure text? Yes. Pure text or another macro. Do you mean that a thing such as http://frozenlock.org/2011/11/05/on-the-fly-key-sequence-insertion/ won't work anymore? Not at the moment, but macros may change in the future. I'm unsure about the best level to handle them, but it's probably too high at the moment. On the other hand, I would like to avoid too much intersection with inline Babel calls or src blocks. For example, expansion could happen before buffer is parsed, like in old exporter. But at the same time, inline src blocks are executed, so I'm sure the macro could be replaced with such a block. I'm open to discussion about this. Though, now, when trying to export to LaTeX (with the new exporter and up-to-date Org[1]), I get an error: This is because you're using beamer as your LaTeX class, which probably doesn't have any association in `org-e-latex-classes'. Note that even if it had one, it wouldn't work as expected since Beamer is not supported yet (but I'll probably implement a first draft for this back-end soon). Regards, -- Nicolas Goaziou
Re: [O] new (LaTeX) exporter and date formatting
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: The following patch should add the language option according to LANGUAGE keywords if babel package is explicitly loaded in preamble. I think this will be a great addition! Albeit a very limited one: guessed language in only added when babel package is loaded _and_ it is different from the one set by the user. If there is no objection, I'll push a slightly refactored version of that patch. Regards, -- Nicolas Goaziou
[O] bug#11710: 24.1.50; Bidi attributes are not exported in org-mode html output
On Thu, Jun 14, 2012 at 10:42 PM, Eli Zaretskii [stuff deleted] Did you customize Emacs to dynamically determine the paragraph direction in Org buffers? By default they are forced to be left-to-right. Yes, I changed that. Org-mode appears to me to work fine in dynamic Bidi mode, so I don't understand the reasoning that it was turned off by default. [stuff deleted] To the Org maintainers: the resolved paragraph direction at character position N in the current buffer can be retrieved like this: (save-excursion (goto-char N) (current-bidi-paragraph-direction)) Ok, thanks. Perhaps I'll have a go at it on my own. Regards, Dov
[O] bug#11700: bug#11700: 24.1.50; Bad interaction between BiDi and org-tables
On Thu, Jun 14, 2012 at 10:37 PM, Eli Zaretskii e...@gnu.org wrote: Date: Thu, 14 Jun 2012 21:10:46 +0300 From: Dov Grobgeld dov.grobg...@gmail.com Cc: 11...@debbugs.gnu.org [stuff deleted] I tried inserting tabs into the buffer before the vertical bars, but after reordering it still didn't come out right. ??? What exactly did you try? You need to have a TAB before and after each '|' that's between the cells (the outer ones do not need a TAB). Like this (you should see this correctly in Emacs 24.1; move cursor with C-f to see the logical order): | אבגד | הוזחטי | Isn't this what you wanted? Yes. Great! This is indeed what I wanted. My mistake was that I tried it with a tab character before OR after the vertical bar. This solution should be really simple to implement in org-mode as it means that instead of joining the table columns with spacevbarspace as is currently done, you just need to use tabvbartab as well as setting the tab width to 1. But I just wonder, is there any other character (preferably white space character) with the same end-of-segment-boundary properties as tab, in case tab is used for something else in org-mode? Or is it possible to take an arbitrary character, e.g. U+E0020, and bless it with end-of-segment boundary properties and then use that in the org-mode buffer? As a side note, I really like the idea of end of segment separator, and I wasn't aware of it when I wrote fribidi a long time ago. I wonder if the semantics of the emacs segment separator follows the Unicode Bidi Algorithm?
[O] bug#11710: 24.1.50; Bidi attributes are not exported in org-mode html output
Date: Fri, 15 Jun 2012 09:17:36 +0300 From: Dov Grobgeld dov.grobg...@gmail.com Cc: 11...@debbugs.gnu.org On Thu, Jun 14, 2012 at 10:42 PM, Eli Zaretskii [stuff deleted] Did you customize Emacs to dynamically determine the paragraph direction in Org buffers? By default they are forced to be left-to-right. Yes, I changed that. Org-mode appears to me to work fine in dynamic Bidi mode, so I don't understand the reasoning that it was turned off by default. 2 reasons: . If you maintain Org files with mixed L2R and R2L contents, having some items on the left and some on the right looks messed up, especially if the parent item is on the other side of the window. . Performance. Dynamic detection of paragraph direction can slow down redisplay, if you have long stretches of items without empty lines to separate them. When sub-trees are hidden, this could cause an annoying effect whereby moving cursor past one visible line causes a perceptible delay (because there are many hundreds of hidden lines Emacs needs to move through in the buffer). This punishes Org users who don't use bidirectional scripts, which are the majority of Org users. So in traditions of democracy, the majority wins... (save-excursion (goto-char N) (current-bidi-paragraph-direction)) Ok, thanks. Perhaps I'll have a go at it on my own. Please consider reporting here if you get it to work, because Org maintainers may wish to use your code. TIA
[O] bug#11700: bug#11700: 24.1.50; Bad interaction between BiDi and org-tables
Date: Fri, 15 Jun 2012 09:39:35 +0300 From: Dov Grobgeld dov.grobg...@gmail.com Cc: 11...@debbugs.gnu.org Yes. Great! This is indeed what I wanted. My mistake was that I tried it with a tab character before OR after the vertical bar. This solution should be really simple to implement in org-mode as it means that instead of joining the table columns with spacevbarspace as is currently done, you just need to use tabvbartab as well as setting the tab width to 1. Yep. But I just wonder, is there any other character (preferably white space character) with the same end-of-segment-boundary properties as tab, in case tab is used for something else in org-mode? That's the (space . :align-to COLUMN) display property I was talking about. With it, you can arrange for a single blank, say, to produce a stretch of whitespace of arbitrary size, in character cell units, aligned to a specified column. If you use :width instead of :align-to, you can have the size tuned in pixels. Emacs treats text covered by such display properties as segment separators, so they produce the same effect as TAB does. That's because conceptually, such display properties are used to separate text into columnar display, exactly like TAB is used in plain-text tables. You can find examples of using these display properties in minibuffer.el, where they are used to produce the display in the *Completions* buffer. Their documentation is in the ELisp manual. Or is it possible to take an arbitrary character, e.g. U+E0020, and bless it with end-of-segment boundary properties and then use that in the org-mode buffer? Try using u+2029, it should do the trick, I think. As a side note, I really like the idea of end of segment separator, and I wasn't aware of it when I wrote fribidi a long time ago. I wonder if the semantics of the emacs segment separator follows the Unicode Bidi Algorithm? Of course, it does; Emacs implements the UBA to the letter, taking only the high-level protocols fire-escape to guide the reordering using Emacs-specific context. (But even the high-level protocols feature is part of the UBA, see section 4.3 there.) The Segment Separator feature is not an Emacs invention, it exists in the UBA. The key to understanding it is this part of the UBA: L1. On each line, reset the embedding level of the following characters to the paragraph embedding level: 1. Segment separators, 2. Paragraph separators, 3. Any sequence of whitespace characters preceding a segment separator or paragraph separator, and 4. Any sequence of white space characters at the end of the line. And the TAB character has S, i.e. segment separator, as its bidi property. Since its embedding level is reset to the base embedding level of the paragraph, the result is that text on both sides of a TAB is reordered separately and independently. Moreover, the high-level protocols feature give us one more possibility: HL4. Apply the Bidirectional Algorithm to segments. . The Bidirectional Algorithm can be applied independently to one or more segments of structured text. For example, when displaying a document consisting of textual data and visible markup in an editor, a higher-level process can handle syntactic elements in the markup separately from the textual data. Emacs uses this to treat the `space' display properties as segment separators.
Re: [O] [latex] Problems with old exporter (for Beamer) and with new exporter
Hello Nicolas, Nicolas Goaziou wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: With the new exporter, most things work. What does not work: - macro does not get executed (no string in orange color), Macro are meant to produce contents, not to talk to back-ends. Every text they produce will be protected. Do you mean the template must be pure text? Yes. Pure text or another macro. Do you mean that a thing such as http://frozenlock.org/2011/11/05/on-the-fly-key-sequence-insertion/ won't work anymore? Not at the moment, but macros may change in the future. I'm unsure about the best level to handle them, but it's probably too high at the moment. On the other hand, I would like to avoid too much intersection with inline Babel calls or src blocks. For example, expansion could happen before buffer is parsed, like in old exporter. But at the same time, inline src blocks are executed, so I'm sure the macro could be replaced with such a block. I'm open to discussion about this. I think it makes a lot of sense to consider that macros can't be used in a back-end specific way -- the first reason being that you have no way to tell for which back-end they are written (unlike what we can do with `org-add-link-type' where we can specify different back-end translations). Though, now, when trying to export to LaTeX (with the new exporter and up-to-date Org[1]), I get an error: This is because you're using beamer as your LaTeX class, which probably doesn't have any association in `org-e-latex-classes'. OK. I thought I was working on a pure document. Sorry for the noise. Note that even if it had one, it wouldn't work as expected since Beamer is not supported yet (but I'll probably implement a first draft for this back-end soon). I'll be glad to be your first Beamer tester -- as this is something I use a lot, even if I do use it in its simple form (no multicolumn parameters, and the like). Best regards, Seb -- Sebastien Vauban
Re: [O] new (LaTeX) exporter and date formatting
Hi Nicolas,
The following patch should add the language option according to LANGUAGE
keywords if babel package is explicitly loaded in preamble.
I think this will be a great addition!
I just made some quick test of your patch and it works great! So I
completely agree.
Albeit a very limited one: guessed language in only added when babel
package is loaded _and_ it is different from the one set by the user.
I do not mind. I can have '#+LATEX_HEADER: \usepackage[en]{babel}' in
all my .org files by default and have the exporter override the language
setting based on the '#+LANGUAGE:' tag.
If there is no objection, I'll push a slightly refactored version of
that patch.
Pleas do so. And a big thanks for that addition!
Regards,
Andreas
Re: [O] new (LaTeX) exporter and date formatting
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
I do not mind. I can have '#+LATEX_HEADER: \usepackage[en]{babel}' in
all my .org files by default and have the exporter override the language
setting based on the '#+LANGUAGE:' tag.
I've pushed the patch. Thanks for the language list.
Note that LANGUAGE doesn't override Babel package's options, but append
another language to them if not already specified.
Hence,
#+LATEX_HEADER: \usepackage[english]{babel}
#+LANGUAGE: fr
will produce
\usepackage[frenchb,english]{babel}
Should it replace previous language instead?
Regards,
--
Nicolas Goaziou
[O] Format a whole column using ;%.2f in orgtbl?
Hi, I'm using radiotables and would like to get all numbers of column 1 with two digits after the decimal separator. My example below leads to an error, but it may explain what I'd like to receive: Input: | 100 | Value | | 150 | Value | #+TBLFM: $1=%s;%.2f Desired outoput: | 100.00 | Value | | 150.00 | Value | #+TBLFM: $1=%s;%.2f I also tried to use :fmt (1 %s;%.2f) while exporting to LaTeX, but in vain. Regards, Alexander
Re: [O] new (LaTeX) exporter and date formatting
Hi Nicolas,
Nicolas Goaziou wrote:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
I do not mind. I can have '#+LATEX_HEADER: \usepackage[en]{babel}' in
all my .org files by default and have the exporter override the language
setting based on the '#+LANGUAGE:' tag.
I've pushed the patch. Thanks for the language list.
Note that LANGUAGE doesn't override Babel package's options, but append
another language to them if not already specified.
Hence,
#+LATEX_HEADER: \usepackage[english]{babel}
#+LANGUAGE: fr
will produce
\usepackage[frenchb,english]{babel}
That's wrong a the main language is the latest loaded (here: english).
Should it replace previous language instead?
I would think so, or at least suffixed, instead of being prefixed.
Of course, this is related to the question: do we allow or want multiple
languages in one document? If the answer is yes in LaTeX, how do we do in Org,
and for the HTML export (for which the value of #+LANGUAGE is also used).
Honestly, I don't care that much about one or the other, as I don't have to
type documents with multiple languages inside them. Or, if I would, I would
accept to insert LaTeX code inside my Org file to fix whatever needs to!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Bug: org-capture Does not take user to any new buffer
On Tue, Jun 5, 2012 at 9:07 AM, Mike Fitzgerald mikef656 at gmail.com wrote: I'm presented with an *Org Select* buffer that offers me the available choices However, this part does not work as expected:when I select one of those I select one of those, I get a CAPTURE-foo.org bufferI would expect: A) new buffer would be created and B) EMACS would switch to it andC) Some message with value to the userB and C do not happen. A happens but I need to manually switch to itI get a message that has little value: Capture template `j': org- called-interactively-pI have never used the working version of capture (this is it), but I have usedremember a little and seem to recall it gives a message something I am seeing similar behaviour from Org Capture. That is: - It doesn't open the buffer for the user to add text to the capture. - A message byte-code: Capture template `t': org-called-interactively-p is displayed. - The capture _does_ get written to the target file. - However the capture written to the target file contains %? literally inserted into the entry. (setq org-log-done t)(setq org-capture-templates '((t Todo entry (file+headline ~/org/gtd.org Tasks) * TODO %?\n %i\n %a) (j Journal entry (file+datetree ~/org/journal.org) * %?\nEntered on %U\n %i\n %a))) I'm using templates similar to these. The main thing I can add, is that if I change entry to plain, Capture works just fine. (Of course, in many cases one wants entries, so this is not a solution.) I'm using GNU Emacs 23.3.1 ((i386-mingw-nt5.1.2600) of 2011-03-10) and Org Version 20120611 (7.8.11) which I downloaded/installed with the Emacs package manager system. I apologise if there is already a solution to this issue (I didn't see it), and I hope this additional information is helpful. Regards, N. ;org-capture binding ;(global-set-key \C-c-c 'org-capture)(global-set-key [(control c) (c)] 'org- capture)Does this look OK? ThanksMike On Mon, Jun 4, 2012 at 10:56 PM, Nick Dokos nicholas.dokos at hp.com wrote:Mike Fitzgerald mikef656 at gmail.com wrote: To duplicate: I haven't tried specifically to duplicate your setup but org-capture seems to work fine here. 1) Run org-capture with C-c c 2) User is Promoted with the two templates expected (copied the templates from the org-mode site) 3) Enter j for journal 4) Expect switch to new buffer 5) No switch occurs So what happens instead? If I start capture, I get another window where I'm presented with an *Org Select* buffer that offers me the available choices and when I select one of those, I get a CAPTURE-foo.org buffer for some value of foo. This is actually an indirect buffer and the text should be inserted into the target location already, so you can look at ~/org/journal.org (or whatever) and see that it contains the partial entry just started. See the description of org-capture: C-h f org-capture RET. If I were you, I'd probably use edebug to step through the org-capture function (and I'd forget about byte compiling anything until whatever problem you have is identified and solved). HTH, Nick Note that journal.org is open, but I need to switch to it I expected EMACS to switch to a new buffer after choosing the template. Running GNU EMACS 23.3 on Win7 Org mode update byte compiled by hand (without make) using (defun my/compile-org(optional directory) Compile all *.el files that come with org-mode. (interactive) ;Found on a org-mode related page. Thanks Mike 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. Emacs : GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600) of 2011-03-10 on 3249CTO Package: Org-mode version 7.8.11 current state: == (setq org-log-done 'time org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed- command-hook) org-metaup-hook '(org-babel-load-in-session-maybe) org-capture-templates '((t Todo entry (file+headline ~/org/gtd.org Tasks) * TODO %?\n %i\n %a) (j Journal entry (file+datetree ~/org/journal.org) * %?\nEntered on %U\n %i\n %a) ) org-after-todo-state-change-hook '(org-clock-out-if-current) org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab- command-maybe org-babel-hide-result-toggle-maybe) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode- configure-edit-buffer)
Re: [O] New Link Syntax: Adding ATTRIBUTES (Was: org-e-html: Including ATTR_HTML)
On Thu, Jun 14, 2012 at 8:53 PM, William Crandall bc3141...@gmail.comwrote: ATTRIBUTES would consisting of name:value pairs, perhaps giving names export-type prefixes, such as HTML_STYLE and HTML_TITLE, or LATEX_PDFBORDER and LATEX_URLCOLOR. HTML ATTRIBUTES would map to HTML 'attributes': http://www.w3.org/TR/html5/section-index.html#attributes-1 LATEX ATTRIBUTES would map to Latex \hypersetup 'options': http://en.wikibooks.org/wiki/LaTeX/Hyperlinks#.5Chyperref (Subsection: Customization) -- This would be a significant change, but it would make LINKS first class objects, and allow Org mode users to directly apply rich families of link attributes/options. I really like this idea! -- Avdi
[O] [dev] About a beamer back-end
Hello,
As I announced in another thread, I'm starting a Beamer back-end for the
new export engine. Though, before I start hacking, I have a question
about environments.
I'm wondering if it is really interesting to have every environment set
up from headlines. I understand it allows to use column view but, from
my experience, I've used previous Beamer exporter without ever resorting
to this view. Also, it introduces some hacks (like the normal block)
when you want to insert some text after a block.
On the other hand, I think special blocks could be used for
environments. For example:
#+begin_src org
* Vocabulary
#+ATTR_BEAMER: :title Definition
#+BEGIN_BLOCK
A *set* consists of elements.
#+END_BLOCK
Some text.
#+ATTR_BEAMER: :title Question. :action 2-
#+BEGIN_ALERTBLOCK
Let R be the set of all sets that are not members of themselves.
Is R a member of itself?
#+END_ALERTBLOCK
#+end_src
would result in:
#+begin_src latex
\begin{frame}
\frametitle{Vocabulary}
\begin{block}{Definition}
A \alert{set} consists of elements.
\end{block}
Some text.
\begin{alertblock}2-{Question}
\end{alertblock}
\end{frame}
#+end_src
Beamer minor mode would provide templates for blocks instead of
shortcuts for property API. Frames would still be defined from
headlines.
I do not mind keeping previous implementation, but it can be clunky at
times. What do you think?
Regards,
--
Nicolas Goaziou
Re: [O] Smart Quotes Exporting
Nicolas Goaziou n.goaziou at gmail.com writes: Hello, Mark Shoulson mark at kli.org writes: ASCII exporter also handle UTF-8. So it's good to have there too. Really? I would have thought ASCII meant ASCII, as in 7-bit clean text. org-e-ascii.el (as old org-ascii.el) handles ASCII, Latin1 and UTF-8 encodings. I noticed that after writing my response. The name just threw me a little. Yes, that exporter needs to handle it too. It looked to me like your solution would essentially boil down to do string handling when there's a string, otherwise recur down and find the strings, which essentially means apply it to all the strings... and there were already functions out there applying things to strings, so this can just ride along with them. Here, let's look at your suggestion and see if we can find what I missed: So, if it's a string, use the regexps (if they can be smart enough to look at beginning and end of the string, which they can--though I haven't been using the :post-blank property so presumably something is amiss), and if it isn't a string, recur down until you get to a string... Ah, but only if it's in org-element-recursive-objects. You're missing an important part: the regexps cannot be smart enough for quotes at the beginning or the end of the string. There, you must look outside the string. Hence: Well, wait; regexps can make some pretty darn good guesses at the beginnings or ends of strings. Quotations don't normally end in spaces (in the conventions used with ; French typography is different, but if you're using spaces around your quotes you have worse problems (line-breaks) to worry about). So if a string ends in space(s) followed by a quote, it's very likely that quote is an open-quote for some stuff that comes after. Conversely, if a string starts with a quote followed by some spaces, it's very likely a close- quote to what went on before. This isn't quite it; beginning-of-string followed by quote, then punctuation and then spaces is also a close-quote, etc... There is a lot of fine-tuning. But even what I currently have was able to handle your Caesar said, /Alea Jacta est./ example. Yes, there are edge-cases which this won't catch, and it remains to be seen how pervasive and annoying those are. It may be that repeated tweaking of regexps will handle enough of the ordinary cases. It may be that after a few rounds of regexp-hacking someone will finally decide that regexp- hacking just won't handle enough of the important cases. But I think even as it stands now we'd probably handle 80-90% of the normal situations, which really is as much as we reasonably can hope for. Could I trouble someone to try applying my patch and trying it out for yourself and seeing just how bad/good the performance is? It seems to work okay for the cases I've been trying, but maybe my dataset isn't robust enough. Let's give it a test and seen how many actual cases in common usage it gets wrong. Maybe see how much can be fixed by tuning regexps. ] 1. If it has a quote as its first or last position, check for ] objects before or after the string to guess its status. An ] object never starts with a white space, but you may have to ] check :post-blank property in order to know if previous object ] had white spaces at its end. But you can only do that from the element containing the string, not from the string itself. The case where a quote both sits at the edge of a string (i.e. at the border of some element, formatting, etc) *and* does not have whitespace next to it, with possible punctuation, does not seem to be a normal occurrence to me. If I'm wrong, how common *is* it? So the issue with the current state is that it would wind up applying to too much? (it would hit code and verbatim elements, for example, and that would be wrong.) No, you are not applying it too much (verbatim elements don't contain plain-text objects) but your function hasn't got access to enough information to be useful. The on-screen version, of course, will have to be smarter and check for the face formatting to make sure it doesn't happen in comments or verbatims; I am pretty sure it does not do that yet. wait, called on the top-level parsed tree object, recursively doing its thing before(?) the transcoders of the individual objects get to it. That's called a parse tree filter. That should be a possibility indeed. The function would be applied on the parse tree and would replace strings within elements containing plain text (that is paragraph, verse-block and table-row types). parse tree filters are applied very early in the export process. Another option would be to integrate it into `org-element-normalize-contents', but I think the previous way is better. Maybe. I know it sounds like I'm fixated on the plain-text solution, but I'm not convinced the
Re: [O] [dev] About a beamer back-end
Hi Nicolas, First a big thank you for all your efforts over the last year. On Fri, Jun 15, 2012 at 5:08 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: I'm wondering if it is really interesting to have every environment set up from headlines. I understand it allows to use column view but, from my experience, I've used previous Beamer exporter without ever resorting to this view. Also, it introduces some hacks (like the normal block) when you want to insert some text after a block. On the other hand, I think special blocks could be used for environments. For example: [...] I do not mind keeping previous implementation, but it can be clunky at times. What do you think? I have to agree with you, the block approach seems cleaner to me. Environments like definition or quotes appear on beamer slides as blocks, so I think your proposal fits in better logically compared to using headlines. There is an added bonus to this, now headlines could be used properly to do what it is meant to do, sectioning. Something like this would be very nice: #+begin_src org #+BEAMER_FRAME_LEVEL: 3 * Top level section 1 ** sub-section 1 *** frame 1 some intro text #+ATTR_BEAMER: :title Definition #+BEGIN_BLOCK A *set* consists of elements. #+END_BLOCK some concluding text ** sub-section 2 *** another frame * Top level section 2 ** sub-section *** some frame #+end_src org With this syntax it would be very easy to write both really long (40-50 frames) as well as quick and short presentations. However this breaks backwards compatibility for existing org documents. As a very frequent beamer export user I would be willing to break backwards compatibility for cleaner structuring in the future. If backwards compatibility is too precious, one could move org-beamer to contrib and rename it org-beamer-lagacy. Another comment/request I have is better support for overlays. It seems to me with the block approach overlaying for blocks could be supported with block header arguments (like babel). I'm not sure though how one could have overlays in lists though. Maybe the [@n] syntax for ordered lists could be exploited to support overlays with list (although I admit it feels like a big hack)? Hopefully these comments are helpful. PS: I can't wait to test the new beamer exporter. :) -- Suvayu Open source is the future. It sets us free.
Re: [O] [dev] About a beamer back-end
On Fri, Jun 15, 2012 at 12:41 PM, suvayu ali fatkasuvayu+li...@gmail.com wrote: With this syntax it would be very easy to write both really long (40-50 frames) as well as quick and short presentations. I've only been using Org and Beamer for a little while, but if I understand it correctly this sounds preferable. I haven't memorized my Beamer syntax yet, but something basic that I do a lot and I've found to be awkward in Org-Beamer is having a series of slides where the main title stays the same but with different content for each. I'd like to be able to write that as a section and a series of subsections. Then again, perhaps this is already possible and I just don't know how. -- Avdi
Re: [O] Format a whole column using ;%.2f in orgtbl?
Hi Alexander On Fri, Jun 15, 2012 at 4:34 PM, AW alexander.will...@t-online.de wrote: [...] Desired outoput: | 100.00 | Value | | 150.00 | Value | #+TBLFM: $1=%s;%.2f [...] What you tried would be | 100.00 | Value | | 150.00 | Value | #+TBLFM: $1=$0;%.2f $0 is the current table field. What I recommend is | 100.00 | Value | | 150.00 | Value | #+TBLFM: $1 = $0 +.0; f-2 because of the behavior I explained in the tables shown here: http://orgmode.org/worg/org-faq.html#table-float-fraction Michael
[O] Problems with Org-mode from git and Habits
Hello all: I have decided to give org-habit another shot, however, I am having some problems. The habit todos show up in the agenda correctly with consistency graphs. However, they will not repeat once I mark them as done- this used to work, but not anymore. I am using the git version of org-mode. Any pointer will be appreciated. Charles -- I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-) (Linus Torvalds) pgpA0zFGdWLuk.pgp Description: PGP signature
Re: [O] Problems with Org-mode from git and Habits
Hi Charles On Fri, Jun 15, 2012 at 8:42 PM, Charles Philip Chan cpc...@bell.net wrote: I have decided to give org-habit another shot, however, I am having some problems. The habit todos show up in the agenda correctly with consistency graphs. However, they will not repeat once I mark them as done- this used to work, but not anymore. I am using the git version of org-mode. Any pointer will be appreciated. I can not confirm with release_7.8.11-71-g8840cd. Can you try this?: #+BEGIN_SRC org ,* TODO take a break , SCHEDULED: 2012-06-14 Thu .+9d/28d , :LOGBOOK: , - State DONE from TODO [2012-06-01 Fri 12:00] , :END: , :PROPERTIES: , :LAST_REPEAT: [2012-06-01 Fri 12:00] , :LOG_INTO_DRAWER: t , :LOGGING: logrepeat , :STYLE:habit , :END: #+END_SRC Michael
Re: [O] Problems with Org-mode from git and Habits
Michael Brand michael.ch.br...@gmail.com writes: Hi Micheal: I can not confirm with release_7.8.11-71-g8840cd. Can you try this?: ... Thanks. I have traced the problem to a customization that I have in org-after-todo-state-change-hook what prevented the :LAST_REPEAT: property to be add and the todo state to be toggled back. Sorry for the noise. Charles -- Sigh. I like to think it's just the Linux people who want to be on the leading edge so bad they walk right off the precipice. (Craig E. Groeschel) pgp4PjCw3xY67.pgp Description: PGP signature
Re: [O] new (LaTeX) exporter and date formatting
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: That's wrong a the main language is the latest loaded (here: english). Good point. Should it replace previous language instead? I would think so, or at least suffixed, instead of being prefixed. From now, it will be suffixed. Of course, this is related to the question: do we allow or want multiple languages in one document? If the answer is yes in LaTeX, how do we do in Org, and for the HTML export (for which the value of #+LANGUAGE is also used). This is unrelated to HTML. Each back-end handles #+LANGUAGE: keyword as needed, if at all. There's no global specification about that keyword. Moreover, it's simpler to implement that way. So, if there is no drawback with having two languages, let's keep it simple. Regards, -- Nicolas Goaziou
