[Orgmode] Re: Recurring TODOs and alreade done TODOs
Thank you very much, Matt! Everything works fine now... :-) On 03/26/2010 10:35 PM, Matt Lundin wrote: Friedericksen Hopefriedericksen.h...@gmail.com writes: First the problem: I would like to create some recurring TODO items. But for example, when I use 'C-c C-s 10-05-01 +1w' it just create the timestamp: 'SCHEDULED:2010-05-01 Sat' I don't know why, because it is exactly like in the manual described. Do I have to enable recurring TODOs in the config? I believe you have to set recurring todos by hand---i.e., dive into the org file and edit the SCHEDULED timestamp. Is there a way/function/option to automatically clear or archive old TODO-Items which are marked as DONE? Here's one way to do it: --8---cut here---start-8--- (defun my-org-archive-done-items () Archive all items marked done in the current file (interactive) (org-map-entries '(org-archive-subtree-default) /!+DONE 'file)) --8---cut here---end---8--- Best, Matt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [org-feed] Some problems with Remember the Milk and org-feed
Hi all Sven Bretfeld sven.bretf...@gmx.ch writes: As I have said before, I can recommend www.rememberthemilk.com (RTM) to capture tasks and dates on an Android phone as long as MobileOrg for Android is still under development. There are still two problems I encountered: 1. Emacs needs login information to access the RTM feed. I have not figured out yet, how to automatize that. At the moment I type in username and password once after I started a new Emacs session. I still haven't found out how to make org-feed send the login information automatically. Using .authinfo doesn't work. This cannot be a big problem for an Emacs crack (what I'm not). Any ideas? 2. I start org-feed every hour with a run-at-time function. Every 2nd or 3rd time, Emacs is unable to read the feed and hangs forever, the minibuffer saying something like Reading 18 bytes. I haven't figured out the reason for this problem yet. This problem vanished as soon as I subscribed to a pro-account of Remember the Milk. Greetings Sven ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: org-mode tutorial questionaire
I keep my stuff in git too, but recently I have found Dropbox very useful. Once I discovered how to install it on my server it meant that all my config files were automatically kept in sync on my computers. in fact Dropbox is still great even if you don't run your own server. Git is still very useful for letting you easily go back if you make a mistake, or want to start over again from an earlier version. Even better, make a git repo in your dropbox directory. Great tastes that taste great together! (There's a valid question as to whether the git repo in dropbox should be a bare repo to facilitate pushing and pulling, or a working repo so that you can use it directly. Suggestions on this point are welcome). I have a .git repo in my org folder inside Dropbox. It's not a bare repo, but I do keep a bare repo on a server and I have a cron job that automatically does a commit and pushes to my bare repo once a day. Ian. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] spreadsheet: column width behavior(s)
Are there reasons to only narrow but not to widen columns? I think this is really the only thing that makes sense. Why would you want it any wider, given the limited amount of screen real estate we have here? I don't think it would be difficult to make it behave the way you request, but I don't think I would ever use widening fields. When would you want to use this? I see, there _are_ reasons for `maximum width' (and other variants would be only additional if ever). The variant `fixed width' can be useful for the following timetable. Here it is achieved with the field content `= widen' in the last row. several columns with the same width: |---+---+---+---+---+---| | | Mon | Tue | Wed | Thu | Fri | |---+---+---+---+---+---| | 8:15 | Math | Compute= | - | Math | Compute= | | 13:15 | - | Math | Compute= | - | Math | |---+---+---+---+---+---| | / | 9 | 9 | 9 | 9 | 9 | | / | = = | = = | = = | = = | = = | instead of: |---+--+--+--+--+--| | | Mon | Tue | Wed | Thu | Fri | |---+--+--+--+--+--| | 8:15 | Math | Computer S= | -| Math | Computer S= | | 13:15 | -| Math | Computer S= | -| Math | |---+--+--+--+--+--| | / | | 12 | 12 | | 12 | or even: | Mon | 8:15 | Math | | Tue | 8:15 | Computer Science | | Tue | 13:15 | Math | | Wed | 13:15 | Computer Science | | Thu | 8:15 | Math | | Fri | 8:15 | Computer Science | | Fri | 13:15 | Math | ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Where ends a subtree?
Hi, I wonder where an subtree ends. My work flow is as follow: * headline some text... Know I notice a ToDo entry that is link to the text. So i type ** ToDo something useful notes about the ToDo ... more about the headline. My problem is, that '... more about the headline' is hidden, when the ToDo entry is folded. It belongs syntactically to ToDo, but semantically to the headline. Is there an end Tag or something like that? Where i can say: Here Ends the ToDo entry, what comes now belong to the last headline? Any Idea? Or a hint, how i can use org-mode another, better way? Greetings ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] spreadsheet: column width behavior(s)
On Mar 27, 2010, at 2:11 PM, Michael Brand wrote: Are there reasons to only narrow but not to widen columns? I think this is really the only thing that makes sense. Why would you want it any wider, given the limited amount of screen real estate we have here? I don't think it would be difficult to make it behave the way you request, but I don't think I would ever use widening fields. When would you want to use this? I see, there _are_ reasons for `maximum width' (and other variants would be only additional if ever). The variant `fixed width' can be useful for the following timetable. Here it is achieved with the field content `= widen' in the last row. several columns with the same width: |---+---+---+---+---+---| | | Mon | Tue | Wed | Thu | Fri | |---+---+---+---+---+---| | 8:15 | Math | Compute= | - | Math | Compute= | | 13:15 | - | Math | Compute= | - | Math | |---+---+---+---+---+---| | / | 9 | 9 | 9 | 9 | 9 | | / | = = | = = | = = | = = | = = | instead of: |---+--+--+--+--+--| | | Mon | Tue | Wed | Thu | Fri | |---+--+--+--+--+--| | 8:15 | Math | Computer S= | -| Math | Computer S= | | 13:15 | -| Math | Computer S= | -| Math | |---+--+--+--+--+--| | / | | 12 | 12 | | 12 | or even: | Mon | 8:15 | Math | | Tue | 8:15 | Computer Science | | Tue | 13:15 | Math | | Wed | 13:15 | Computer Science | | Thu | 8:15 | Math | | Fri | 8:15 | Computer Science | | Fri | 13:15 | Math | Yes, thinking more about it, I do agree that a fixed width makes a lot of sense as the application of N. It does now work like this. Thanks! - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Tables and Images are shifted to the end of document while exporting to tex file
I think I find where the bug is. I notice the images which are moved to
the end of the document were placed just after the footnote syntax, say:
here is the content.[fn:footnote]
[fn:footnote] here is the footnote of the content.
#+CAPTION: caption
#+LABEL: fig:caption
#+ATTR_LaTex: width=0.9\textwidth, placement=[ht]
[[file:/img/img.jpg]]
After exporting to tex file, the image part will be replaced.
Keith
Keith wrote:
Dear all,
I have a document containing total around 10 images and tables with the
attribute setting #+ATTR_LaTex: placement=[htb]. However, I notice
that two of this images and tables are placed in the end of the pdf
document where shouldn't be their place. At the beginning I thought it
might be the floating mechanism in Tex system. Nevertheless, after
trying lots of tuning in vain, I noticed the position of these image and
table were shifted to the end of the file just before \end{document}
and this causes the mistake of the position.
Does anyone has idea about it?
Keith
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] possible bug: TAB after elipsis
Hi Carsten, On 10-Mar-26, at 2:32 AM, Carsten Dominik wrote: On Mar 24, 2010, at 7:04 PM, Anthony Lander wrote: If the cursor is after the elipsis on a folded entry like this: Some entry...| pressing TAB doesn't expand the entry, or in fact, do anything useful at all. Is it possible to get it to expand the entry, or am I missing something? Cursor after the dots means the cursor is no longer in the headline, in fact it is no longer in the entry at all. I was thinking about this a bit more. Is it possible to meet in the middle and restrict the cursor so that it can't go past the last character in the headline, like this: *** Some entry|... I suggest this because if you do type after the elipsis, the text goes right on the end of the folded entry, which I believe is undesirable as well; It means that part of the entry is invisible, and part is visible. Limiting the cursor would solve both problems. Is this even feasible? Regards, -Anthony ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] spreadsheet: column width behavior(s)
Yes, thinking more about it, I do agree that a fixed width makes a lot of sense as the application of N. It does now work like this. Thank you for changing. And if someone wants `maximum width' I hope that it will be implemented with the syntax ..N as a _variant_ _additional_ to the existing N. Comparison of four variants (the last two rather useless apart from showing the completeness of the syntax): 30 : `fixed width' (the only variant implemented now) ..40 : `maximum width' (as wide as necessary but max. 40) 20.. : `minimum width' (as wide as necessary but min. 20) 20..40 : `width range' (min. 20, then up to 40, narrow only if 40) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] spreadsheet: column width behavior(s)
On Mar 27, 2010, at 6:15 PM, Michael Brand wrote: Yes, thinking more about it, I do agree that a fixed width makes a lot of sense as the application of N. It does now work like this. Thank you for changing. And if someone wants `maximum width' I hope that it will be implemented with the syntax ..N as a _variant_ _additional_ to the existing N. No, I am now convinced that this is not at all needed. Fixed is best and just fine. Thanks! - Carsten Comparison of four variants (the last two rather useless apart from showing the completeness of the syntax): 30 : `fixed width' (the only variant implemented now) ..40 : `maximum width' (as wide as necessary but max. 40) 20.. : `minimum width' (as wide as necessary but min. 20) 20..40 : `width range' (min. 20, then up to 40, narrow only if 40) - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Where ends a subtree?
On Saturday 27 March 2010 05:27 am, Franz Heuser wrote: Hi, I wonder where an subtree ends. My work flow is as follow: * headline some text... Know I notice a ToDo entry that is link to the text. So i type ** ToDo something useful notes about the ToDo ... more about the headline. My problem is, that '... more about the headline' is hidden, when the ToDo entry is folded. It belongs syntactically to ToDo, but semantically to the headline. Is there an end Tag or something like that? Where i can say: Here Ends the ToDo entry, what comes now belong to the last headline? Any Idea? Or a hint, how i can use org-mode another, better way? This appears to be the situation with Calendar and also surprisingly with Diary. Somewhere on the Emacs Wiki it suggests; no space between lines, and also to begin each new line with a dash -Such as; - item 1 - another note - some more. For me, for Diary in particular, it would be good to be able to block longer text together, and even perhpaps paragraph. I suppose it becomes less of an itemized work diary at that stage, and more of a rambling personal type, which suggests a separate or 2nd diary file altogether should be used. What do others think. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
Anthony Lander anthonylan...@yahoo.com writes: I was thinking about this a bit more. Is it possible to meet in the middle and restrict the cursor so that it can't go past the last character in the headline, like this: *** Some entry|... I suggest this because if you do type after the elipsis, the text goes right on the end of the folded entry, which I believe is undesirable as well; It means that part of the entry is invisible, and part is visible. Limiting the cursor would solve both problems. Is this even feasible? I have not been following closely this thread, but I believe customizing org-special-ctrl-a/e might bring you a long way towards the behaviour you want. I suggest you give it a try. ,[ (info (org)Headlines) ] | Documentation: | Non-nil means `C-a' and `C-e' behave specially in headlines and items. | | When t, `C-a' will bring back the cursor to the beginning of the | headline text, i.e. after the stars and after a possible TODO keyword. | In an item, this will be the position after the bullet. | When the cursor is already at that position, another `C-a' will bring | it to the beginning of the line. | | `C-e' will jump to the end of the headline, ignoring the presence of tags | in the headline. A second `C-e' will then jump to the true end of the | line, after any tags. This also means that, when this variable is | non-nil, `C-e' also will never jump beyond the end of the heading of a | folded section, i.e. not after the ellipses. ` hth memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Thanks for this, memmon. On Sat, Mar 27, 2010 at 1:02 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: Anthony Lander anthonylan...@yahoo.com writes: I was thinking about this a bit more. Is it possible to meet in the middle and restrict the cursor so that it can't go past the last character in the headline, like this: *** Some entry|... I suggest this because if you do type after the elipsis, the text goes right on the end of the folded entry, which I believe is undesirable as well; It means that part of the entry is invisible, and part is visible. Limiting the cursor would solve both problems. Is this even feasible? I have not been following closely this thread, but I believe customizing org-special-ctrl-a/e might bring you a long way towards the behaviour you want. I suggest you give it a try. ,[ (info (org)Headlines) ] | Documentation: | Non-nil means `C-a' and `C-e' behave specially in headlines and items. | | When t, `C-a' will bring back the cursor to the beginning of the | headline text, i.e. after the stars and after a possible TODO keyword. | In an item, this will be the position after the bullet. | When the cursor is already at that position, another `C-a' will bring | it to the beginning of the line. | | `C-e' will jump to the end of the headline, ignoring the presence of tags | in the headline. A second `C-e' will then jump to the true end of the | line, after any tags. This also means that, when this variable is | non-nil, `C-e' also will never jump beyond the end of the heading of a | folded section, i.e. not after the ellipses. ` hth memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Todo state for [un]ordered list items?
When I take notes at work, I tend to like to minimize my headlines and use list items instead. Part of this is simply due to how things look when exported. To use headlines for everything looks peculiar to me, at least under the default settings anyway. So... my typical work org-file is like so: * Projects ** Project 1 *** History/Overview *** Journals 2010-03-27 Sat * Main thing I did 1 - did stuff - did some more stuff - some sub stuff ** Project 2 * Talks/Courses * Ideas Most likely I'll have one heading under the timestemp shown for each activity for that project that day and the rest will be hyphen lists. My problem is that I can't make any of the unordered list items todos -- it just makes the headline a todo. I'm already at 5 headlines deep and really don't want to make headlines just for a todo that has it's place in my bulleted notes. My questions are: - Does anyone else find the idea of an unordered todo helpful, but one that's not part of a headline? - If so, how could it be implemented? - If not, I'm absolutely game to hear alternative work flows and how others manage without this feature at present! --- So far, I've just been making the headline a TODO and then putting in a [/] at the top; unordered list items that are todos also have a [ ] which is tracked by the top level todo. - Bonus: if this is the best (headline = todo and unordered lists are check boxes), how can I implement a shortcut to toggle the 'todo checkbox' state for unordered list items? It would be awesome to have a C-c C-t equivalent for sub-items such that they were given a checkbox! Many thanks, John ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: possible bug: TAB after elipsis
Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] GtD with org-mode and a Palm PDA
Dear org-moders,
I use org-mode for lots of things and love it. Recently I have been
using it more for implementing David Allen's Getting Things Done and
have written a couple of perl scripts and a supporting shell script to
facilitate this. I hope they might be of use to others.
I normally work at my desktop computer and when inputs arrive or things
occur to me that I'm going to have to deal with I just use org-remember
to put them into an inbox.org file. However, I also work in other
places and keep a Palm TX with me. I use Slap on the Palm to enter
similar quick thoughts and pass them to the Memos database, where I
give them a category of Inbox. I sync my palm with the desktop
using JPilot and then the palm2org.pl perl script moves these Inbox
memos to the end of my inbox.org file on the desktop as a preliminary
step in my weekly GtD review. During the week I also use the ToDo list
on my Palm to decide what to work on next, checking off ToDos as they
are completed. The same script uses these completed ToDos to
change the TODOs in my projects.org file to DONE - again, this is a
first step in my review.
I then perform my weekly review, going through projects.org and
identifying next actions, which I then toggle as TODOs and assign
tags which will become GtD contexts for the tasks (e.g. @Library,
Phone, Email etc.)
After completing the review, the second perl script org2palm.pl uses
the list of TODOs in my projects.org to rebuild the ToDo list on the
Palm TX. It also clears all memos from the Inbox category on the palm,
since these have now been incorporated into projects.org. Running this
perl script as part of the org2palm shell script completes the process
by uploading the updated ToDos and Memos lists to the Palm.
I also use the Palm calendar of course, but I enter items there by
hand, so have not felt a need to automate that process.
I have pasted the scripts below rather than adding them as
attachments.
I am happy for others to use or modify the scripts as they wish (I am
no expert perl or shell programmer and no doubt many people can think of
improvements). I have only tested and used them on FreeBSD using
JPilot and pilot-xfer to sync the Palm TX and desktop. I imagine they
would work about the same on Linux. Some of the paths at the start of
the scripts would need modifying for use on Windows and the shell
script would need to be replaced by a batch file, but I don't imagine
those modifications would be too difficult.
I hope this is of some use, I have certainly found the process helpful
in my own work.
Tony
P.S. I know Palm devices are old fashioned now, but as long as my TX
works I have no desire to use anything else and I guess there are other
orgers in a similar position.
--
palm2org.pl:
#!/usr/bin/perl
# palm2org
# Use the Palm ToDo list to check off completed tasks in org
# This should be run after syncing palm with jpilot and before
# the weekly GtD review.
# Also import Palm Memos in the Inbox category and append
# them to the org-mode inbox.org file. These memos are
# used for collecting inputs during the week. Once
# transferred to org-mode the program org2palm can be used
# to clear them on the palm (org2palm should be run *after*
# a GtD weekly review.
use strict;
use warnings;
use autodie;
use File::Copy;
use Palm::ToDo;
use Palm::StdAppInfo;
# Locations of the relevant files
my $palmdir = $ENV{HOME}/.jpilot;
my $tododb = $palmdir/ToDoDB.pdb;
my $memodb = $palmdir/MemosDB-PMem.pdb;
my $orgdir = $ENV{HOME}/org;
my $projects = $orgdir/projects.org;
my $inbox = $orgdir/inbox.org;
my $backup_projects = $orgdir/projects.bak;
my $backup_inbox = $orgdir/inbox.bak;
# Mark completed ToDos in projects.org
# Does the org projects file need to be updated?
my $savenew = 0;
# Read the existing org projects list into an array
open(my $fh, '', $projects);
my @orglines = $fh;
close($fh);
# Load the Palm ToDo database
my $pdb = new Palm::PDB;
$pdb-Load($tododb);
# Use ToDos marked completed to update the org projects lines
my @records = @{$pdb-{records}};
foreach my $record (@records) {
if ($record-{completed}) {
my $description = $record-{description};
# Find this record in the projects list and change TODO to DONE
foreach my $i (0..$#orglines) {
if ($orglines[$i] =~ /^\*+\sTODO\s+$description/ ||
$orglines[$i] =~ /^\*+\sTODO\s\[#[A-C]\]\s+$description/) {
$orglines[$i] =~ s/TODO/DONE/;
$savenew++;
}
}
}
}
# Update the org projects file if necessary, saving a backup
if ($savenew) {
copy($projects, $backup_projects);
open(my $fh, '', $projects);
foreach my $orgline (@orglines) {
print $fh $orgline;
}
close($fh);
print $savenew task;
if ($savenew 1) {
print s were;
}
else {
[Orgmode] Re: Todo state for [un]ordered list items?
John Hendy jw.he...@gmail.com writes: * Projects ** Project 1 *** History/Overview *** Journals 2010-03-27 Sat * Main thing I did 1 - did stuff - did some more stuff - some sub stuff ** Project 2 * Talks/Courses * Ideas Most likely I'll have one heading under the timestemp shown for each activity for that project that day and the rest will be hyphen lists. My problem is that I can't make any of the unordered list items todos -- it just makes the headline a todo. I'm already at 5 headlines deep and really don't want to make headlines just for a todo that has it's place in my bulleted notes. First, I would suggest a different organisation. You are 5 headlines deep, because you chose this kind of setup, but with some tweaking, you could avoid this: a) Give each Project an own file. b) Don't give dates a headline. So, you would have a file like this: * Project 1 ** History/Overview ** Journals *** DONE Main thing I did 1 2010-03-27 Sat *** TODO Stuff 2 *** TODO Stuff 3 If you want to review what you did on a specific day, use the agenda for this. For substuff, if it is really not worth a separate task, there are lists. - If not, I'm absolutely game to hear alternative work flows and how others manage without this feature at present! --- So far, I've just been making the headline a TODO and then putting in a [/] at the top; unordered list items that are todos also have a [ ] which is tracked by the top level todo. - Bonus: if this is the best (headline = todo and unordered lists are check boxes), how can I implement a shortcut to toggle the 'todo checkbox' state for unordered list items? It would be awesome to have a C-c C-t equivalent for sub-items such that they were given a checkbox! I do not understand, did you miss this: ,[ (info (org)The very busy C-c C-c key) ] |- If the cursor is in a plain list item with a checkbox, toggle the | status of the checkbox. ` To make a checkbox without typing [ ], use C-c C-x C-b: ,[ (info (org)Checkboxes) ] | `C-c C-x C-b' | Toggle checkbox status or (with prefix arg) checkbox presence at | point. With double prefix argument, set it to `[-]', which is | considered to be an intermediate state. | - If there is an active region, toggle the first checkbox in | the region and set all remaining boxes to the same status as | the first. With a prefix arg, add or remove the checkbox for | all items in the region. | | - If the cursor is in a headline, toggle checkboxes in the | region between this headline and the next (so _not_ the | entire subtree). | | - If there is no active region, just toggle the checkbox at | point. ` If you need this very often, you may want to bind this to an easier keycombo. Did this help so far? memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Todo state for [un]ordered list items?
On Sat, Mar 27, 2010 at 2:15 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes * Projects ** Project 1 *** History/Overview *** Journals 2010-03-27 Sat * Main thing I did 1 - did stuff --snip-- First, I would suggest a different organisation. You are 5 headlines deep, because you chose this kind of setup, but with some tweaking, you could avoid this: a) Give each Project an own file. b) Don't give dates a headline. So, you would have a file like this: * Project 1 ** History/Overview ** Journals *** DONE Main thing I did 1 2010-03-27 Sat *** TODO Stuff 2 *** TODO Stuff 3 I started this way (pro1.org, pro2.org, etc.) but found changing buffers constantly to be annoying. I much prefer them all in one place now, but am still open to changing that! I can see advantages to the one-file-per-project idea. For instance I just wrote up a paper at home and exporting to html/latex was far easier since it had the whole file to play in. I would have had a harder time getting just my paper out of a whole ' personal.org' file... Followup/claification: - what are your pro/cons for why you go one file per project vs. a big file? I know different people have different opinions on this. I believe Carsten said in at least one of his main talks on org-mode that he has on big one as does Sacha Chua who I emailed with a little and uses org-mode a ton. - The journals are not always todos. Sometimes they are just notes, but need a time stamp anyway. I can see your point of doing it that way. I burn a headline level just on the time stamp. - My main purpose of the time stamps is that I need to print my status and then double side tape it into an intellectual property notebook. I think I can do this with agenda. Side note: I wonder about putting one file vs. many files in this new 'beginner tutorial' to help new people choose a set up when first starting? Might be cool. Not to say one is better, but to at least offer what I'm looking for: experience users' input as to what is benefited from one style vs. the other and what functionality is gained/lost/tougher. If you want to review what you did on a specific day, use the agenda for this. For substuff, if it is really not worth a separate task, there are lists. I will look into agenda more. Have not explored it's functionality much yet. Been on org-mode for about 2 weeks! - If not, I'm absolutely game to hear alternative work flows and how others manage without this feature at present! --- So far, I've just been making the headline a TODO and then putting in a [/] at the top; unordered list items that are todos also have a [ ] which is tracked by the top level todo. - Bonus: if this is the best (headline = todo and unordered lists are check boxes), how can I implement a shortcut to toggle the 'todo checkbox' state for unordered list items? It would be awesome to have a C-c C-t equivalent for sub-items such that they were given a checkbox! I do not understand, did you miss this: ,[ (info (org)The very busy C-c C-c key) ] |- If the cursor is in a plain list item with a checkbox, toggle the | status of the checkbox. ` Sorry, this is not what I meant. You answered my 'state' question in your next point with C-c C-x C-b. I know how to toggle the checkbox 'state'... I meant to toggle the state of having a checkbox... period, aka go from - item 1 to - [ ] item 1 To make a checkbox without typing [ ], use C-c C-x C-b: ,[ (info (org)Checkboxes) ] | `C-c C-x C-b' | Toggle checkbox status or (with prefix arg) checkbox presence at | point. With double prefix argument, set it to `[-]', which is | considered to be an intermediate state. | - If there is an active region, toggle the first checkbox in | the region and set all remaining boxes to the same status as | the first. With a prefix arg, add or remove the checkbox for | all items in the region. | | - If the cursor is in a headline, toggle checkboxes in the | region between this headline and the next (so _not_ the | entire subtree). | | - If there is no active region, just toggle the checkbox at | point. ` This is what I was looking for. Dumb that I missed it. In my skimming, only the 'toggle checkbox status' descriptions were popping out to me so it seemed to be for something of a tree-level C-c C-c vs. what it actually does. Even after re-reading it, though, it seems confusing: - I don't get what a '[double] prefix arg' is. C-c C-x C-b does indeed, add a check box to an unordered list item no matter where I am on the line, but according to this, since I'm not providing a prefix argument (with C-u, right?), it should only toggle the status? But there is no 'status' so it adds? - How do I get the box to go away if I don't want it anymore? If you need this very
Re: [Orgmode] suggestion: display of #+TITLE
I like it. This is a great little piece of work. Thanks a lot. Scot On Fri, Mar 26, 2010 at 3:34 AM, Dan Davison davi...@stats.ox.ac.uk wrote: Carsten, Scot -- Scot Becker scot.bec...@gmail.com writes: Or what about---in the spirit of the 'hidden' outline stars---the option to set #+TITLE: and friends in a 'barely visible' color, and in the 'standard' font of the document, if that's possible. OK, I understand that suddenly-disappearing text might be confusing. My intention was to help in the current efforts to avoid making org seem too technical to people coming from more mainstream software, by providing a clean document title. But OK, so magical hiding off by default. Scot's suggestion seems like a good intermediate position. Below is a new version of the patch which follows that. I resisted the temptation to go crazy with the barely visible-ness, just the same as other dimmed text in org (archived, code, etc). An image is at http://www.princeton.edu/~ddavison/org-faces/Default-MidnightBlue-DimmedKeywords.pnghttp://www.princeton.edu/%7Eddavison/org-faces/Default-MidnightBlue-DimmedKeywords.png As sexy as it is, really hiding the markup is a fair break from most (all?) of 'standard' org mode, Right, apart from links I guess. Org users are used to sudden hiding behaviour on their part. [...] On Wed, Mar 24, 2010 at 2:52 PM, Carsten Dominik carsten.domi...@gmail.com wrote: Hi Dan, I think the patch is almost good. I do like the larger face for the title, and I know that some themes also use larger faces for headlines. But I think we at least need a variable governing if the keyword will be made invisible or not. In addition to the new faces, I've introduced a new variable org-hidden-keywords which is a list of special keywords to hide, with a customise interface. At the moment that allows for hiding of #+TITLE, #+AUTHOR, #+DATE and #+EMAIL. By default all hiding is off. Dan --8---cut here---start-8--- diff --git a/lisp/org-faces.el b/lisp/org-faces.el index e336b3c..fc80e82 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -59,6 +59,19 @@ The foreground color of this face should be equal to the background color of the frame. :group 'org-faces) +(defface org-dim; similar to shadow + (org-compatible-face 'shadow +'class color grayscale) (min-colors 88) (background light)) + (:foreground grey50)) + (((class color grayscale) (min-colors 88) (background dark)) + (:foreground grey70)) + (((class color) (min-colors 8) (background light)) + (:foreground green)) + (((class color) (min-colors 8) (background dark)) + (:foreground yellow + Face used to de-emphasise text by dimming. + :group 'org-faces) + (defface org-level-1 ;; originally copied from font-lock-function-name-face (org-compatible-face 'outline-1 'class color) (min-colors 88) (background light)) (:foreground Blue1)) @@ -468,6 +481,41 @@ changes. :group 'org-faces :version 22.1) +(defface org-document-title + 'class color) (background light)) (:foreground midnight blue :weight bold :height 1.44)) +(((class color) (background dark)) (:foreground steel blue :weight bold :height 1.44)) +(t (:weight bold :height 1.44))) + Face for document title, i.e. that which follows the #+TITLE: keyword. + :group 'org-faces) + +(defface org-document-author + 'class color) (background light)) (:foreground midnight blue)) +(((class color) (background dark)) (:foreground steel blue))) + Face for document author, i.e. that which follows the #+AUTHOR: keyword. + :group 'org-faces) + +(defface org-document-email + (org-compatible-face 'org-document-author '((t nil))) + Face for document email, i.e. that which follows the #+EMAIL: keyword. + :group 'org-faces) + +(defface org-document-date + (org-compatible-face 'org-document-author '((t nil))) + Face for document date, i.e. that which follows the #+DATE: keyword. + :group 'org-faces) + +(org-copy-face 'org-dim 'org-document-title-keyword + Face for #+TITLE: keyword.) + +(org-copy-face 'org-dim 'org-document-author-keyword + Face for #+AUTHOR: keyword.) + +(org-copy-face 'org-dim 'org-document-email-keyword + Face for #+EMAIL: keyword.) + +(org-copy-face 'org-dim 'org-document-date-keyword + Face for #+DATE: keyword.) + (defface org-block (org-compatible-face 'shadow 'class color grayscale) (min-colors 88) (background light)) diff --git a/lisp/org.el b/lisp/org.el index dad8649..4410f46 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2975,6 +2975,17 @@ lines to the buffer: :group 'org-font-lock :type 'boolean) +(defcustom org-hidden-keywords nil + List of keywords that should be hidden when typed in the org buffer. +For example, add #+TITLE to this list in order to make the
[Orgmode] Checkbox Statistics (was: Todo state for [un]ordered list items?)
Hi, btw, it is easier to keep multiple questions in separate mails with separate subjects. Thus, more people will read and answer (easier to identify the topic, shorter so quicker to skim over etc.). John Hendy jw.he...@gmail.com writes: P.S. Somewhat un-related, but while taking about lists... In an unordered list like this (my todo list for today) [...] Still under the todo headline whether -floors is a checkbox or not? Shouldn't they be counted? Based on the example here ( http://www.gnu.org/software/emacs/manual/html_node/org/Checkboxes.html), I should get the behavior I expect. In fact, when yanking it into my file, I get this instead of what's shown on the tutorial page: * TODO Organize party [1/3] (instead of [3/6] - call people [1/3] - [ ] Peter - [X] Sarah - [ ] Sam - [X] order food - [ ] think about what music to play - [X] talk to the neighbors Bug or something in .emacs that I'm unaware of? This is not the current example: ,[ (info (org)Checkboxes) ] | * TODO Organize party [2/4] |- [-] call people [1/3] | - [ ] Peter | - [X] Sarah | - [ ] Sam |- [X] order food |- [ ] think about what music to play |- [X] talk to the neighbors ` See the [-] cookie? Always use the documentation provided for your version! Orgmode is a moving quickly. Using C-h a org checkbox, I found this var: ,[ (info (dir)Top) ] | org-hierarchical-checkbox-statistics is a variable defined in `org-list.el'. | | Documentation: | Non-nil means, checkbox statistics counts only the state of direct children. | When nil, all boxes below the cookie are counted. | This can be set to nil on a per-node basis using a COOKIE_DATA property | with the word recursive in the value. ` and in the manual ,[ (info (org)Checkboxes) ] |(1) Set the variable `org-hierarchical-checkbox-statistics' if you | want such cookies to represent the all checkboxes below the cookie, not | just the direct children. ` So, for general behaviour, use (setq org-hierarchical-checkbox-statistics nil) On a file-wide basis, add something like: #+PROPERTY: COOKIE_DATA recursive On a per-headline basis, use * Task [/] :PROPERTIES: :COOKIE_DATA: recursive :END: I do not use checkboxes, but that should do. #+PROPERTY: COOKIE_DATA recursive checkbox * TODO Organize party [2/7] :PROPERTIES: :COOKIE_DATA: recursive checkbox :END: - [-] call people [1/2] - [ ] Peter - [X] Sarah - [ ] Sam - [X] order food - [ ] think about what music to play - [ ] talk to the neighbors Problem solved ;) Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: possible bug: TAB after elipsis
John Hendy jw.he...@gmail.com writes: Very cool and good point about unfolding. I've basically been doing the same things. Thanks for the speed keys link, especially. I've just got to sit down and read the whole manual some weekend... there's so much and since I am usually searching under 'problem-based' motivation, there's so many helpful things I might never find that way! On Sat, Mar 27, 2010 at 1:53 PM, Memnon Anon gegendosenflei...@googlemail.com wrote: John Hendy jw.he...@gmail.com writes: This awesome. If this equivalent existed for M-a/e and M-f/b, I would be very happy with the result. Seem reasonable -- when on a folded headline, I just can't think of a reason someone would want to interact with the headline after the ellipsis. It even, as someone else mentioned, can ge one into trouble -- press the wrong key or delete after it and you're removing text you can't even see... but are able to interact with! Well, after all, its just Plain Text you are editing. Whenever there is an Elipsis, there is a convenient hack in the display hiding what you don't want to see, but it is never the less a hack. So I got into the habbit that, whenever I edit a line that contains ..., I unfold it first; whenever it is folded, I only a ) view it or b) navigate with the org commands like the speed keys (http://orgmode.org/manual/Speed-keys.html) or c) use the org structure editing command (http://orgmode.org/manual/Structure-editing.html). For extensive editing with emacs board tools, there is always M-x show-all. So, I agree, whenever there are ellipsis, editing it ... can get one into trouble. So I just don't ;). hth Memnon Sorry about the premature post - send key malfunction :) One other thing I've done for dealing with folded text is use my binding for F9-v which toggles visibility mode on and off. This unfolds _everything_ and makes it possible to see what you are changing (usually because I accidentally edited something in a folded region and want to see exactly what I'm undoing to fix it) (global-set-key (kbd f9 v) 'visible-mode) HTH, Bernt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug in org-crypt?
Hi, If you have the follow org file * test crypt :crypt: ** subheading 1 text 1 ** subheading 2 text 2 with setup as (require 'org-crypt) (setq org-tags-exclude-from-inheritance '(crypt)) (setq org-crypt-key CBC0714E) ; my key On calling org-encrypt-entry on the first head line, only subheading 1 get encrypted, subheading 2 remains plain text. But, if you add an empty line or some text under the first heading, both subheading 1 and 2 are encrypted. Testing on recent git checkout results the same. Is it a bug? -- Jc/*__o/* X\ * (__ Y*/\ ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] suggestion: display of #+TITLE
Thanks Scot, here's the final version of my proposed patch (no change in outward appearance from previous version). By default, title, author, date and email lines appear in dark blue with the initial keywords greyed out. The title is in a larger font than the others. To change that appearance, customise the faces org-document-title org-document-info org-document-info-keyword In addition, the variable org-hidden-keywords can be used to make any of those keywords disappear. You can use the customize interface for this, or e.g. (setq org-hidden-keywords '(title date)) Dan --8---cut here---start-8--- diff --git a/lisp/org-faces.el b/lisp/org-faces.el index e336b3c..8ec7ce1 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -468,6 +468,34 @@ changes. :group 'org-faces :version 22.1) +(defface org-document-title + 'class color) (background light)) (:foreground midnight blue :weight bold :height 1.44)) +(((class color) (background dark)) (:foreground pale turquoise :weight bold :height 1.44)) +(t (:weight bold :height 1.44))) + Face for document title, i.e. that which follows the #+TITLE: keyword. + :group 'org-faces) + +(defface org-document-info + 'class color) (background light)) (:foreground midnight blue)) +(((class color) (background dark)) (:foreground pale turquoise)) +(t nil)) + Face for document date, author and email; i.e. that which +follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword. + :group 'org-faces) + +(defface org-document-info-keyword + (org-compatible-face 'shadow +'class color grayscale) (min-colors 88) (background light)) + (:foreground grey50)) + (((class color grayscale) (min-colors 88) (background dark)) + (:foreground grey70)) + (((class color) (min-colors 8) (background light)) + (:foreground green)) + (((class color) (min-colors 8) (background dark)) + (:foreground yellow + Face for #+TITLE:, #+AUTHOR:, #+EMAIL: and #+DATE: keywords. + :group 'org-faces) + (defface org-block (org-compatible-face 'shadow 'class color grayscale) (min-colors 88) (background light)) diff --git a/lisp/org.el b/lisp/org.el index dad8649..e30c49a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2975,6 +2975,17 @@ lines to the buffer: :group 'org-font-lock :type 'boolean) +(defcustom org-hidden-keywords nil + List of keywords that should be hidden when typed in the org buffer. +For example, add #+TITLE to this list in order to make the +document title appear in the buffer without the initial #+TITLE: +keyword. + :group 'org-font-lock + :type '(set (const :tag #+AUTHOR author) + (const :tag #+DATE date) + (const :tag #+EMAIL email) + (const :tag #+TITLE title))) + (defcustom org-fontify-done-headline nil Non-nil means change the face of a headline if it is marked DONE. Normally, only the TODO/DONE keyword indicates the state of a headline. @@ -4681,6 +4692,17 @@ will be prompted for. ((string= block-type verse) (add-text-properties beg1 end1 '(face org-verse t)) + ((member dc1 '(title: author: email: date:)) + (add-text-properties +beg (match-end 3) +(if (member (intern (substring dc1 0 -1)) org-hidden-keywords) +'(font-lock-fontified t invisible t) + '(font-lock-fontified t face org-document-info-keyword))) + (add-text-properties +(match-beginning 6) (match-end 6) +(if (string-equal dc1 title:) +'(font-lock-fontified t face org-document-title) + '(font-lock-fontified t face org-document-info ((not (member (char-after beg) '(?\ ?\t))) ;; just any other in-buffer setting, but not indented (add-text-properties --8---cut here---end---8--- Scot Becker scot.bec...@gmail.com writes: I like it. This is a great little piece of work. Thanks a lot. Scot On Fri, Mar 26, 2010 at 3:34 AM, Dan Davison davi...@stats.ox.ac.uk wrote: Carsten, Scot -- Scot Becker scot.bec...@gmail.com writes: Or what about---in the spirit of the 'hidden' outline stars---the option to set #+TITLE: and friends in a 'barely visible' color, and in the 'standard' font of the document, if that's possible. OK, I understand that suddenly-disappearing text might be confusing. My intention was to help in the current efforts to avoid making org seem too technical to people coming from more mainstream software, by providing a clean document title. But OK, so magical hiding off by default. Scot's suggestion seems like a good intermediate position. Below is a new version of the patch which follows that. I resisted the temptation to go crazy with the barely visible-ness, just the same as other dimmed text
