Re: [O] Old entry remains in appt when the original one in org file is changed
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.
So, the procedure to reproduce my problem is the following:
1. Add the following in the agenda file
* TODO test
SCHEDULED: <2012-01-14 Sat 12:00>
2. Call org-agenda-to-appt
3. Change the SCHEDULED time-stamp in the entry like this
* TODO test
SCHEDULED: <2012-01-14 Sat 12:00>
4. Call org-agenda-to-appt again # ADDED THIS
5. appt-time-msg-list has the old entry
((1380)
#("12:00 TODO test" 6 15
(org-heading t))
t)
((1390)
#("12:10 TODO test" 6 15
(org-heading t))
t)
I found how to fix this. You can tell org-agenda-to-appt forcefully
clear the old entries by passing non-nil to the first argument of
org-agenda-to-appt.
This is how I use it:
(defun my-org-agenda-to-appt-when-saved ()
(when (member buffer-file-name (mapcar 'expand-file-name org-agenda-files))
(org-agenda-to-appt t)))
(add-hook 'after-save-hook 'my-org-agenda-to-appt-when-saved)
Note that this will clear all entries stored in appt, including the
ones unrelated to org-mode. But if you are using appt only from
org-mode, there is no problem.
--
Takafumi
Re: [O] :noweb no-export
Hi Tom, I just pushed up a fix and a test, please let me know if the problem persists. Cheers, t...@tsdye.com (Thomas S. Dye) writes: > Hi Eric, > > The :noweb no-export option depends on the value of :exports in an > unexpected way. > > If :exports code, then the noweb references are not expanded on export > to LaTeX, as expected. > > If :exports both, then the noweb references are expanded on export to > LaTeX. > > All the best, > Tom -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [BUG] Inconsistency in src block hiding
Eric Schulte writes: > Bastien writes: > >> Eric Schulte writes: >> >>> The attached patch entirely removes the #+name and #+results based >>> hiding. Note that the existing "wrap" argument to the ":results" header >>> argument will wrap results in a block which allows easy tab-based result >>> hiding. >>> >>> As this is a relatively large change I hesitate to apply it outright, >>> although I do agree that it leads to simpler more consistent behavior. >>> If general consensus seems to support the application of this patch then >>> I will be happy to apply it. >> >> Has there been any more feedback on this? >> >> Erik, is it safe to apply the patch or shall we wait more? >> > > I've received no more feedback on this patch. It should be safe as it > adds no new code but simply removes some questionable code. I will > apply this patch now. > > Best, So I'm (very) late to this party... but today I decided to track down why I can't hide my PlantUML graphics with TAB anymore... and it's this commit: --8<---cut here---start->8--- commit 8a8a56c27715740053d8a7ea2ba6411b781a22f1 Author: Eric Schulte Date: Mon Nov 28 00:43:35 2011 -0700 remove #+name and #+result hiding Given that arbitrary regions may already be hidden using a drawer the ability to hide any named entity is redundant. In addition the name based hiding does not mix well with other keywords. Thanks to Nicolas Goaziou for raising this issue and suggesting the removal of #+name based hiding. --8<---cut here---end--->8--- I actually miss being able to hide single (large) activity diagrams at work since they tend to be larger than my screen when displayed in Emacs. I can use M-x org-toggle-inline-images but that works globally on all images at once. Is there an easy way to wrap my resulting PlantUML images so I can use TAB to hide them - or is this not supported anymore? 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. Is there still a way to hide results output with the current master? Regards, Bernt
Re: [O] Minimal overhead Org-mode blogging system
On Sun, Jan 15, 2012 at 12:08 PM, Steinar Bang wrote:
>> Puneeth Chaganti :
> [snip!]
>> https://github.com/punchagan/blog-files
>
>> I've added a short README that tries to include the things that you
>> are looking for. But, it's something I wrote up quickly. Feel free
>> to ask any specific questions.
>
> I've been trying to use it, but I keep running into issues with
> reprise.pay.
>
> The latest one, is:
>
> Traceback (most recent call last):
> File "reprise.py", line 258, in
> env.get_template('cloud.html'))
> File "reprise.py", line 140, in generate_tag_cloud
> maxFreq = max(t['freq'] for t in tag_freq)
> ValueError: max() arg is an empty sequence
>
> The code for this, is:
>
> def generate_tag_cloud(entries, template):
> tags = sum([e['tags'] for e in entries], [])
> tag_freq = [{'tag': tag, 'freq': tags.count(tag)} for tag in set(tags)
> if tags.count(tag) > 3]
> maxFreq = max(t['freq'] for t in tag_freq)
> ...
>
> I've debugged this with pdb (`M-x pdb'), and tag_freq is empty.
>
> If I'm interpreting the python code correctly (I don't know python...)
> only those tags that have more than 3 occurrences will be in the
> tag_freq collection...?
>
> My problem is that I have only one article, my first, so obviously the
> tag_freq collection will stay emtpy, and reprise.py will crash...
>
> I tried removing the test, ie.
>
> def generate_tag_cloud(entries, template):
> tags = sum([e['tags'] for e in entries], [])
> tag_freq = [{'tag': tag, 'freq': tags.count(tag)} for tag in set(tags)]
> maxFreq = max(t['freq'] for t in tag_freq)
> ...
>
> but that just gave me a different error (division by zero):
>
> File "reprise.py", line 257, in
> env.get_template('cloud.html'))
> File "reprise.py", line 147, in generate_tag_cloud
> 'freq': t['freq']} for t in tag_freq]
> File "reprise.py", line 144, in normalize
> return min_r + (val - min_f) * (max_r - min_r) / float (max_f - min_f)
>
> Any ideas of how to proceed?
This is totally home brew stuff. Sorry for the trouble you are
having, in getting it to run.
Try commenting out the lines 257, 258 in reprise.py and see if that
works for you. I'll take a look later, and try to see if this can be
improved.
Thanks,
Puneeth
Re: [O] How to include section in exported Latex file, but not in table of contents
Hi Eric,
Eric S Fraga wrote:
> Viktor Rosenfeld writes:
>
> > Hi,
> >
> > I would like to include an entry of my org file in the exported Latex
> > file, but I would like the entry to be skipped in the table of contents.
> >
> > In other words, I would like to reproduce the behavior of Latex commands
> > like \section* and so on. Is this at all possible?
> >
> > I tried EXPORT_OPTIONS: toc:nil in a property drawer below the entry,
> > but that didn't work out.
> >
> > Thanks,
> > Viktor
>
> AFAIK, I don't think this is possible as headlines are exported as
> either \section or \section* depending on your num: setting for the
> whole document.
>
> However, it *is* possible to do the opposite of what you want, albeit
> with direct latex code. That is, you can have sections *not* included
> in the table of contents automatically but have those that you want
> included by adding an explicit =\addcontentsline= directive into your
> org file. For example:
>
> --8<---cut here---start->8---
> #+OPTIONS: H:3 num:nil toc:t
>
> #+LaTeX: \tableofcontents
>
> * Introduction
> This is some introductory text.
> * Included in toc
> #+LaTeX: \addcontentsline{toc}{section}{The actual entry in TOC}
> This section heading should appear in the table of contents.
> * Conclusions
> But this will not appear in the toc.
> --8<---cut here---end--->8---
>
> Unfortunately, numbering is not done at all so you would have to do this
> manually if you wanted numbers. Also note that the "toc:t" setting is
> actually ignored as you have not asked for numbering... so you have to
> explicitly ask for the table of contents yourself.
Thanks for the info. I'll try it out, but it seems somewhat brittle,
especially with a large toc.
Cheers,
Viktor
Re: [O] Hack: org-agenda-cache.el
On 16.1.2012, at 17:31, Max Mikhanosha wrote: > Hi Carsten, > > At Mon, 16 Jan 2012 16:40:01 +0100, > Carsten Dominik wrote: >> On 16.1.2012, at 13:18, Carsten Dominik wrote: >> >> Sorry, I am talking about `org-agenda-markers', and indeed, some >> care has to be taken here. Basically, the function >> org-agenda-new-marker needs to be modified to take a buffer as an >> argument, and then to push the new marker on the list of markers in >> that buffer. Also, org-agenda-save-markers-in-region needs to be >> modified. >> >> OK, this is a bit complicated, I am willing to help. If you make a >> new patch that implements the multibuffer stuff in org-agenda, I >> will look at the marker issues and implement them. > > Cool, I'll redo it and submit a patch in the next few days. The plan > is: > > - Multi-buffer support (ie buffer-local vars) goes in >unconditionally, since I think there is no way to undo making >variable buffer local, and if there is, it would make toggling on/off >function really complicated. Not really, there is `kill-local-variable'. But I agree, not big reason to make it possible to turn it off. > >About the markers, what about if I call to clean them up >kill-buffer-hook? This will work even if user kills the buffer >manually, not just on q key. Sounds good, make sure to add to the kill-buffer-hook *locally*, using org-add-hook (for XEmacs compatibility). > > - The "use existing buffer, and bury on quit" toggle needs a new >name org-agenda-reuse-buffers? Wanderlust has a similar mechanism >and its called "sticky summary buffers", so maybe >org-agenda-buffer-sticky? Sounds good to me. > > - The C-u r that you suggested to kill all buffers is already taken >by "reload with a >search string", so I think for cleanup bindings could be: > >q -> kill buffer or bury if enabled >Q -> always kill >C-u Q -> kill all agenda buffers (ie cleanup) Jup. > >Now that I'm thinking it also needs to keep track of all agenda >buffers, so need a global list. The kill-buffer hook should work >there too. You can also loop over all buffers and find the ones which are in org-agenda-mode. This is a bit easier than keeping track of them. Regards - Carsten
[O] column view extension
I've found a non-standard use case for org-mode. 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. I would use a popular wargame Warhammer 40k army list as example. The army list consist of the sections: HQ (headquarters), Elite, Troop, FA (fast attack), HS (heavy support). Every section divides further on squads and their options. Those an hierarchical structure defined. An army list has it limits on choices for points spent on, occupied slots and so on. Spreadsheets is inconvenient for roster accounting since I doesn't know the number of squad, persons it incorporates and their wargear in advance. I would rather extend it dynamically. I've tried to write some template in terms of cell-processor but found it too complicated. It have expressed perfectly in terms of tree-processor (my own name) though. I defines some kind of attribute grammar as a tree processor. The file containing referenced army list attached to the post. Org-mode gives me more powerful instrument than any spreadsheet I've meet. In two strings it can express the structure demands plenty of verbosity to be recorded in any spreadsheet. I've just defined COLUMNS property for an outline and org-mode gather all required information from its subnodes. 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. Example. Every node has its point point cost. Parent node costs calculated by summing all its subnodes cost. But I'd like to introduce new attribute: node share that represents point weight of the node among its siblings ( 100% * node.cost / parent(node).cost ). Another example. I'd like to separate node own cost from computed subnodes cost sum. That way I escape creating boring virtual parent nodes existing exclusively for summing model cost with costs of it's own wargear. I'm using org-mode for it convenience but I don't know much about lisp and can't extend org-mode. I hope someone become interested in creating spreadtree application based on existing properties code. BA.org Description: Binary data
Re: [O] [bug] Tables in lists not exported to ODT
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 K. > Eric S Fraga writes: > >> Hello, >> >> I am trying to export a document which includes small tables within a >> list. The export to PDF via Latex works perfectly. However, when I >> export to ODT, the tables simply disappear. >> >> Attached is a simple example to illustrate the effect, both org and odt >> files. >> >> I have looked at the documentation but have not seen any caveat related >> to tables. Have I missed something or is this a bug? >> >> Thanks, >> eric > > Pursuing this, to the un-trained eye (mine), the ODT code being > generated looks fine so maybe this is a libreoffice bug? > > However, when looking at content.xml, the " fontified differently than if the table had been placed outside the > list. I use "nXML" mode for looing at XML files. The fontication would > seem to indicate something strange is going on but I cannot see anything > out of the ordinary. > > Anyway, for the moment, I'll hack the document to put the table > elsewhere where it actually becomes visible as I need to get this > document out to somebody else! > > Thanks again, > eric --
Re: [O] byte-code: Error (org-odt): Cannot find factory styles files. Aborting.
Jambunathan K writes: > Hello Johnny > >>> It looks like one of your installation step is non-standard. There is an >>> easy workaround available but I would like to make sure that org-odt >>> auto-configures itself with minimal user intervention. >> >> Make on unmodified Makefile, manually moved to /usr/local/share >> direcory. > > You MUST NOT copy files by hand. You MUST use 'make install' to copy the > files. > > There are two variables - lispdir and datadir - that determine where the > lisp and styles files go. Here is the unmodified Makefile. > > , Makefile > | # Where local software is found > | prefix=/usr/local > | > | # Where local lisp files go > | lispdir = $(prefix)/share/emacs/site-lisp > | > | # Where data files go > | # $(datadir) contains auxiliary files for use with ODT exporter. > | # See comments under DATAFILES. > | datadir = $(prefix)/share/emacs/etc > ` > > If you do M-x locate-library RET org-odt RET on your current > installation, you are likely to see the following message: > , > | Library is file "/usr/local/share/emacs/org-mode" as directory. > ` > > Based on the above setting, you can modify the default lispdir as > follows: > > , Makefile > | # Where local lisp files go > | lispdir = $(prefix)/share/emacs/org-mode < > | > | # Where data files go > | # $(datadir) contains auxiliary files for use with ODT exporter. > | # See comments under DATAFILES. > | datadir = $(prefix)/share/emacs/etc > ` > > The style files will then get automatically get copied to > /usr/local/share/emacs/etc. > > It's NOT important what the values for lispdir and datadir are. What is > VERY IMPORTANT is that you use "make install" to copy the files. > >> >>> - What OS/Distrib are you using >> >> Fedora 16. > > I am on Windows. I don't use any of the Gnu/Linuxes. > > I am not sure what Fedora policy for installation is. May be org-7.8.03 > hasn't hit Fedora yet and that's the reason why you chose to download > and install by hand. > > FYI, Gentoo uses the following values for lispdir and datadir. > prefix = /usr > lispdir = $(prefix)/share/emacs/site-lisp/org-mode/ > datadir = $(prefix)/share/emacs/etc/org-mode/ > > See > http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00800.html. Thanks Jambunathan and Eric for your advice! This seems completely reasonable and a self induced error; I will try reinstall with this method in a couple of days and improve my makefile-editing / git updating skills! Cheers -- Johnny
Re: [O] Captions for src and example blocks
Hello, Christian Wittern writes: > It seems that the current LaTeX and ODT backends do not support this > out of the box, also there is no word of this in the manual, so > I assume it is still experimental? Yes. If you have the development version, you can test it. > Excuse my ignorance, but what is e-latex? Is that different from the > standard Latex export called with C-c C-e l? It's the LaTeX back-end for the new export engine, so, yes, it is different from the one used with C-c C-e l. Regards, -- Nicolas Goaziou
Re: [O] Agenda, yellow bar "delayed"
On Jan 14, 2012, at 6:33 PM, François Pinard wrote: > Let me report a tiny annoyance, nothing serious. It seems to coincide > with a recent "git pull", but the coincidence may be accidental. > > Whenever I use the "I" key to clock-in from the agenda, the background > on the agenda line used to immediately go yellow. Now, it does not > change immediately, yet if I do "r" to "redo", then it changes. Am I > alone in having observed this? I'm seeing this as well. Along with the fact that that agenda line doesn't change the status to STARTED, as it did before. And that J no longer jumps to the currently clocked in task. Running 7.8.03 (release_7.8.03.137.g812d0) — M
Re: [O] Minor org mode for achieve code folding effects
David Rogoff therogoffs.com> writes: > Carlos Russo gmail.com> writes: >> I have used both Carsten's and Eric's solution, as well as hideshow-org (https://github.com/secelis/hideshow-org), which works rather well and deserves a mention. >> Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience functions to set the outline minor mode regexps to correspond to the current comment syntax. Thus, if I'm (for instance) in shell-script mode, # * and # ** become the outline level 1 and 2 markers. > > I have all this working and it's great. But... This is using outline-minor- mode. Like Giovanni, who started this thread, I'm used to orgmode, which is a little different although it uses outline mode. I tried hacking the code to use orgstruct-mode, which is the minor mode version of orgmode. I got a little figured out, but got lost. > I would think all of Tassilo's code to automatically set up outline-regexp would still be valid, but I'm not doing something right. I saw Carsten's message to look at the visibility cycling and understand that, but the keymaps are not working right and the outline-regexp isn't being set right. I've worked around the latter with a quick function I can call from the file buffer. However, I don't know what's going on with the keymap. It looks right. For example, c-h k TAB gives this: >runs the command orgstruct-hijacker-command-102, which is an interactive Lisp function. It is bound to . > (orgstruct-hijacker-command-102 ARG) > In Structure, run `org-cycle'. > Outside of structure, run the binding of `[(tab)]' or ` '. > > However, it doesn't seem to recognize when it's in a structure. M-x org-cycle works as does M-x org-global-cycle. > > I only need this for emacs-lisp-mode and verilog-mode so I simplified Tassilo's code (for now) like this: > >(when (eq major-mode 'emacs-lisp-mode) > (setq outline-regexp ";; [*]+ ")) >(when (eq major-mode 'verilog-mode) > (setq outline-regexp "\\s-*// [*]+ ")) Anyone?
Re: [O] Hack: org-agenda-cache.el
Hi Carsten, At Mon, 16 Jan 2012 16:40:01 +0100, Carsten Dominik wrote: > On 16.1.2012, at 13:18, Carsten Dominik wrote: > > Sorry, I am talking about `org-agenda-markers', and indeed, some > care has to be taken here. Basically, the function > org-agenda-new-marker needs to be modified to take a buffer as an > argument, and then to push the new marker on the list of markers in > that buffer. Also, org-agenda-save-markers-in-region needs to be > modified. > > OK, this is a bit complicated, I am willing to help. If you make a > new patch that implements the multibuffer stuff in org-agenda, I > will look at the marker issues and implement them. Cool, I'll redo it and submit a patch in the next few days. The plan is: - Multi-buffer support (ie buffer-local vars) goes in unconditionally, since I think there is no way to undo making variable buffer local, and if there is, it would make toggling on/off function really complicated. About the markers, what about if I call to clean them up kill-buffer-hook? This will work even if user kills the buffer manually, not just on q key. - The "use existing buffer, and bury on quit" toggle needs a new name org-agenda-reuse-buffers? Wanderlust has a similar mechanism and its called "sticky summary buffers", so maybe org-agenda-buffer-sticky? - The C-u r that you suggested to kill all buffers is already taken by "reload with a search string", so I think for cleanup bindings could be: q -> kill buffer or bury if enabled Q -> always kill C-u Q -> kill all agenda buffers (ie cleanup) Now that I'm thinking it also needs to keep track of all agenda buffers, so need a global list. The kill-buffer hook should work there too. Regards, Max
Re: [O] Hack: org-agenda-cache.el
On 16.1.2012, at 13:18, Carsten Dominik wrote: > Hi Max, > > this is a pretty good solution if the main issue with slow agenda > is that it feels slow because you are often switching back and forth > between different agenda buffers. I like it, and I would vote for > integration into Org-mode, not as a separate package, but directly, > as an option. If Bastien agrees, maybe you could make a patch which > introduces this into the main code. > > Three comments: > > 1. I think there needs to be a command to remove all agenda buffers, to make > sure that everything is updated. Maybe this could be "C-u r" or so, which > would rebuilt the current and remove all others. This commands needs to make > sure that all markers are safely discarded - otherwise you will die the > marker death eventually. > > 2. I don't think that "-cache" is the best name choice for this, because this > is not a caching mechanism. It is a "multiple-agenda-buffers" thing. > > 3. One caveat for this is that maybe in some places, org-agenda-marker-table > is modified while the agenda buffer is not current (I am not sure, I just > think this needs to be checked). If so, one would need to pop to the > relevant agenda buffer to make the change. Sorry, I am talking about `org-agenda-markers', and indeed, some care has to be taken here. Basically, the function org-agenda-new-marker needs to be modified to take a buffer as an argument, and then to push the new marker on the list of markers in that buffer. Also, org-agenda-save-markers-in-region needs to be modified. OK, this is a bit complicated, I am willing to help. If you make a new patch that implements the multibuffer stuff in org-agenda, I will look at the marker issues and implement them. - Carsten > > Just my 2c, of course. > > - Carsten > On 15.1.2012, at 20:47, Max Mikhanosha wrote: > >> As my agenda files slowly grew over the years, the speed of generating >> agenda had slowly deteriorated, finally hitting the point of me jdoing >> something about it. (it got to around 5-7 seconds, which kind of >> interrupts work-flow) >> >> Attached file org-agenda-cache.el is a "quick fix" solution that I >> developed for myself, its more of a request for discussion and not >> intended as contribution yet. >> >> Basic idea is: >> >> 1. Multiple-agenda buffers can exist at the same time, having separate >> tag filters and other such settings. This is accomplished by bunch of >> org-agenda-* variables being made buffer-local. >> >> 2. Custom agenda commands should bind `org-agenda-buffer-name' variable, >> so that for example C-c a generates "*Agenda*" buffer and C-c t >> generates "*Todo List*" buffer. >> >> 3. org-agenda checks if buffer with `org-agenda-buffer-name' exists >> and if it does, it will show that buffer, rather then re-generating >> it. To generate a fresh agenda, becomes C-c a r instead of C-c a >> >> 4. org-agenda-quit buries the agenda buffer instead of killing it. >> >> 5. All of the above shenanigans can be switched on and off by doing >> M-x toggle-org-agenda-caching command, its off by default so you have >> to turn it on after loading the file. >> >> I had been using this setup for last few days, and it had really been >> a blast, returning me to the times when I just started with org-mode, >> and information had appeared in milliseconds rather then seconds. >> >> >
Re: [O] [BUG] ORG-LIST-END-MARKER when exporting from within a babel block with an exclude or include tag
> > If you export this file to PDF (C-c C-e d), babel will evaluate and > export the file as ascii. However, the ascii file will have the > undesirable "ORG-LIST-END-MARKER" in it. > Here is the resulting ascii export: > Well, this certainly is an odd problem. I can confirm that I recreated the problem locally on export to .tex and .html, but not to .txt. I had to make the following changes to your example [1] before the code block returned any results on export. To make things stranger the marker does not appear in the results when `org-export-blocks-preprocess' is run outside of a recursive export, or when the code block is evaluated interactively. I am not familiar enough with the list exporting code to know where to begin looking into this, but since the buffer does return an elisp string, one easy (though unclean) solution would be to `replace-regexp-in-string' to manually strip the "ORG-LIST-END-MARKER"s from the string. Hope this helps, Footnotes: [1] #+TITLE: Test org file #+EXPORT_INCLUDE_TAGS: test2 * First heading :test1: Testing, 1-2, 1-2. * Second heading :test2: Because we can. ** Now a list - First item - Second item #+BEGIN_SRC emacs-lisp :exports results :var buffer-file-name=(buffer-file-name) (let ((org-export-babel-evaluate nil)); don't evaluate in 'recursive' exports (org-export-as-ascii org-export-headline-levels nil nil 'string)) #+END_SRC -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Including an active timestamp in encrypted (crypt) org entries
Org encrypts everything inside a heading with the chosen tag. It does not try to be "smart" and decide what should and what should not be encrypted inside that heading. Putting the time-stamp in the headline as suggested by others should work, since org uses that information and the heading itself is not encrypted. Another solution is to put the information that must be encrypted inside a subheading and encrypt only the subheading. This way you can have all the usual org data (schedule, deadline timestamps, lognotes, etc) in the main heading and profit from the org power while all your sensitive data is still encrypted. -- Darlan
Re: [O] byte-code: Error (org-odt): Cannot find factory styles files. Aborting.
Hello Johnny >> It looks like one of your installation step is non-standard. There is an >> easy workaround available but I would like to make sure that org-odt >> auto-configures itself with minimal user intervention. > > Make on unmodified Makefile, manually moved to /usr/local/share > direcory. You MUST NOT copy files by hand. You MUST use 'make install' to copy the files. There are two variables - lispdir and datadir - that determine where the lisp and styles files go. Here is the unmodified Makefile. , Makefile | # Where local software is found | prefix=/usr/local | | # Where local lisp files go | lispdir = $(prefix)/share/emacs/site-lisp | | # Where data files go | # $(datadir) contains auxiliary files for use with ODT exporter. | # See comments under DATAFILES. | datadir = $(prefix)/share/emacs/etc ` If you do M-x locate-library RET org-odt RET on your current installation, you are likely to see the following message: , | Library is file "/usr/local/share/emacs/org-mode" as directory. ` Based on the above setting, you can modify the default lispdir as follows: , Makefile | # Where local lisp files go | lispdir = $(prefix)/share/emacs/org-mode < | | # Where data files go | # $(datadir) contains auxiliary files for use with ODT exporter. | # See comments under DATAFILES. | datadir = $(prefix)/share/emacs/etc ` The style files will then get automatically get copied to /usr/local/share/emacs/etc. It's NOT important what the values for lispdir and datadir are. What is VERY IMPORTANT is that you use "make install" to copy the files. > >> - What OS/Distrib are you using > > Fedora 16. I am on Windows. I don't use any of the Gnu/Linuxes. I am not sure what Fedora policy for installation is. May be org-7.8.03 hasn't hit Fedora yet and that's the reason why you chose to download and install by hand. FYI, Gentoo uses the following values for lispdir and datadir. prefix = /usr lispdir = $(prefix)/share/emacs/site-lisp/org-mode/ datadir = $(prefix)/share/emacs/etc/org-mode/ See http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00800.html. --
Re: [O] Hack: org-agenda-cache.el
Hi Max, this is a pretty good solution if the main issue with slow agenda is that it feels slow because you are often switching back and forth between different agenda buffers. I like it, and I would vote for integration into Org-mode, not as a separate package, but directly, as an option. If Bastien agrees, maybe you could make a patch which introduces this into the main code. Three comments: 1. I think there needs to be a command to remove all agenda buffers, to make sure that everything is updated. Maybe this could be "C-u r" or so, which would rebuilt the current and remove all others. This commands needs to make sure that all markers are safely discarded - otherwise you will die the marker death eventually. 2. I don't think that "-cache" is the best name choice for this, because this is not a caching mechanism. It is a "multiple-agenda-buffers" thing. 3. One caveat for this is that maybe in some places, org-agenda-marker-table is modified while the agenda buffer is not current (I am not sure, I just think this needs to be checked). If so, one would need to pop to the relevant agenda buffer to make the change. Just my 2c, of course. - Carsten On 15.1.2012, at 20:47, Max Mikhanosha wrote: > As my agenda files slowly grew over the years, the speed of generating > agenda had slowly deteriorated, finally hitting the point of me jdoing > something about it. (it got to around 5-7 seconds, which kind of > interrupts work-flow) > > Attached file org-agenda-cache.el is a "quick fix" solution that I > developed for myself, its more of a request for discussion and not > intended as contribution yet. > > Basic idea is: > > 1. Multiple-agenda buffers can exist at the same time, having separate > tag filters and other such settings. This is accomplished by bunch of > org-agenda-* variables being made buffer-local. > > 2. Custom agenda commands should bind `org-agenda-buffer-name' variable, > so that for example C-c a generates "*Agenda*" buffer and C-c t > generates "*Todo List*" buffer. > > 3. org-agenda checks if buffer with `org-agenda-buffer-name' exists > and if it does, it will show that buffer, rather then re-generating > it. To generate a fresh agenda, becomes C-c a r instead of C-c a > > 4. org-agenda-quit buries the agenda buffer instead of killing it. > > 5. All of the above shenanigans can be switched on and off by doing > M-x toggle-org-agenda-caching command, its off by default so you have > to turn it on after loading the file. > > I had been using this setup for last few days, and it had really been > a blast, returning me to the times when I just started with org-mode, > and information had appeared in milliseconds rather then seconds. > >
Re: [O] byte-code: Error (org-odt): Cannot find factory styles files. Aborting.
Johnny writes: > Jambunathan K writes: [...] > Please provide me information on >> - how you downloaded the Org (git? tar file? elpa?) > > I pulled the latest git version. > >> - how did you compile. Did you do a make? Did you change the Makefile at >> all? >> - how did you install. Did you do a make install? > > Make on unmodified Makefile, manually moved to /usr/local/share > direcory. The problem is that if you don't use the "make install" command, the installed files don't know where to look for the etc/styles directory! If you use "make install" with the appropriate "--prefix", you should be okay. Or, at least, that's my understanding from a quick look at the Makefile... ;-) HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.136.ge2707)
Re: [O] byte-code: Error (org-odt): Cannot find factory styles files. Aborting.
Jambunathan K writes: > Johnny writes: > >> Hi, >> >> I just upgraded to org-mode 7.8.03 (from 7.6) and now get this error >> message when trying to use the org-odt converter. With version 7.6, I used >> org-odt from contrib and that worked fine, so what is the reason for >> this error? >> >> I did see another post about this about installing "style files", but >> what are these and how do I install them? > > It looks like one of your installation step is non-standard. There is an > easy workaround available but I would like to make sure that org-odt > auto-configures itself with minimal user intervention. > > Please provide me information on > - how you downloaded the Org (git? tar file? elpa?) I pulled the latest git version. > - how did you compile. Did you do a make? Did you change the Makefile at > all? > - how did you install. Did you do a make install? Make on unmodified Makefile, manually moved to /usr/local/share direcory. > - What OS/Distrib are you using Fedora 16. > > Do you see debug messages from the org-odt module in the *Messages* > buffer. They will look something similar to this - one for schema files > and one for styles files. > > , > | Debug (org-odt): Searching for OpenDocument styles files... > | Debug (org-odt): Trying c:/Documents and Settings/kjambunathan/My > Documents/My Data/src/org-mode/etc/styles/... > | Debug (org-odt): Using styles under c:/Documents and > Settings/kjambunathan/My Documents/My Data/src/org-mode/etc/styles/ > ` Debug (org-odt): Searching for OpenDocument styles files... Debug (org-odt): Trying /usr/local/share/emacs/etc/styles/... Debug (org-odt): Trying /usr/local/share/emacs/org-mode/etc/styles/... Debug (org-odt): Trying /usr/share/emacs/23.3/etc/org/... byte-code: Error (org-odt): Cannot find factory styles files. Aborting. Maybe I should tell org-odt to search for a libreoffice directory instead? > >> Thanks for any help (and thanks for the exporter!)! -- Johnny
Re: [O] How to include section in exported Latex file, but not in table of contents
Viktor Rosenfeld writes:
> Hi,
>
> I would like to include an entry of my org file in the exported Latex
> file, but I would like the entry to be skipped in the table of contents.
>
> In other words, I would like to reproduce the behavior of Latex commands
> like \section* and so on. Is this at all possible?
>
> I tried EXPORT_OPTIONS: toc:nil in a property drawer below the entry,
> but that didn't work out.
>
> Thanks,
> Viktor
AFAIK, I don't think this is possible as headlines are exported as
either \section or \section* depending on your num: setting for the
whole document.
However, it *is* possible to do the opposite of what you want, albeit
with direct latex code. That is, you can have sections *not* included
in the table of contents automatically but have those that you want
included by adding an explicit =\addcontentsline= directive into your
org file. For example:
--8<---cut here---start->8---
#+OPTIONS: H:3 num:nil toc:t
#+LaTeX: \tableofcontents
* Introduction
This is some introductory text.
* Included in toc
#+LaTeX: \addcontentsline{toc}{section}{The actual entry in TOC}
This section heading should appear in the table of contents.
* Conclusions
But this will not appear in the toc.
--8<---cut here---end--->8---
Unfortunately, numbering is not done at all so you would have to do this
manually if you wanted numbers. Also note that the "toc:t" setting is
actually ignored as you have not asked for numbering... so you have to
explicitly ask for the table of contents yourself.
HTH,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.136.ge2707)
[O] [BUG?][babel] Re: Including source when exporting in PDF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/01/12 06:29, Frozenlock wrote:
> This babel block should do the following:
>
> - When exporting, automatically tangle the babel blocks. - Then
> take the resulting files and add them to a zip file, along with the
> original .org file. - Add the necessary \usepackage and latex
> commands to insert the zipfile.
>
> Let me know if something isn't like you want.
>
> Here is the babel block to add to your source (org) file:
>
> #+BEGIN_SRC emacs-lisp
> :results org :exports results :var
> buffer-file-name=(buffer-file-name) (let ((filename
> (file-name-nondirectory (file-name-sans-extension
> buffer-file-name (shell-command (concat "zip -j " filename
> ".zip " filename".org " (mapconcat '(lambda (arg)
> (convert-standard-filename (expand-file-name arg)))
> (org-babel-tangle) " "))) (concat
> "#+LATEX_HEADER:\\usepackage{attachfile2}\n" "#+LATEX: \\vfill
> \\textattachfile[print=false,color=0.5 0.5
> 0.5]{"filename".zip}{Source (.org) \\& other files...}\n"))
> #+END_SRC ==
Thanks for this code - it looks good, but there is a serious problem:
src_emacs_lisp{} expressions are evaluated and replaced with the
result in the org file, which does not happen when tangling from the
buffer itself.
Example:
* name src_emacs-lisp{(buffer-file-name)}
#+BEGIN_SRC emacs-lisp :results org :exports results :var
buffer-file-name=(buffer-file-name)
(org-babel-tangle)
#+END_SRC
If I export the file above, the file get changed to:
* name
#+BEGIN_SRC emacs-lisp :results org :exports results :var
buffer-file-name=(buffer-file-name)
(org-babel-tangle)
#+END_SRC
Is there something wrong with the code?
Rainer
>
>
> On a related note, I've added some improvements to my own way to
> export in multiple format and add the files along with the source.
> The latex commands and usepackage are included, so no need to add
> them elswhere in the org file:
>
> == # Make sure this babel block is the
> last one in the buffer; # block after this one won't be evaluated
> before the txt and html export. #+BEGIN_SRC emacs-lisp :results org
> :exports results :var buffer-file-name=(buffer-file-name) (let
> ((org-export-babel-evaluate nil)); don't evaluate in 'recursive'
> exports (save-window-excursion ;; avoid leakage when more than one
> org export in block (org-export-as-ascii
> org-export-headline-levels)) (save-window-excursion
> (org-export-as-html org-export-headline-levels)) (let ((filename
> (file-name-nondirectory (file-name-sans-extension
> buffer-file-name))) (to-include-files (directory-files
> (file-name-directory buffer-file-name (shell-command (concat
> "zip -j " filename ".zip " (mapconcat '(lambda (arg) arg)
> (remove-if '(lambda (file) (string-match
> "\\.$\\|\\.pdf$\\|\\.atfi$\\|\\.tex$\\|#" file)) ;; don't include
> useless files to-include-files) " "))) (concat
> "#+LATEX_HEADER:\\usepackage{attachfile2}\n" "#+LATEX: \\vfill
> \\textattachfile[print=false,color=0.5 0.5
> 0.5]{"filename".zip}{Source (.org) & html, txt...}\n"))) #+END_SRC
> ==
>
>
> Enjoy!
>
>
>
> On Thu, Jan 12, 2012 at 8:59 AM, Rainer M Krug
> wrote:
>> On 12 January 2012 14:54, Frozenlock
>> wrote:
>>> The code block I previously sent only require you to specify
>>> which _extension_ you want or don't want. No need to include
>>> any specific filename (other than the .zip file in the latex
>>> "include" command).
>>>
>>> Am I to understand you want something to include *all and only*
>>> tangled files?
>>
>> Yes - and the files do have different extensions (e.g. .R, .sh,
>> .sub, none) and are not tangled necessarily in a specific
>> directory.
>>
>> and the original org file, but that is not a problem.
>>
>> Rainer
>>
>>>
>>> --
>>>
>>> I tried ":exports result" with no success. I'll try to send a
>>> minimum working example shortly.
>>>
>>> On Thu, Jan 12, 2012 at 4:11 AM, Rainer M Krug
>>> wrote:
> On 12/01/12 03:06, Frozenlock wrote:
>> To include multiple files, I export all of the required
>> files before the PDF creation and zip them. This way, I
>> only need to include a single zip file.
>
> Good idea.
>
>>
>> #+BEGIN_SRC emacs-lisp :exports none ;; various exports
>> (save-window-excursion (org-export-as-ascii
>> org-export-headline-levels)) (save-window-excursion
>> (org-export-as-html org-export-headline-levels))
>>
>> ;;zip the required files (let ((filename
>> (file-name-sans-extension (file-name-nondirectory
>> (buffer-file-name) (shell-command (concat "zip "
>> filename ".zip " (mapconcat '(lambda (arg) arg)
>> (remove-if '(lambda (filename) (string-match
>
