Re: [O] org-tree-slide: some small changes
Takaaki ISHIKAWA tak...@ieee.org writes: Dear Eric, Thank you for your kind suggestions. You're very welcome! [...] 4. Custom faces for headings. Oh… This is not my expected behavior. When you exit the org-tree-slide mode, the default configurations would be restored by org-tree-slide-heading-level-2-init or -3-init. However, as you know, those changes will apply to all org-mode buffers at the same time! Is my understanding correct? I guess, then, it would be good to have face changes be optional. I have tried org-tree-slide-mode with all face changes commented out and it works perfectly fine for me. If you can wrap all such changes into a conditional with a user customisable variable, I would be happy! 5. The default keybindings to moving slides. I agree, but I cannot change this because my english keyboard does not have the Page Up and Page Down key :-( Ah, interesting! I understand. It's easy enough for me to re-map, as you have suggested. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3d-898-g005917
Re: [O] html-export - limit size of pic to page-size?
Eric S Fraga e.fr...@ucl.ac.uk writes: Thorsten Jolitz tjol...@googlemail.com writes: Have you looked at the section in the manual on exporting to HTML, specifically the section entitled Images in HTML export? You can specify whatever HTML attributes you want for the image. OK, thanks for the hint. By the way, I am not sure what you mean by html page-size as HTML has no concept of pages, per se. Maybe you mean the width? Yes, 'width' is what I meant by 'page-size'. -- cheers, Thorsten
Re: [O] Bug: ODT export and environments
I acknowledge the bug. I would rather not fix it. Too much effort for too little gain etc. I think it is time that old exporter is forgotten and new exporter is exercised instead, when possible. Add this to your .emacs (add-to-list 'load-path ~/src/org-mode/contrib/lisp) (require 'org-e-odt) Invoke the following command. M-x org-export-dispatch RET Use the following to customize. M-x customize-group RET org-export-e-odt RET You can obtain all the new exporters by following means. 1. Check out from git. 2. Install `org-plus-contrib' package from Org ELPA. See http://orgmode.org/ for further instructions. Cassio Koshikumo ckoshik...@gmail.com writes: Hello, I think there's a bug when exporting files to ODT using environments (center, quote etc.). Sample file: * Testing #+BEGIN_CENTER First line. Second line. #+END_CENTER When exporting that, only First line will have the correct style OrgCenter. Second line (and all subsequent ones) will have the default Text body style. Thanks and best regards --
Re: [O] Problems with org-caldav (wrong-type-argument stringp 47)
Eric S. Fraga writes: David Engster d...@randomsample.de writes: OK, I took a shot at dealing with sexp entries. It's a complicated issue, since s-expressions can be in Org entries or by themselves. I updated the Readme with a section on how they are handled now. Please let me know how it works out for you. If you don't want/need sexp-based entries in your calendar, just set org-icalendar-include-sexps to nil. this fails. See below for debug trace. Thanks for the trace. This should be fixed now. As an aside, this new version of org-caldav changes point in my diary file (leaving it at the last entry in the file). Maybe a save-excursion somewhere is needed? Org-caldav does not use the diary file directly. This would rather be a bug in the icalendar exporter, or maybe in the icalendar package. I'm not sure how and where exactly these sexp entries are handled. -David
Re: [O] html-export - limit size of pic to page-size?
Thorsten Jolitz tjol...@googlemail.com writes: Hi List, when exporting plantuml code blocks to .png files, the resulting pictures can be tiny or really huge, depending on the class hierarchy modeled. Is it possible to restrict the size of the graphic to the html page-size, no matter how big the resulting .png file actually is? For example #+ATTR_HTML: width=600 -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] Info: (org)Customizing tables in ODT export
Is this issue resolved for you. Firstly, make sure that org file is indeed of right size and is NOT sheared to smaller size. Secondly, think about What has changed in my environment, which made me notice this aberrant behaviour. Did I change my PC, my desk etc etc. Thirdly, try emacs -Q FWIW, here is a report from my x86/Debian. , | kjambunathan@debian-6:~/src/org-mode/doc$ ls -al org* | 915211 Feb 2 23:26 org |23759 Jan 13 23:48 orgcard.tex | 398898 Feb 3 17:49 orgguide.pdf |99505 Jan 13 23:48 orgguide.texi | 1408420 Feb 3 17:49 org.html | 1729366 Feb 3 17:49 org.pdf | 717545 Feb 2 23:23 org.texi | 102 Feb 2 23:26 org-version.inc ` t...@tsdye.com (Thomas S. Dye) writes: Aloha Jambu, Jambunathan K kjambunat...@gmail.com writes: I am able to scroll/move up/down the info node without any issues. In the tiff file that you have attached, the section heading corresponding to 12.8.11.4 is underlined with dots. For me, there is no such dotted underline in the node. Have you tried emacs -Q Either you are having extra customizations or using an enhanced version of info (info+?) from Emacswiki or from elsewhere. This is the file created by 'make update' using the build system. I don't believe I've customized anything here beyond making 'make update' the default synonym for 'make'. I'll admit I'm not certain how or what the build system does to generate the documentation, but the files 'org', 'org.html', and 'org.pdf' were all created within a minute of one another. I don't think I'm using info+. poto:dk dk$ info --version info (GNU texinfo) 4.13 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. I'm working on a Mac. Thanks again for looking into this. All the best, Tom --
Re: [O] bbdb or bbdb3 or org-contacts
Thank you very much for all the input. So in summary it is on the safe side to use bbdb for a transition period because neither the maintainability of bbdb3 nor org-contacts seem to be ensured. Dieter PS: I hope future developments will bring forth a stable database solution maintained within Emacs proper. Daimrod daim...@gmail.com writes: joa...@verona.se writes: Daimrod daim...@gmail.com writes: Bastien b...@altern.org writes: Hi Dieter, Dieter Wilhelm die...@duenenhof-wilhelm.de writes: What do you advise, what is already usable and what is the way ahead, still bbdb or bbdb3 or already org-contacts? BBDB is great. org-contacts.el is too slow when you have many contacts, and it is not really maintained anymore. I've started to use org-contacts.el. I haven't (yet) problem with its speed but I've improved the completion mecanism which prevented me to use it. When I'll finish to document/comment it, I'll post it here. I would be very interested in having a look. See the attached patch files. I still need to need to take into account what could be after the cursor vv ATM I only use this From: John [cursor]D ^^ But I would like to use this But it mostly works. I migrated from bbdb to org-contacts, but it turned out to be too slow, so now I mostly isearch for the contact I want. Recently I've bee thinking of trying a strategy where bbdb could act as a cache for org-contacts, but I havent tried it yet. It shouldnt be too hard I think. org-contacts can generate a list of all contacts, that you then iterate and generate the bbdb database from. It might be a useful addition in any case. I was thinking to add a cache mecanism directly to `org-contacts.el'. It would load the content of the contacts files the first time into the appropriate structure and then reread the files only when they changed. Moreover, `org-contacts.el' doesn't use the new parser from `org-element.el' ATM, and using it might improve the performance too. PS: Sorry for the double patch files but the `org-reverse-string' part hasn't been merged yet and I use it. -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] html-export - limit size of pic to page-size?
Dieter Wilhelm die...@duenenhof-wilhelm.de writes: For example #+ATTR_HTML: width=600 Actually my question was meant with regards to Org-babel code blocks, e.g. , | +name: class-diagram | +begin_src plantuml :file class-diagram.png ` Is it possible to specify the html 'width=600' or 'width=auto' in the 'begin_src' line or in the subtree-properties - or do I have to let my program write the , | +ATTR_HTML: width=600 ` on top of the inserted link to 'class-diagram.png' when exporting to html? -- cheers, Thorsten
Re: [O] html-export - limit size of pic to page-size?
Thorsten Jolitz tjol...@googlemail.com writes: Dieter Wilhelm die...@duenenhof-wilhelm.de writes: For example #+ATTR_HTML: width=600 Actually my question was meant with regards to Org-babel code blocks, e.g. , | +name: class-diagram | +begin_src plantuml :file class-diagram.png ` What is plantuml? Something like gnuplot? Can't you create a png with exactly the resolution you want? Dieter Is it possible to specify the html 'width=600' or 'width=auto' in the 'begin_src' line or in the subtree-properties - or do I have to let my program write the , | +ATTR_HTML: width=600 ` on top of the inserted link to 'class-diagram.png' when exporting to html? -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] bbdb or bbdb3 or org-contacts
Dieter Wilhelm die...@duenenhof-wilhelm.de writes: So in summary it is on the safe side to use bbdb for a transition period Yes. because neither the maintainability of bbdb3 nor org-contacts seem to be ensured. Why do you think that maintainability of bbdb3 is not safe? To me looks that bbdb3 is in good swing at the moment. PS: I hope future developments will bring forth a stable database solution maintained within Emacs proper. That would be great, but maybe bbdb3 might fill it. Sincerely, Gour -- Even if you are considered to be the most sinful of all sinners, when you are situated in the boat of transcendental knowledge you will be able to cross over the ocean of miseries.
Re: [O] Info: (org)Customizing tables in ODT export
Aloha Jambu, Jambunathan K kjambunat...@gmail.com writes: Is this issue resolved for you. Just now, thanks to your suggestions. Firstly, make sure that org file is indeed of right size and is NOT sheared to smaller size. The org file appears to be correct. I opened it in emacs and was surprised to find section 12.8.11.4 is complete. Secondly, think about What has changed in my environment, which made me notice this aberrant behaviour. Did I change my PC, my desk etc etc. I changed my info: poto:doc dk$ which -a info /opt/local/bin/info /usr/bin/info This is the problem. When I use /usr/bin/info (ver. 4.8), which shipped with my Mac, all is well. When I use /opt/local/bin/info (ver. 4.13) from MacPorts, then the file is truncated. Achim mentioned something about locale and the C compiler, but I couldn't really follow where he was going. Since MacPorts is the only place on my system where gcc is invoked (I think, I certainly don't use gcc on my own), then perhaps there is a problem there? Thanks for your patience and persistence. I really appreciate the help. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Info: (org)Customizing tables in ODT export
Thomas S. Dye writes: This is the problem. When I use /usr/bin/info (ver. 4.8), which shipped with my Mac, all is well. When I use /opt/local/bin/info (ver. 4.13) from MacPorts, then the file is truncated. Could you re-create the info file with makeinfo-4.13, then? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Info: (org)Customizing tables in ODT export
Aloha Achim, Achim Gratz strom...@nexgo.de writes: Thomas S. Dye writes: This is the problem. When I use /usr/bin/info (ver. 4.8), which shipped with my Mac, all is well. When I use /opt/local/bin/info (ver. 4.13) from MacPorts, then the file is truncated. Could you re-create the info file with makeinfo-4.13, then? I don't see any difference between /usr/bin/makeinfo --no-split org.texi -o org and /opt/local/bin/makeinfo --no-split org.texi -o org In both cases, info 4.13 on my system truncates the display. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Prefix arguments, checklists, and lists
Nicolas Goaziou writes:
Hello,
Robert Horn rjh...@alum.mit.edu writes:
As a rule of thumb, C-c C-c on a list will operate on every top level
items and C-c C-c on a item will operate on the item. You are considered
to be on a list when calling C-c C-c from affiliated keywords or from
the very beginning of the first line in the first item. Note that
element-wise navigation (like M-{ and M-}) behaves the same.
This is different than your initial response, and still needs to be
documented. My major concern (and the bug that Bastien fixed) was that
it was applying the whole list logic whenever the point was on the first
*item* of the list. Restricting it to being different when on the first
*character of the first item* is different, and at least allows the
commands to be used on the first line.
I still think it's poor user interface design. The impact when you go
through the documentation for each command and add ... except when on
the first character of the first item of the list, in which case the
behavior is may make this clear. The user has to add that into
their thought processes when using lists. This constant side nag of
where am I on this line? which item am I on? is an indication of a
user interface problem.
The other times that emacs and org-mode care about where you are on the
line are situations where you are directly editing and changing the
contents of the line. It feels natural to pay attention to the location
on the line when editing the text. And, even then, the change is
restricted to that location on the line. It is only when using a
prefixed commands that the changes affect other locations.
That's why I prefer using a different prefix to mean whole list. That
leaves all of the list related commands that affect the current item to
be C-u prefixed. If you have a different prefix that means whole
list, you eliminate the where is the point? mental effort. It adds
the ability to have that different prefix enable whole list when on
any item in any location in the list.
R Horn
rjh...@alum.mit.edu
Re: [O] html-export - limit size of pic to page-size?
Dieter Wilhelm die...@duenenhof-wilhelm.de writes: What is plantuml? Something like gnuplot? Can't you create a png with exactly the resolution you want? Nice tip, thanks, it did not come to my mind that the problem might be much easier to solve on the plantuml (textbased software for UML diagram creation) side than on the Org-mode side, but it is - there is a 'scale' command for zoom-functionality in plantuml: ,- | scale 1.5 | scale 2/3 | scale 200 width | scale 200 height | scale 200*100 `- are examples. Although it seems impossible to determine the right relative scale factor without knowing the grafic size a priori, this way I can offer a pic scaled down to absolute width=600 and a download link to the original size png. -- cheers, Thorsten
[O] color of exported code block
Hi, My emacs color theme consists of a black background with colors that match that. When I export an org file to html, the colors appear like how they appear in emacs (good), except the background isn't black. This (http://comments.gmane.org/gmane.emacs.orgmode/50906) post explains that I could modify the color and background options in the pre tag), but I was wondering if there's a way to have emacs export the code with a white background color theme so that it'll always look OK in an export? That is, when I edit in emacs, colors have a black background theme. When I export, different colors are used that match a white or grey background color. FYI, I use (add-to-list 'load-path ~/.emacs.d/color-theme-6.6.0) (require 'color-theme) (color-theme-clarity) -- Vinh
[O] [ANN] Merge of new export framework on Wednesday
━ ANNOUNCING THE NEW EXPORT FRAMEWORK ━ Table of Contents ─ 1 To Whom Used the Experimental Version 2 What’s New .. 2.1 New Back-Ends .. 2.2 Drawer Handling .. 2.3 Special Blocks .. 2.4 Improved Asynchronous Export .. 2.5 Smart Quotes .. 2.6 Cross Referencing .. 2.7 Lists of Tables, Lists of Listings 3 Installation 4 Configuration .. 4.1 Variables .. 4.2 Hooks .. 4.3 Filters .. 4.4 Forking a Back-End 5 Caveats 6 Footnotes Hello, I will install the new export framework along with a set of back-ends Wednesday evening (UTC). Here are a few notes to help you make the transition. 1 To Whom Used the Experimental Version ═══ The merge implies some renaming for symbols and files. More precisely, “e-” is removed from symbols like variable names, functions and back-ends and “org-e-” becomes “ox-” in files. To sum it up: ━━━ Old name New name ─── e-latex latex org-e-latexox-latex org-export-latex-packages-alist org-latex-packages-alist ━━━ Be sure to check filters and requires in your configuration files. 2 What’s New Even though the internals are completely different, the new exporter mostly behaves like its predecessor. There are only a few noticeable changes. 2.1 New Back-Ends ─ New back-ends come with the new export engine: • Markdown back-end (name: `md') • Texinfo back-end (name: `texinfo') • Man back-end (name: `man') Most of the other back-ends have been rewritten from scratch, too. 2.2 Drawer Handling ─── By default, every drawer but “properties” and “logbook” has its contents exported. See `org-export-with-drawers' variable. 2.3 Special Blocks ── The `org-special-blocks.el' library, which has been moved to “contrib/”, is obsolete since its features are included in the new export framework. 2.4 Improved Asynchronous Export Export can be asynchronous independently on the type of the source or output (temporary buffer or file). A special interface, called “The Export Stack”, is used to view the output. See `org-export-in-background' variable. 2.5 Smart Quotes All back-ends have support for “smart” quotes, according to `org-export-default-language' value or the `LANGUAGE' specifications in the buffer. See `org-export-with-smart-quotes'. As of now, only “de”, “en”, “es” and “fr” languages are supported, but it’s easy to add more. See `org-export-smart-quotes-alist'. Do not hesitate to contribute more languages. 2.6 Cross Referencing ─ Export has now full support for cross references, through targets and `#+NAME' attributes[1]. Pay attention to the following example. ╭ │ #+CAPTION: A table │ #+NAME: table │ | a | b | │ │ #+CAPTION: Another table │ #+NAME: other-table │ | c | d | │ │ 1. itmitem 1 │ 2. item 2 │ │ Look at item [[itm]]! It happens after table [[other-table]]. ╰ When exported, the last line will be displayed as: ╭ │ Look at item 1! It happens after table 2. ╰ It doesn’t depend on the back-end used. It also references footnotes, headlines, LaTeX environments… 2.7 Lists of Tables, Lists of Listings ── There is support for lists of tables and lists of listings in some back-ends with the following syntax: ╭ │ #+TOC: headlines ╰ ╭ │ #+TOC: tables ╰ ╭ │ #+TOC: listings ╰ 3 Installation ══ There are two ways to install export back-ends. 1. You may customize `org-export-backends' variable. It contains the list of back-ends that should always be available. 2. You can also simply require the back-end libraries (e.g. `(require 'ox-icalendar)' for the iCalendar back-end). Note that with method 1, the back-ends will be loaded only when the export framework is used for the first time. 4 Configuration ═══ Previously, the export engine was configured through variables and numerous hooks. Now, there are variables, only two hooks and filters. One can also easily fork a new export back-end from an existing one. 4.1 Variables ─ The easiest way to browse configurable variables should be through customize interface. Though, the old export framework is still lurking in the Org shipped with Emacs. As a
[O] Calling 'org-babel-mark-block' with 'M-x cmd' and 'M-: (cmd)'
Hi List, just wondering (and curious) if this is a bug or (in some way) expected behaviour: Say point is at the beginning of the first line of an Org-mode source block: , | #+begin_src plantuml :file er-class-diagram.png | scale 600 width ... # point at beg-of-line ` Now, when I call interactive command org-babel-mark-block' either with 'M-x org-babel-mark-block' or 'C-c C-v C-M-h', the body of the source block is (visibly) marked as expected (transient-mark-mode is on). But with the point at the same position, evaluating with 'M-:' ,-- | Eval: (org-babel-mark-block) `-- returns the position of point without (visibly) marking the source-block body. -- cheers, Thorsten
Re: [O] Calling 'org-babel-mark-block' with 'M-x cmd' and 'M-: (cmd)'
Thorsten Jolitz tjol...@googlemail.com wrote: Hi List, just wondering (and curious) if this is a bug or (in some way) expected behaviour: Say point is at the beginning of the first line of an Org-mode source block: , | #+begin_src plantuml :file er-class-diagram.png | scale 600 width ... # point at beg-of-line ` Now, when I call interactive command org-babel-mark-block' either with 'M-x org-babel-mark-block' or 'C-c C-v C-M-h', the body of the source block is (visibly) marked as expected (transient-mark-mode is on). But with the point at the same position, evaluating with 'M-:' ,-- | Eval: (org-babel-mark-block) `-- returns the position of point without (visibly) marking the source-block body. The function is called differently in the two cases: * backtrace with ESC ESC : (org-babel-mark-block) org-babel-mark-block() eval((org-babel-mark-block) nil) eval-expression((org-babel-mark-block) nil) call-interactively(eval-expression nil nil) * backtrace with M-x org-babel-mark-block org-babel-mark-block() call-interactively(org-babel-mark-block record nil) command-execute(org-babel-mark-block record) execute-extended-command(nil org-babel-mark-block) call-interactively(execute-extended-command nil nil) I don't know if that accounts for the difference - my guess is that it probably does, but I don't know how. Nick
Re: [O] Calling 'org-babel-mark-block' with 'M-x cmd' and 'M-: (cmd)'
Nick Dokos nicholas.do...@hp.com writes: The function is called differently in the two cases: * backtrace with ESC ESC : (org-babel-mark-block) org-babel-mark-block() eval((org-babel-mark-block) nil) eval-expression((org-babel-mark-block) nil) call-interactively(eval-expression nil nil) * backtrace with M-x org-babel-mark-block org-babel-mark-block() call-interactively(org-babel-mark-block record nil) command-execute(org-babel-mark-block record) execute-extended-command(nil org-babel-mark-block) call-interactively(execute-extended-command nil nil) I don't know if that accounts for the difference - my guess is that it probably does, but I don't know how. Interesting, I have to check what happens when I use this function in a program. Kind of strange, though, is that a bug in 'org-babel-mark-block' - or in Emacs itself? -- cheers, Thorsten
Re: [O] [ANN] Merge of new export framework on Wednesday
Le dimanche 3 février 2013 à 20h00, Nicolas Goaziou a écrit: I will install the new export framework along with a set of back-ends Wednesday evening (UTC). Here are a few notes to help you make the transition. That's an exciting news! Thanks for all the job already done and to be done. If the documentation is as good as this announcement, it will be great! Cheers, François Allisson
Re: [O] Problems with org-caldav (wrong-type-argument stringp 47)
David Engster d...@randomsample.de writes: Eric S. Fraga writes: David Engster d...@randomsample.de writes: OK, I took a shot at dealing with sexp entries. It's a complicated issue, since s-expressions can be in Org entries or by themselves. I updated the Readme with a section on how they are handled now. Please let me know how it works out for you. If you don't want/need sexp-based entries in your calendar, just set org-icalendar-include-sexps to nil. this fails. See below for debug trace. Thanks for the trace. This should be fixed now. Excellent. My diary sexp entries work! Thanks. As an aside, this new version of org-caldav changes point in my diary file (leaving it at the last entry in the file). Maybe a save-excursion somewhere is needed? Org-caldav does not use the diary file directly. This would rather be a bug in the icalendar exporter, or maybe in the icalendar package. I'm not sure how and where exactly these sexp entries are handled. This problem seems to have disappeared. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07
Re: [O] html-export - limit size of pic to page-size?
Thorsten Jolitz tjol...@googlemail.com writes: Is it possible to specify the html 'width=600' or 'width=auto' in the 'begin_src' line or in the subtree-properties - or do I have to let my program write the , | +ATTR_HTML: width=600 ` on top of the inserted link to 'class-diagram.png' when exporting to html? You can put that line immediately above the #+RESULTS line after the first time you evaluate the source code block. Subsequent evaluations of the source code will replace the results but will leave those lines present. See the attached example. This is easier, in my opinion, than having to change the code to generate a specific size, especially if have different export targets for the same document. HTH, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07 #+name: umltest #+begin_src plantuml :file uml.png :exports results skinparam monochrome true autonumber footbox off actor Somebody #white actor me #88 Somebody - me : ask for grant review me - me : spend some time thinking about this Somebody - me : review grant #+end_src #+CAPTION: UML diagram #+LABEL: fig:uml #+ATTR_LATEX: width=\linewidth #+ATTR_HTML: width=600px #+results: umltest [[file:uml.png]]
Re: [O] babel: setting :cmdline header arg for sql blocks
Gary Oberbrunner ga...@oberbrunner.com writes: To run mysql code in org-mode (which by the way is pretty incredible that this works at all, and so beautifully, especially since I'm on Windows), I have to have a long header: #+BEGIN_SRC sql :exports both :results value :engine mysql :cmdline -h XXX.YYY.XXX.YYY -u user -ppassword -D database I'd like to put all those flags in one place so I only need to say #+BEGIN_SRC sql (and maybe the exports/results). If I put them in PROPERTY tags at the end of the buffer: #+PROPERTY: exports both #+PROPERTY: results value #+PROPERTY: engine mysql #+PROPERTY: cmdline -h XXX.YYY.XXX.YYY -u user -ppassword -D database then exporting no longer works, I presume because the exporter doesn't like :cmdline or :exports or :results or something else about me setting these globally. Is there a way to set them for sql blocks only? Or some kind of macro I can use to tidy up my sql blocks? (I'm running recent git org-mode from a couple of weeks ago, Emacs 24.3.50.1, Windows) You could customize the `org-babel-default-header-args:sql' variable. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] patch for ob-sql.el: improve MySQL header formatting, and add db spec header vars
Gary Oberbrunner ga...@oberbrunner.com writes: Here's a better version of this patch, which also adds support for :colnames, which I needed. And it adds some doc about what header args are used. * add a header-row delimiter to the tables returned from mysql * adds new sql-specific header args for the database connection, and implements them for mysql * adds support for :colnames (mysql only) * (minor) adds an edebug spec to org-babel-result-cond to allow edebugging through it Hi Gary, Thanks for sharing this patch. It looks like a solid improvement of Org's SQL support, and I'd like to apply it, however I need to ask for two things first. Most importantly, given the size of the patch you'll have to complete the Emacs copyright assignment process, see [1]. Less importantly, if you could re-generate the patch using git format-patch, it will be much easier to apply. Thanks! On Fri, Feb 1, 2013 at 10:18 AM, Gary Oberbrunner ga...@oberbrunner.comwrote: Let me know if this would be better as a pull request. This patch does three things: * add a header-row delimiter to the tables returned from mysql * adds new sql-specific header args for the database connection, and implements them for mysql * (minor) adds an edebug spec to org-babel-result-cond to allow edebugging through it -- Gary Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte http://cs.unm.edu/~eschulte
[O] New exporter, beamer confusion
During the semester break, I want to switch over to the new exporter.
Currently I'm using export mainly for beamer presentations.
I found the org-e-latex-classes entry in an old e-mail post. With
that, M-x org-export-dispatch l P produces a .tex document that
compiles. But the output is not right.
I've typically done my presentations with sections and frames only, no
sub-(sub-)sections. So I got some improvement over my first test by
removing the subsection lines from Nicolas' example entry:
(add-to-list 'org-e-latex-classes
'(beamer
\\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]
(\\section{%s} . \\section*{%s})
; (\\subsection{%s} . \\subsection*{%s})
; (\\subsubsection{%s} . \\subsubsection*{%s})
))
Frame display is still incorrect, though. If I write:
* Section A
** Slide 1
*** Third-level
Fourth-level
... I expect ** in the outline to be the frame title, and the third
and fourth level headings go into the frame's body as bullets. But in
the .tex file, there is no \begin{frame} at all. So I get an
enumeration hard-aligned to the top of the frame:
1. Slide 1
1.1 Third-level
1.1.1 Fourth-level
Bottom line question, then, is: How can I convert my setup for the old
exporter (pasted below) over to the new exporter, and get compatible
results without having to restructure dozens of org files?
I'm also attaching a very simple org file that I'm using for testing.
Org-mode version 7.9.2 (release_7.9.2-883-g6fb36e.dirty @
/home/dlm/share/org-mode.git/lisp/) (Dirty = A tiny patch I have
submitted for a mobileorg problem, which so far has been ignored.)
hjh
*** OLD EXPORTER SETUP
#+LANGUAGE: en
#+OPTIONS: H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+BEAMER_FRAME_LEVEL: 2
#+TITLE: Applied Techniques for Digital Audio \newline Making
music by programming
#+AUTHOR:H. James Harkins
#+DATE: 7 November 2012
#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}beamer
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX
* Section
** Frame
*** Bullet in frame
simple-beamer.org
Description: Binary data
simple-beamer.tex
Description: TeX document
Re: [O] New exporter, beamer confusion
On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote: #+OPTIONS: H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t The H:10 is your problem. Since you want 2nd level headlines to be frames, it should be H:2. Hope this helps, -- Suvayu Open source is the future. It sets us free.
[O] colorg: Weekly status
Hi to all Org friends! Here is my weekly status message on colorg development. colorg is a tool for real-time collaborative editing of Org files. Interesting progress has been made this weekend, but no cake yet! Sigh... :-) There is an Emacs module and a Python server. The Emacs client has much advanced and is ready for testing, and almost ready for use (!), a few bugs surely remain. The client now correctly demultiplexes what servers send, which merely means that an Emacs user may simultaneously associate many buffers to that many shared resources, usually all taken from one, but maybe more than one colorg server, and all goes nicely in parallel. I removed some optimization code from the Emacs client and pushed the equivalent in the Python server. The idea was then to shorten packets transmitted from the client to the server, the idea is now to keep the client as simple as possible. Clash resolution in the server, when different users work in the same vicinity, remains a difficult issue, and is still not finished. Without a server which takes dependable decisions in all cases, colorg is unusable in practice. While I have a rather clear idea about how to proceed, the programming is still fairly tedious. It will likely have to wait until next weekend, sorry. Before leaving, I'd like to document my usual testing recipe, in case someone would be adventurous enough to repeat it. Once colorg installed as per https://github.com/pinard/colorg/wiki/Usage, and having identical files test1.org and test2.org ready, in a terminal window I do: emacs test1.org emacs test2.org env/bin/colorg-server -d This opens two Emacs windows besides the terminal window. That terminal window displays a trace of the on-going communication (because of -d). My own keybinding for colorg-mode is C-c e . In one of the Emacs (let's say the one for test1.org), I type: C-c e . RET RET RET RET This has the effect of connecting to the server and uploading test1.org. In the second Emacs, I type: C-c e . RET RET RET TAB RET This has the effect of connecting to the server and associating the current test2.org with the already existing resource named test1.org. From now on, modifications to one buffer are reflected on the other. François
