Re: [O] automatic tangle
Thanks Eric, Thanks a lot for the quick reply. Any chances of this being incorporated into Org-Mode in the near future? András On 1/14/12, Eric Schulte eric.schu...@gmx.com wrote: András Major andras.g.ma...@gmail.com writes: Hi Sebastien, I have the impression it's already there: if you edit your code directly in the Org buffer, without opening an indirect buffer, the only thing you have to do is: That's precisely what I want to avoid. I'd like to use the language-specific indentation and highlighting using the indirect buffer. Basically, what I'm after is a quick keyboard command that tangles the entire file while I'm in the indirect buffer. The following functions provide for (1) easily executing code in the org-mode buffer related to the current edit buffer and (2) tangling the org-mode buffer related to the current edit buffer. Binding (2) to a key in `org-src-mode' should provide the functionality you describe. #+BEGIN_SRC emacs-lisp (defmacro org-src-in-org-buffer (rest body) `(save-window-excursion (org-edit-src-exit 'save) ,@body (setq msg (current-message)) (if (eq org-src-window-setup 'other-frame) (let ((org-src-window-setup 'current-window)) (org-edit-src-code 'save)) (org-edit-src-code 'save)) (message (or msg (defun org-src-tangle (arg) (interactive P) (org-src-in-org-buffer (org-babel-tangle arg))) #+END_SRC I think that the above should be folded into org-src.el, but I'm not entirely sure how. (1) could be used to perform a number of functions in the org buffer from an edit buffer, although off the top of my head I'm not sure if there exists a need for this aside from tangling. Best, -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] latex export of #+header: lines
Hi all,
I am experiencing a problem with the latex exporter: #+header: lines
are visible in the exported file.
Example:
/==\
* test header tag
#+caption: foo
#+label: fig:fig1
#+name: foo
#+header: :file foo.png
#+header: :width 3600 :height 3600 :res 600
#+begin_src R :exports results :results graphics
plot(1:10, 1:10)
#+end_src
\==/
Results (LaTeX):
/=\
\section{test header tag}
\label{sec-1}
\#+header: :file foo.png
\#+header: :width 3600 :height 3600 :res 600
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{foo.png}
\caption{\label{fig:fig1}foo}
\end{figure}
\=/
The header arguments seem to take their effect, though.
Regards,
Andreas
Re: [O] latex export of #+header: lines
Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb -- Sebastien Vauban
Re: [O] column view extension
ayvango ayva...@zoho.com writes: I've found a non-standard use case for org-mode. I don't think there is a *standard* use case for org! ;-) There is plenty of spreadsheets engine with common drawback: spreadsheet cells follow original memory cell abstraction that are handy for a computer but is inconvenient for human. Hierarchical structures is more natural and in some cases may be used much more effective for at almost half of the data models. Indeed. And I like your particular example. Enjoy! This method saves me a lot of time but it may not be used with other hierarchical data models as simply as for the army list. This models may require more complicated summary types than those provided from ground. Is there any way to incorporate abstract grammar for defining and processing properties. There is already a way to define synthesized attributes as well as inherited ones. But there is no way to bind them together with a function to calculate output. I cannot answer this, whether any such way exists or not, but I can add my +1 if what you want is not possible. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.138.gbf1d5)
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K kjambunat...@gmail.com writes: Hello Eric I have pushed a fix for this. The fix is a bit tricky. So please exercise extra care while verifying the output. Hope I haven't overlooked any corner cases. Jambunathan, my simple examples all work perfectly. Many thanks! One comment: for tables that are indented, it probably makes sense to have the table take up 100% of the width available to it? In any case, is there an easy way to customise this from within LibreOffice? I note that, in etc/styles/OrgOdtContentTemplate.xml, you have defined OrgTable with 96% for the width but I have no idea how to change that value from within LibreOffice. This OrgTable style does not appear anywhere in the style chooser (F11). By the way, I was surprised, upon reading your comments in the git log, that OpenDocument doesn't support tables within lists. This seems like a silly restriction? Given that OpenDocument uses XML for its encoding, I would have thought that a hierarchical structure in a document would be trivial to represent. Do you know what the reasoning was? Just curious! Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.138.gbf1d5)
Re: [O] latex export of #+header: lines
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas
Re: [O] latex export of #+header: lines
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas Just tried, and the odt export has them as well. Maybe a problem on my test file? Or is the #+header(s): tag somehow deprecated? - Andreas
Re: [O] latex export of #+header: lines
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Confirmation, exporting to latex. Also happens with #+headers: lines. The code actually executes as it should so the lines are being interpreted correctly by babel so it's the exporting that is wrong. org up to date from git. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.139.g94f1)
Re: [O] latex export of #+header: lines
Hi Andreas, Andreas Leha wrote: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban writes: Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) Yes, they are. Sorry... I just read too quickly... I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. They should not appear in the exported TeX code. You're right about that. Just tried, and the odt export has them as well. Maybe a problem on my test file? Or is the #+header(s): tag somehow deprecated? I never used #+header (without the s). But that's not the problem... This must be related to the new variable `org-babel-exp-code-template'. See discussion at http://osdir.com/ml/emacs-orgmode-gnu/2012-01/msg00544.html. Though, I must admit not yet having time for testing it... Best regards, Seb -- Sebastien Vauban
Re: [O] LaTeX export problem
Wiadomość napisana przez Nick Dokos w dniu 10 sty 2012, o godz. 01:13: Have you tried exporting a simple file to latex? Perhaps something as simple as: --- * Foo Bar --- Nick Yes I have, it still produces a one-line TeX file.
Re: [O] Old entry remains in appt when the original one in org file is changed
Takafumi Arakaki aka@gmail.com writes: Hi Bernt, Thanks for your setup recipe. However, I noticed I failed to explain what I meant; the old entry remains in appt-time-msg-list even if you call org-agenda-to-appt. My recipe clears the list each time the agenda is generated. I only use appt for org-mode appointments so clearing the list works great for me. Regards, Bernt
[O] org-tags-column not fully obeyed
A nice day to all my Orger friends! For a while, I noticed that org-tags-column is not fully obeyed. I have it set to -70 from ~/.emacs, and `C-u C-c C-q' repairs the lines having tags set in another way. Insertion of new tags works nicely too. Yet, while wandering around (often through the Agenda), I often find tags reset as if org-tags-column was -79, or even some more bizarre places. I did not find yet under which circumstance the resetting occur. Did someone observe the same thing and identified what is going on? Or even have a recipe so I could repair either Org or my habits while using it? François P.S. I also see frequently see other display problems, which I routinely repair through org-indent-indent-buffer (thanks to those who helped me finding this function). It would be better if I was able to identify some repeatable usage cases, that I could share here.
[O] Idle time issue
Hi list, I'm setting up clocking to track idle time with org-clock-idle-time. It didn't work at first and it took me a while to figure out why. I use Emacs under x11 and yesterday's git head (812d0a53). Since I had not installed x11idle, idle time tracking failed silently. x11idle is mentioned in the manual, but it says For X11, you *can* install a utility program `x11idle.c' (my emphasis on can). It seems however that one *must* install x11idle, or idle time tracking will not work under x11. It seems to me that either the manual should say x11idle is mandatory, or that the x11 user should be given a choice to use either x11idle or emacs idle time. What do you think? I am prepared to try and send a patch either way. Tomas
[O] Reduced availability till next week
Dear all, I'm moving to a new flat, no Internet at home, only at work, where I try not to dive into Org code. I'll be back on next monday -- thanks for your patience. Best, -- Bastien
Re: [O] LaTeX export problem
Piotr Kaźmierczak p.h.kazmierc...@gmail.com wrote: Wiadomość napisana przez Nick Dokos w dniu 10 sty 2012, o godz. 01:13: Have you tried exporting a simple file to latex? Perhaps something as simple as: --- * Foo Bar --- Nick Yes I have, it still produces a one-line TeX file. In that case, it seems like your orgmode install is hosed - have you tried reinstalling from scratch? Nick
Re: [O] [BUG] Inconsistency in src block hiding
Hello, Bernt Hansen be...@norang.ca writes: I tried :results wrap but that didn't work for me. If I add RESULTS to my list of drawers then I can hide the block with TAB but I can't export my diagrams to HTML anymore which isn't very satisfying. Why can't you? Wouldn't it be related to drawers configuration (org-export-with-drawers for example)? Is there still a way to hide results output with the current master? Yes, within a drawer. Regards, -- Nicolas Goaziou
Re: [O] [BUG] Inconsistency in src block hiding
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: I tried :results wrap but that didn't work for me. If I add RESULTS to my list of drawers then I can hide the block with TAB but I can't export my diagrams to HTML anymore which isn't very satisfying. Why can't you? Wouldn't it be related to drawers configuration (org-export-with-drawers for example)? Yes... but I don't think I can configure which drawers I get, and I don't want my LOGBOOK drawer with all my clock lines in my export. -Bernt Is there still a way to hide results output with the current master? Yes, within a drawer. Regards,
[O] Bug: org-get-current-options uses fixed format-time-string [7.6]
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. Hi all: org-get-current-options uses the following line to fill the `#+DATE:' property in a new file: (format-time-string (substring (car org-time-stamp-formats) 1 -1)) While this is correct, I think it is too much tightly coupled with the org-time-stamp-formats constant defined in org.el. I would like to suggest to add a new defun (possibly interactive) to add a plain actual date. Something along the lines of: (defun org-current-time-stamp-string () Returns the current time stamp string in the org format. (format-time-string (substring (car org-time-stamp-formats) 1 -1))) (defun org-insert-current-time-stamp-string () Insert at point the current time stamp string in the org format. (interactive) (insert (org-current-time-stamp-string))) If those functions already exist, it would be then more appropriate to use them in that function `org-get-current-options`. Emacs : GNU Emacs 24.0.90.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-10-12 on dfontaine-laptop, modified by Debian Package: Org-mode version 7.6 -- Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsevi...@um.es _.___ Dep. Ingeniería y Tecnología de Computadores, Facultad de Informática D|TEC Univ.de Murcia,Campus Espinardo,30080 Murcia (SPAIN),Tel.+34868887571
[O] feature: include internal archive in [%] cookies
When I mark things complete, I then send them to internal archive. Any chance of adding an option for the [%] cookie to count items in Archive subtree? (similar to the org-hierarchical-checkbox-statistics variable)
Re: [O] Minimal overhead Org-mode blogging system
On Wed, Dec 07, 2011 at 10:50:52PM +0530, Puneeth Chaganti wrote: I have a system, that does most of what you are looking for. https://github.com/punchagan/blog-files Though it seems to be a little more complicated than it needs to be, it works for me and I haven't had the time and motivation to simplify it. This is a commentary on the entire thread rather than on this specific suggestion (though it's applicable here.) All of these take a git repo with text files in a lightweight markup language (e.g. markdown, org, rst, etc.) and build a blog/website tools have this major flaw and there's no good solution: They rebuild all pages in the site every time you update the site. Which doesn't matter at all when you have 10 posts, but when you have a hundred posts you notice the rebuild process, and by the time you have 1000-1500 posts, its totally unusable. Every time you fix a comma it takes 1-3 minutes and nearly OOMs a VPS system to fix. So what's the solution? - Incremental builds - Cached build elements. - make-style dependency checking. - indexes (for tags, archives, etc.) that are The truth is that the part of the pipe that handles the filtering of the text is important, but is not particularly central or crucial in the grand scheme of the usability of this kind of application. Cheers, sam -- tycho(ish) @ ga...@tychoish.com http://tychoish.com/ don't get it right, get it written -- james thurber pgp6niEoeMRcr.pgp Description: PGP signature
Re: [O] LaTeX export problem
Wiadomość napisana przez Nick Dokos w dniu 17 sty 2012, o godz. 18:00: In that case, it seems like your orgmode install is hosed - have you tried reinstalling from scratch? I did, but no luck. There must be something else I'm missing here, but I don't have time to investigate now. Thanks for your help, I'll post a solution here once I find one. Piotr
Re: [O] column view extension
Hi ayvango On Mon, Jan 16, 2012 at 22:00, ayvango ayva...@zoho.com wrote: I hope someone become interested in creating spreadtree application based on existing properties code. This would be very useful for me too. There are several resources that go towards this direction: *formulas in colum spec #+COLUMNS* First of course average/sum/min/max/... in the manual and talks, see the links in http://thread.gmane.org/gmane.emacs.orgmode/42071/focus=42088 but then there is also this very interesting whole thread about org-columns-compute and org-columns-compile-map http://thread.gmane.org/gmane.emacs.orgmode/12067 *org-collector* See e. g. http://thread.gmane.org/gmane.emacs.orgmode/42071/focus=42091 *dynamic block columnview with #+TBLFM:* For an example see indent2_tbl4.org.txt attached here http://lists.gnu.org/archive/html/emacs-orgmode/2011-11/msg00072.html and for some issues see the whole thread here http://thread.gmane.org/gmane.emacs.orgmode/48764 *remote() in #+TBLFM:* A simple example that might be interesting for some special cases but commonly quite inconvenient to change: #+BEGIN_SRC org , #+STARTUP: odd , - hours are edited, the rest is calculated with , M-x org-table-iterate-buffer-tables , * parent , #+TBLNAME: parent , | days | , |3 | , #+TBLFM: @$1 = remote(child1, @$1) + remote(child2, @$1) , *** child1 , #+TBLNAME: child1 , | days | hours | relative | , |1 | 8 | 0. | , #+TBLFM: @$1 = $2 / 8 :: @$3 = $1 / remote(parent, @$1) , *** child2 , #+TBLNAME: child2 , | days | hours | relative | , |2 |16 | 0.6667 | , #+TBLFM: @$1 = $2 / 8 :: @$3 = $1 / remote(parent, @$1) #+END_SRC Michael
Re: [O] LaTeX export problem
Piotr Kaźmierczak p.h.kazmierc...@gmail.com writes: Wiadomość napisana przez Nick Dokos w dniu 10 sty 2012, o godz. 01:13: Have you tried exporting a simple file to latex? Perhaps something as simple as: --- * Foo Bar --- Nick Yes I have, it still produces a one-line TeX file. can you, just in case, post to the mailing list with both org and resulting tex files attached? Also, what do M-x find-library RET org RET and M-x org-version RET say? What operating system are you using? I'm assuming a Mac from your previous message. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.144.g7233)
Re: [O] Minimal overhead Org-mode blogging system
tychoish ga...@tychoish.com writes: On Wed, Dec 07, 2011 at 10:50:52PM +0530, Puneeth Chaganti wrote: I have a system, that does most of what you are looking for. https://github.com/punchagan/blog-files Though it seems to be a little more complicated than it needs to be, it works for me and I haven't had the time and motivation to simplify it. This is a commentary on the entire thread rather than on this specific suggestion (though it's applicable here.) All of these take a git repo with text files in a lightweight markup language (e.g. markdown, org, rst, etc.) and build a blog/website tools have this major flaw and there's no good solution: They rebuild all pages in the site every time you update the site. Which doesn't matter at all when you have 10 posts, but when you have a hundred posts you notice the rebuild process, and by the time you have 1000-1500 posts, its totally unusable. Every time you fix a comma it takes 1-3 minutes and nearly OOMs a VPS system to fix. So what's the solution? - Incremental builds - Cached build elements. - make-style dependency checking. - indexes (for tags, archives, etc.) that are The truth is that the part of the pipe that handles the filtering of the text is important, but is not particularly central or crucial in the grand scheme of the usability of this kind of application. Cheers, sam Note that regular Org-mode projects [1] do *not* re-publish every single page after an update, but rather only publish pages which have changed since the previous publish. Thus a git repository with a pos-update hook which runs `org-publish' in a batch Emacs session does a good job of publishing updates without having to re-publish the entire site. This is the approach taken for my lab's wiki [2], which is just a git repository [3] with a post-update hook and a couple of helper scripts [4] which re-publish updated pages after every commit. Best, Footnotes: [1] http://orgmode.org/manual/Publishing.html [2] http://wiki.adaptive.cs.unm.edu [3] http://gitweb.adaptive.cs.unm.edu/wiki.git [4] http://gitweb.adaptive.cs.unm.edu/wiki.git/tree/HEAD:/data -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Mobile Org and crypt
I would love to hear from anyone using org-mobile with either or both : * individual crypted entries tagged with crypt * whole org files saved as file.org.gpg (ie entire file encrypted) I'm using an iPhone (not rooted/jailbroken).
Re: [O] Refiling list items
On Wed, Aug 17, 2011 at 05:32, Bastien b...@altern.org wrote: I pushed three small changes to the org-refile interface: 1. before prompting the user for a refile target, put the point at the beginning of the region/subtree to refile. This will make sure everyone understands we are refiling headlines, not text. 2. Improve the prompt itself, explicitely saying whether we are refiling a subtree or a region (containing subtree(s)). 3. Add a new option `org-refile-active-region-within-subtree' which, when turned on, allows the user to refile the active region, turning the first line into a headline using `org-toggle-heading'. I think these are improvements going in the right direction -- let me know what you think. On the overall, I'm with Nicolas in thinking that we need to be extra careful when we try to extend a functionality to heterogeneous elements. I've just come across an instance when this functionality was useful again. I like the solution you've implemented, Bastien. There's just a small problem I see right now, which pops up in particular with the example outline from my OP. ,[ Sample Outline ] | * Headline 1 | - List level 1 | - List level 2 | * Headline 2 | Some text. ` Selecting the region with the second line and third line, inclusive (the plain list under Heading 1), refiling with `org-refile-active-region-within-subtree' toggled on produces the following outline: ,[ Results ] | * Headline 1 | 2 | * Headline 2 | Some text. | ** List level 1 | - List level ` As you can see, the digit at the end of the list gets orphaned. -- Jeffrey Horn http://www.failuretorefrain.com/jeff/
