[Orgmode] Re: TODO dependencies
Carsten Dominik schrieb: > On Oct 11, 2007, at 16:46, Carsten Dominik wrote: > >> - concerning the TRIGGER proposal by John, and the TRIGGER/BLOCKER >> functionality >> discussed later: In Emacs terms, this seems to translate into a *hook* >> that is called at the right moment. I'd say that a single hook is >> enough. >> The right moment to call it would be when Org-mode has figured out >> everything >> about a change that is about to occur, but before actually doing it. >> We can be general what kind of change this could be, a TODO state >> change, >> adding a tag, setting a property, changing the priority, anything >> really. > >> So we would have a property that contains a Lisp form, and that lisp >> form would >> be evaluated at that moment. >> TRIGGER would then mean to perform actions in other entries. >> BLOCKER would mean to query other entries for information, and, if >> necessary, >> abort the current action, for example by throwing to a specified >> catch form. >> Obviously, if you nee both triggers and blockers, the blockers need >> to run >> first, but we don't need separate properties/functions for this. >> >> The detailed implementation would then be a number of Lisp functions >> that >> take as arguments a *single* structure that contains all the info of >> the change, >> for example a property list like >> >> (list :type 'TODOSTATE :from nil %to "INPROGRESS" > > Due to the controversial nature of the discussion on this subject, > it seems to be better, for the time being, to keep this functionality > outside the core of org-mode. Other reasons for this are that the > free-form nature of Org-mode files do make it non-trivial to implement > dependencies in a bullet-proof way. > > I will actually take still another step back from the proposals we > discussed: I'd like to not even fix the properties that should be > used for dependencies. > > Instead, I am proposing and starting up the following route: > > Org-mode version 5.13 contains two new hooks, `org-blocker-hook' and > `org-trigger-hook'. These hooks are called before and after a state > change, respectively. Currently only TODO state changes will do > this, but more could be added in the future. > > The blocker hook is able to block a state change, the trigger > hook just happens after the change. This is all that will go into > the core for now. > > While this may seem little, it actually opens the dore wide for > a number of dependency extensions to be written, with free > choice of properties to be used and the "language" applied in > these properties to describe dependencies. In this way > we can have different implementations working alongside without > conflicts. > > As a proof of concept, I am providing a small file org-depend.el. > This is not meant as a definition of how things should be, but > as an inspiration to people who want to try their teeth at this. > > Nevertheless, this small set of functions already does most of > what at least some of you have been asking for: It introduces > the concept of chaining a sequence of TODO entries together by > insinuating only the first entry in the chain. > It also allows for entries to be identified by an :ID: property, > and this property to be used to trigger or be blocked by entries > in arbitrary places in the current file. So I hope it will be a > good starting point, I have tried to comment it well enough > so that hacking should be easy. > > Here is a copy of the documentation from that file. The file > itself is available at http://orgmode.el/org-depend.el. > > - Carsten > > ---8><><8-- > > WARNING: This file is just a PROOF OF CONCEPT, not a supported part > of Org-mode. > > This is an example implementation of TODO dependencies in Org-mode. > It uses the new hooks in version 5.13 of Org-mode, > `org-trigger-hook' and `org-blocker-hook'. > > It implements the following: > > Triggering > -- > > 1) If an entry contains a TRIGGER property that contains the word >"chain-siblings", then switching that entry to DONE does the >following: >- The sibling following this entry is marked DONE. >- The sibling also get the "chain-sibling" property, to make > sure that, when *it* is DONE, the chain will continue. > 2) If the TRIGGER property contains any other words, these are >treated as entry id's. That means, Org-mode will search for an >entry with the ID property exactly equal to this word, and >switch that entry to TODO as well. > > Blocking > > 1) If an entry contains a BLOCKER property that contains the word >"previous-sibling", the sibling above the current entry is >checked. If it is still in a TODO state, the current state >change is blocked. > 2) If the BLOCKER property contains any other words, these are >treated as entry id's. That means, Org-mode will search for an >
[Orgmode] TODO dependencies
On Oct 11, 2007, at 16:46, Carsten Dominik wrote: - concerning the TRIGGER proposal by John, and the TRIGGER/BLOCKER functionality discussed later: In Emacs terms, this seems to translate into a *hook* that is called at the right moment. I'd say that a single hook is enough. The right moment to call it would be when Org-mode has figured out everything about a change that is about to occur, but before actually doing it. We can be general what kind of change this could be, a TODO state change, adding a tag, setting a property, changing the priority, anything really. So we would have a property that contains a Lisp form, and that lisp form would be evaluated at that moment. TRIGGER would then mean to perform actions in other entries. BLOCKER would mean to query other entries for information, and, if necessary, abort the current action, for example by throwing to a specified catch form. Obviously, if you nee both triggers and blockers, the blockers need to run first, but we don't need separate properties/functions for this. The detailed implementation would then be a number of Lisp functions that take as arguments a *single* structure that contains all the info of the change, for example a property list like (list :type 'TODOSTATE :from nil %to "INPROGRESS" Due to the controversial nature of the discussion on this subject, it seems to be better, for the time being, to keep this functionality outside the core of org-mode. Other reasons for this are that the free-form nature of Org-mode files do make it non-trivial to implement dependencies in a bullet-proof way. I will actually take still another step back from the proposals we discussed: I'd like to not even fix the properties that should be used for dependencies. Instead, I am proposing and starting up the following route: Org-mode version 5.13 contains two new hooks, `org-blocker-hook' and `org-trigger-hook'. These hooks are called before and after a state change, respectively. Currently only TODO state changes will do this, but more could be added in the future. The blocker hook is able to block a state change, the trigger hook just happens after the change. This is all that will go into the core for now. While this may seem little, it actually opens the dore wide for a number of dependency extensions to be written, with free choice of properties to be used and the "language" applied in these properties to describe dependencies. In this way we can have different implementations working alongside without conflicts. As a proof of concept, I am providing a small file org-depend.el. This is not meant as a definition of how things should be, but as an inspiration to people who want to try their teeth at this. Nevertheless, this small set of functions already does most of what at least some of you have been asking for: It introduces the concept of chaining a sequence of TODO entries together by insinuating only the first entry in the chain. It also allows for entries to be identified by an :ID: property, and this property to be used to trigger or be blocked by entries in arbitrary places in the current file. So I hope it will be a good starting point, I have tried to comment it well enough so that hacking should be easy. Here is a copy of the documentation from that file. The file itself is available at http://orgmode.el/org-depend.el. - Carsten ---8><><8-- WARNING: This file is just a PROOF OF CONCEPT, not a supported part of Org-mode. This is an example implementation of TODO dependencies in Org-mode. It uses the new hooks in version 5.13 of Org-mode, `org-trigger-hook' and `org-blocker-hook'. It implements the following: Triggering -- 1) If an entry contains a TRIGGER property that contains the word "chain-siblings", then switching that entry to DONE does the following: - The sibling following this entry is marked DONE. - The sibling also get the "chain-sibling" property, to make sure that, when *it* is DONE, the chain will continue. 2) If the TRIGGER property contains any other words, these are treated as entry id's. That means, Org-mode will search for an entry with the ID property exactly equal to this word, and switch that entry to TODO as well. Blocking 1) If an entry contains a BLOCKER property that contains the word "previous-sibling", the sibling above the current entry is checked. If it is still in a TODO state, the current state change is blocked. 2) If the BLOCKER property contains any other words, these are treated as entry id's. That means, Org-mode will search for an entry with the ID property exactly equal to this word, and make sure that this entry is done as well, before allowing the state change to occur. Example: When trying this example, make sure that the settings for TODO keywords have been activated,
[Orgmode] Org-mode version 5.13
Hi everyone,
I am releasing Org-mode version 5.13 at http://orgmode.org
This is a big release. Except for severe bug fixes, the next
release will probably not be before the end of November.
Enjoy
- Carsten
Changes in Version 5.13
Overview
- Bug fixes and improvements in column view
+ All known bugs fixed.
+ A Column view can be captured into a dynamic block.
+ The ITEM column is formatted core compactly.
+ Also ITEM can be edited with `e'
- The agenda dispatcher
+ `<' cycles through restriction states.
+ Multi-character access codes to commands (= sub-keymaps).
- Sorting improvements
+ User-defined sorting keys.
+ Sorting by properties.
+ Sorting of plain lists.
- HTML structure
- Other stuff
+ New variables, several of them.
+ Drawers can be set on a per-file basis.
+ Better control over priority fontification in agenda.
+ M-up and M-down now move the current line up and down.
+ Abort remember template selection with C-g.
Details
===
Bug fixes and improvements in column view
-
- All the bugs described by Scott Jaderholm have been fixed
(at least I hope so...).
- You can now capture a column view into a dynamic block, for
exporting or printing it. The column view can be
+ global, i.e. for the entire file
+ local, i.e. for the subtree where the dynamic block is
+ from an entry with a specific :ID: property.
You can identify the entry whose column view you want to
capture by assigning an :ID: property, and use that property
in the dynamic block definition. For example:
* Planning
:PROPERTIES:
:ID: planning-overview
:END:
[...]
* The column view
#+BEGIN: columnview :hlines 1 :id "planning-overview"
#+END:
Use `C-c C-x r' to insert such a dynamic block, and you will
be prompted for the ID.
- When the current column format displays the TODO keyword,
priority or tags, these parts are stripped from the content
of the ITEM column, making for more compact and readable
entries. When any of these "properties" are not listed in
the current column format, they are instead retained in the
ITEM column.
- You can now also edit the ITEM column with `e'.
The agenda dispatcher
-
- Instead of pressing `1' to restrict an agenda command to
the current buffer, or `0' to restrict it to the current
subtree or region, you can now also press `<' once or
twice, respectively. This frees up `1' and `0' for user
commands, a request by Bastien. In fact, "<" cycles
through different restriction states. "1" and "0" are
still available for backward compatibility, until you bind
them to custom commands.
- The access code to custom agenda commands can now contain
several characters, effectively allowing to bundle several
similar commands into a sub-keymap. This follows an
excellent proposal by Adam Spiers. For example:
(setq org-agenda-custom-commands
'(("h" . "HOME + Name tag searches") ; describe prefix "h"
("hl" tags "+HOME+Lisa")
("hp" tags "+HOME+Peter")
("hk" tags "+HOME+Kim")))
- The user function option in org-agenda-custom-commands may
now also be a lambda expression, following a request by
Adam Spiers.
Sorting improvements
We are using a new routine for sorting entries, courtesy of
John Wiegley. Many thanks to John.
- You can define your own function to extract a sorting key
and in this way sort entries by anything you like.
- Entries can now be sorted according to the value of a
property.
- Plain lists can be sorted.
HTML structure
There is now a -based structure in exported HTML.
- The table of context is wrapped into a div with a class
"table-of-contents".
- The outline structure is embedded in elements with
classes "outline-1", "outline-2" etc.
- The postamble, containing the author information and the
date is wrapped into a div with class "postamble".
I am not sure if the class names are the best choice, let me
know if there are more "canonical" names we should use instead.
Thanks to Mike Newman and Cezar for input, and in particular
to Mike for his clearly formulated specification.
Other stuff
---
- New variable `org-agenda-window-frame-fractions' to
customize the size limits of the agenda window in the case
that you display the agenda window by reorganizing the
frame.
- Drawers can be set on a per-file basis using
#+DRAWERS: HIDDEN STATE PROPERTIES
This will define the drawers :HIDDEN: and :STATE:.
The :PROPERTY: dr
Re: [Orgmode] FR: toggling timestamps active/inactive
On Oct 17, 2007, at 19:18, Adam Spiers wrote: Now that I am beginning to get really serious about implementing the review component of GTD, new ideas for org-mode tweaks are continually popping into my head; apologies for spamming the list recently as a result :-) Several of the tweaks would require >15 LoC to implement, so I am thinking it might be worth sorting out copyright assignment. How should I go about this - would the following be sufficient? Please use the attached form, and let me know when the process is finished, best by sending me a scan of the final assignment (also signed by the FSF). Thanks for doing this - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] BUG: HTML export of Tags containing underscore
I believe that tags containing the underscore character are not correctly exported to HTML in v 5.12c. For example consider an org file containing: * Test ** Test :NEW_TEST: I would expect the HTML source to read: 1.1 Test NEW_TEST but instead I get 1.1 Test :NEWTEST: I understand that _ is a valid tag character from: 6 Tags ** headline. Tags are normal words containing letters, numbers, `_', and `@'. Tags must be preceded and followed by a single colon; like `:WORK:'. Several tags can be specified like `:WORK:URGENT:'. Thanks ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] property constants in elisp formulas
Hi, Is there a better way to do this? = sample file = * top :PROPERTIES: :d_5: 0 :h_5: 8 :m_5: 16 :d_4: 2 :h_4: 18 :m_4: 58 :d_3: 6 :h_3: 11 :m_3: 33 :d_2: 3 :h_2: 13 :m_2: 36 :d_1: 0 :h_1: 13 :m_1: 59 :d_0: 0 :h_0: 6 :m_0: 23 :d_n: 17 :h_n: 8 :m_n: 59 :END: *** test | | day | hour | minute | |---+-+--+| | # | 0 |8 | 16 | | # | 2 | 18 | 58 | | # | 6 | 11 | 33 | | # | 3 | 13 | 36 | | # | 0 | 13 | 59 | | # | 0 |6 | 23 | | # | 17 |8 | 59 | #+TBLFM: @2$2='(car '$PROP_d_5)::@2$3='(car '$PROP_h_5)::@2$4='(car '$PROP_m_5)::@3$2='(car '$PROP_d_4)::@3$3='(car '$PROP_h_4)::@3$4='(car '$PROP_m_4)::@4$2='(car '$PROP_d_3)::@4$3='(car '$PROP_h_3)::@4$4='(car '$PROP_m_3)::@5$2='(car '$PROP_d_2)::@5$3='(car '$PROP_h_2)::@5$4='(car '$PROP_m_2)::@6$2='(car '$PROP_d_1)::@6$3='(car '$PROP_h_1)::@6$4='(car '$PROP_m_1)::@7$2='(car '$PROP_d_0)::@7$3='(car '$PROP_h_0)::@7$4='(car '$PROP_m_0)::@8$2='(car '$PROP_d_n)::@8$3='(car '$PROP_h_n)::@8$4='(car '$PROP_m_n) Specifically, is there a better way to get at a property constant with an elisp formula? It seems the value is automatically put in parens such that $h_3 is (11) which is a little awkward. On the other hand, maybe I can use that to store a list in a property. Edd ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Column view bugs
Vagn Johansen <[EMAIL PROTECTED]> writes:
> Bastien <[EMAIL PROTECTED]> writes:
>
>> Vagn Johansen <[EMAIL PROTECTED]> writes:
>>
>>> I could also see a use for a state-dependent {:}. Display the sum of
>>> times and also the sum of times for tasks that are DONE. E.g. for
>>> adding time-estimates and measuring progress. Or maybe add up the
>>> not-DONEs to show the remaining time.
>>
>> Isn't this already achievable with a clever todo/archive structure?
>
> Sort of. But I do not want to be forced to use a specific structure.
>
> Also it gives incorrect sums if you havee subproject with with mixed
> TODO and DONE tasks.
>
I discovered that is easy to just copy the Time_Estimate value to
Time_Spent for those tasks that are DONE.
(save-excursion
(goto-char (point-min))
;; For each node
(while (re-search-forward (concat "^" outline-regexp) nil t)
;; If task is done and there is no Time_Spent property
(if (and (equal (org-entry-get (point) "TODO") "DONE")
(not (org-entry-get (point) "Time_Spent")))
;; Add Time_Spent property with the value from the
;; Time_Estimate property if available or 999000
(org-entry-put (point) "Time_Spent"
(or (org-entry-get (point) "Time_Estimate") "999000")
--
Vagn Johansen
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Reftex C-c = like menu in agenda buffer?
Bastien <[EMAIL PROTECTED]> writes: > Sivaram Neelakantan <[EMAIL PROTECTED]> writes: [...] > > Do we need really a menu for that? Since we're talking of beginners, here > > I think a quick help message in the minibuffer would be enough. > `?' is free in org-agenda-mode-map, and could be used for that. > > If you're okay with the help message, what command would you find > useful to be listed for beginners? [1] Well Save Quit Exit Log ToDo Are somethings at the top of my head. Note they're not in any order. sivaram -- ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] FR: toggling timestamps active/inactive
Bastien <[EMAIL PROTECTED]> writes: > Just one concern : if Org someday implements promoting/demoting of list > items and sublists, I think we'd like to have these keybindings: > > - S-left/right : demote/promote a list item > - S-M-left/right : demote/promote a whole sublist Of course, I was completely wrong: M-left/right does already the job of promoting/demoting list items and S-left/right is free. Sorry for the noise. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] FR: toggling timestamps active/inactive
Carsten Dominik <[EMAIL PROTECTED]> writes: >> Excellent. I'd forgotten there were so many list types/styles though, >> it seems that this might be better on some kind of cycle (like the >> priority cookies). I don't know what key binding you could use >> though. Could holding CTRL and using the arrows up/down work? > > I guess S-left/right would be quite natural for this. OK. Just one concern : if Org someday implements promoting/demoting of list items and sublists, I think we'd like to have these keybindings: - S-left/right : demote/promote a list item - S-M-left/right : demote/promote a whole sublist Therefore the keys we have for editing the headlines structure will behave quite the same for the lists structure. I believe editing the list structure would be more frequently used than switching from one list type to another. Just a thought, though. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] FR: toggling timestamps active/inactive
On Oct 17, 2007, at 11:08, Rick Moynihan wrote: Carsten Dominik wrote: On Oct 16, 2007, at 18:22, Adam Spiers wrote: Rick Moynihan ([EMAIL PROTECTED]) wrote: Adam Spiers wrote: This seems like a good idea. Another related one occurred to me today (if it's necessary) which is toggling between the two list indicators. e.g. - foo - bar - baz |<-- Point This cammand does exist, it is `C-c -'. Excellent. I'd forgotten there were so many list types/styles though, it seems that this might be better on some kind of cycle (like the priority cookies). I don't know what key binding you could use though. Could holding CTRL and using the arrows up/down work? I guess S-left/right would be quite natural for this. OK. When you are in a list, M-RET makes the next list item, C-u M-RET makes the next section, and C-RET does the same - even if for different reasons. In what sense does M-RET not DWYM? Speaking for myself I think the issue is that M-RET is a common habit for creating a series of either list-items or outlines. The problem arises when you are under an outline and press M-RET it creates a new outline, when you really wanted to start a list. Hence having a convenient toggle here to turn an outline to a list/vice-versa might be handy. Perhaps the C-c - binding (or perhaps a cyclical one) could be used to include the current outline level in the cycle. This binding would then also obviously be applicable on outlines, allowing them to be converted from outline to list. I like `C-c -' to convert from a heading to a list item. Very nice. Thanks. I don't really think we need the other way round though, you can use C-u M-RET or C-RET to directly get a heading from within a list. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Reftex C-c = like menu in agenda buffer?
Sivaram Neelakantan <[EMAIL PROTECTED]> writes: > Does it make sense to have something similar in the agenda buffer when > C-c a a is hit? of course, 1 line in the buffer at least will be lost > to this new menu. I believe this would be useful for a beginner as I > distinctly remember trying to work out the single letter sequences to > do something. The only key I was sure was 'q' to quit. Do we need really a menu for that? I think a quick help message in the minibuffer would be enough. `?' is free in org-agenda-mode-map, and could be used for that. If you're okay with the help message, what command would you find useful to be listed for beginners? [1] Notes: [1] org-agenda-mode-map maps 74 commands... -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Reftex C-c = like menu in agenda buffer?
In auctex, to see the toc, we hit C-C =; there we have a menu which goes like (r)escan (q)uit Does it make sense to have something similar in the agenda buffer when C-c a a is hit? of course, 1 line in the buffer at least will be lost to this new menu. I believe this would be useful for a beginner as I distinctly remember trying to work out the single letter sequences to do something. The only key I was sure was 'q' to quit. And in a recent thread, Carsten told me about 'x' to bury/kill the buffers. Yes, when you hit C-c a, there is already a sort of menu options but I'm talking of the agenda buffer. Once someone has mastered most of the keys, they should be able turn off the menu if they want. sivaram -- ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Totorials
On 2007-10-18 13:04 +0100, Carsten Dominik wrote: > Hi, > > I have made a new page for links to tutorials > > http://orgmode.org/tutorials.html > > Unfortunately it is still mostly a list of areas where I > could imaging a tutorial would be very useful, so let > yourself be inspired! > > - Carsten Many thanks. It is informative. There are quite a few tutorials that I haven't read before. Best, -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the most powerful email client -- http://gnus.org/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Html export suggestion (use of )
Hello, Sorry I wasn't around, but I think the 's might be ok if we also had a class for them or id to be able to style each one differently. Cheers, Cezar ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Totorials
Hi, I have made a new page for links to tutorials http://orgmode.org/tutorials.html Unfortunately it is still mostly a list of areas where I could imaging a tutorial would be very useful, so let yourself be inspired! - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: PocketMod for org-mode
Christian Egli <[EMAIL PROTECTED]> writes:
>> Should we use `cal-tex.el'-like output (very nice but very specific, and
>> not flexible)? Should we just use a straightforward verbatim display?
>> Should we use sections for agenda with multiple views?
>
> A straightforward verbatim dump of the agenda view is fine for me. In
> fact I was just going to use the ps output in my Makefile.
Try this patch against Org 5.12c:
diff -u /home/guerry/elisp/testing/org/org.el /home/guerry/elisp/testing/bzg/org.el
--- /home/guerry/elisp/testing/org/org.el 2007-10-12 20:32:10.0 +0100
+++ /home/guerry/elisp/testing/bzg/org.el 2007-10-18 13:17:18.0 +0100
@@ -17885,7 +17885,8 @@
(error "Cannot write agenda to file %s" file))
(cond
((string-match "\\.html?\\'" file) (require 'htmlize))
- ((string-match "\\.ps\\'" file) (require 'ps-print)))
+ ((string-match "\\.ps\\'" file) (require 'ps-print))
+ ((string-match "\\.tex\\'" file) (require 'org-export-latex)))
(org-let (if nosettings nil org-agenda-exporter-settings)
'(save-excursion
(save-window-excursion
@@ -17903,6 +17904,23 @@
(write-file file)
(kill-buffer (current-buffer))
(message "HTML written to %s" file))
+ ((string-match "\\.tex\\'" file)
+ (let ((buffer-file-name file))
+ (set-buffer (org-export-as-latex nil nil nil "*Org LaTeX export*")))
+ (goto-char (point-min))
+ (save-excursion
+ (when (re-search-forward "^[a-zA-Z0-9]" nil t)
+ (replace-match "begin{verbatim}\n\\&" t nil))
+ (while (re-search-forward
+ "\\([a-z]+\\){\\([^}]+\\)}\\(?:{\\([^}]+\\)}\\)?" nil t)
+ (unless (string-match "begin\\|end" (match-string 1))
+ (replace-match (or (match-string 3) (match-string 2)) t t
+ (while (re-search-forward "\\[#" nil t)
+ (replace-match "[#" t t))
+ (when (search-forward "\\end{document}" nil t)
+ (replace-match "end{verbatim}\n\\&" t nil))
+ (write-file file)
+ (message "LaTeX written to %s" file))
((string-match "\\.ps\\'" file)
(ps-print-buffer-with-faces file)
(message "Postscript written to %s" file))
Diff finished. Thu Oct 18 13:18:45 2007
This is just a temporary workaround, but it might be enough in most
cases. It performs a few checks on the LaTeX output so that links and
priorities are correctly displayed in the verbatim environment.
--
Bastien
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: PocketMod for org-mode
Bastien altern.org> writes: > Leo gmail.com> writes: > > >> Then I guess being able to export the agenda to LaTeX makes sense. > >> Can you describe what would be the expected LaTeX output for you? > > > > Anything like the following would be really really nice: > > > > http://shopping.franklincovey.com/shopping/catalog/category.jsp?displaychildren=true&id=cat1640002&crc=cat960026&sc=0709_main_oct_pp&c=0709_main_oct_pp&product=PlanningPagesbyStartDate > > Well :) Haha, maybe for xmas :-). > Thanks for these example, but what I really need is some suggestions > about the expected content of the LaTeX output itself. > > Should we use `cal-tex.el'-like output (very nice but very specific, and > not flexible)? Should we just use a straightforward verbatim display? > Should we use sections for agenda with multiple views? A straightforward verbatim dump of the agenda view is fine for me. In fact I was just going to use the ps output in my Makefile. Christian ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: PocketMod for org-mode
Leo <[EMAIL PROTECTED]> writes: >> Then I guess being able to export the agenda to LaTeX makes sense. >> Can you describe what would be the expected LaTeX output for you? > > Anything like the following would be really really nice: > > http://shopping.franklincovey.com/shopping/catalog/category.jsp?displaychildren=true&id=cat1640002&crc=cat960026&sc=0709_main_oct_pp&c=0709_main_oct_pp&product=PlanningPagesbyStartDate Well :) Thanks for these example, but what I really need is some suggestions about the expected content of the LaTeX output itself. Should we use `cal-tex.el'-like output (very nice but very specific, and not flexible)? Should we just use a straightforward verbatim display? Should we use sections for agenda with multiple views? I'd start with a simple verbatim output first. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] FR: more flexible customization of org-agenda-custom-commands key bindings
Carsten Dominik <[EMAIL PROTECTED]> writes: >> 2. Once a custom command has been invoked, provide a binding for going >>straight back to the *Org Agenda* buffer to invoke another one. > > This second part I do not understand. Please explain. Here is how I understood it, in the context of the discussion about the sub-keymaps feature: 1. call `org-agenda' 2. use a sub-keymap C-c a s 1 3. do some stuff in the .org file 4. recall org-agenda but immediately use the same keymap (C-c a s) and wait only for the *last* keystroke. Is this it, Adam? If the idea is just to re-display the *Org agenda* buffer, C-x b RET is enough most of the times. But I think the idea was to process commands of the same kind (i.e. belonging to the same sub-keymap) quickly. Maybe `C-c a &' (see C-c &) would be a good binding for this feature, if implemented. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
