Re: [O] [PATCH] Add Time-stamp: in (first 8 lines of) export template
On Tue, Mar 20, 2012 at 7:45 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Then, I can provide a patch with `time-stamp' function added to `before-save-hook' in Org mode. I would lobby against this being the default template, as these time stamps really mess up the ability to merge org files from multiple branches without conflicts. A --- B --- D \ / \C/ At the merge, D would have a conflict to resolve by hand. I used timestamps and the save hook mentioned above for a while and ended up needing to do unnecessary (and in the context of a rev control like GIT - non-useful) manual conflict resolution, so have since removed them from every file I had previously added them to. Just my $0.02. Brian --- midlife...@wightmanfam.org
Re: [O] Archiving old instances of repeating todos
On Wed, Feb 15, 2012 at 5:33 AM, Bernt Hansen be...@norang.ca wrote: lbml...@hethcote.com writes: How do you archive old instances of repeating todos, C-c C-x C-s archives the whole thing. I'd like to have something that would take the following: ** TODO Mutter an oath DEADLINE: 2012-02-13 Mon ++1d -0d - State DONE from TODO [2012-02-12 Sun 16:25] I also note that you do not keep your state messages inside of a logbook drawer. If you are just concerned with seeing the data and not with it accumulating there, you could stuff it inside a LOGBOOK drawer. (setq org-clock-into-drawer t) or the equivalent configuration options should configure this. --Brian
Re: [O] Temp files from testing are permanent...
On Wed, Feb 15, 2012 at 11:11 AM, Achim Gratz strom...@nexgo.de wrote: Olaf Meeuwissen olaf.meeuwis...@avasys.jp writes: If running `make check` (or similar) creates these files, `make clean` (or similar) should clean them up. I was asking that question to decide whether I do need to extend my Makefile fork to handle the cleanup or if the testsuite needs to be called differently to avoid leaving these stale files. ... It would also seem logical that for debugging purposes one could leave the files around. If created with make-temp-file, and created in the system-configured $TMPDIR directory, I would urge (wearing my sysadmin hat) that they get purged at the end of the test run, unless told to do otherwise. If created in the build/test directory, then either make clean or immediate purge seems reasonable. Files created in the system $TMPDIR are not meant (caution: purist view) to remain beyond the execution of the program (or set of programs). Some OS variants are set up to purge the $TMPDIR on reboot, login, or at other times, and some even store it in a virtual memory backed filesystem. When performing as a sysadmin, finding that an application has littered a (usually) limited system resource such as the system $TMPDIR with files that are no longer useful is a minor irritant at best, to a crash-inducing resource consumer at worst. Just my $0.02 if you are taking donations. Brian
Re: [O] Question about repeating events.
On Thu, Jan 12, 2012 at 10:13 AM, Sam Auciello ollei...@gmail.com wrote: I'm trying to set up repeating events to stop repeating after a given date. In this case it's classes I'm taking this semester that need to repeat once a week so I enter them like: *** Programming Workshop 2012-01-24 Tue 13:30-14:50 +1w, 2012-01-20 Fri 13:30-14:50 +1w The agenda shows the class being scheduled each tuesday and friday but I would like to tell it to stop repeating at the end of the semester. Would diary-style datestamps work? http://orgmode.org/manual/Timestamps.html#Timestamps Brian
Re: [O] [ANN] Org Elements in contrib
On Mon, Nov 21, 2011 at 12:50 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: I've added org-element.el in contrib directory. It is a complete parser and interpreter for Org syntax. While it was written to be extensible, it is also an attempt to normalize current syntax and provide guidance for its evolution. This is also a good thing (IMO) from the viewpoint of being able to provide external (non-org-mode) parsers for org-mode files. If org-element is the canonical definition of org syntax (not semantics, just syntax), all other parsers must adhere to this or they are in error. A slight evolution of this would be to have this definition defined in the tests, and have org-element, or any other parser, adhere to those tests. Defining a canon for org-mode syntax is, in any form, a big step forward. Brian
Re: [O] Not overwriting unchanged source code files when tangling
On Fri, Nov 18, 2011 at 7:17 AM, Holger Hoefling hhoef...@gmail.com wrote: I have a problem/request for org-mode and was looking for help. I am using org-mode to write source code files and tangle them out. I want to compile them using make. My problem now is that org-mode overwrites the old files every time I tangle them out, therefore also updating the time stamp - even if nothing has changed. Subsequently, when I run make, everything gets recompiled, not just the changed source code files as all time stamps have changed. Is there an option for org-mode to only overwrite source code files that get tangled out if they have truly changed? I believe that to do this, you would need to have a dependency tree of the nodes contributing to the output (perhaps already exists), and recursively mark any node that refers to a node that changed as dirty. You would also have to store last update times on each node so that they could be compared to each output file, contributing to the determination of needing a regeneration or not. From a make standpoint, if you were to have each node in a file (I am not recommending this), make already has the smarts to handle this. It just becomes unwieldy to manage from an editing perspective. Perhaps a way to deal with this would be to tangle to a different directory, and then sync any changes into your compilation source directory. If you would update the compilation directory only when something differs from the tangle directory, then make could handle it from that point on. Brian
Re: [O] Not overwriting unchanged source code files when tangling
On Fri, Nov 18, 2011 at 10:46 AM, Tom Prince tom.pri...@ualberta.net wrote: On Fri, 18 Nov 2011 08:23:18 -0600, Brian Wightman midlife...@wightmanfam.org wrote: Perhaps a way to deal with this would be to tangle to a different directory, and then sync any changes into your compilation source directory. If you would update the compilation directory only when something differs from the tangle directory, then make could handle it from that point on. The tangle mechanism could probably handle this autoatically. i.e. not saving a file if the contents are identical. If there is not a lot of extra memory / time overhead associated with this, I could see this being a valid approach. I would request that, if implemented, this be placed behind an on/off switch. The makefile could also handle this with something along these lines (correct the leading space - tab conversion as well as proper macro definitions): tangleflag: totangle.org $(TANGLECOMMAND) totangle.org $(TOUCH) tangleflag syncflag: tangleflag $(SYNCCOMMAND) sourcedir tangledir $(TOUCH) syncflag --Brian
Re: [O] Not overwriting unchanged source code files when tangling
On Fri, Nov 18, 2011 at 11:02 AM, Carsten Dominik carsten.domi...@gmail.com wrote: How about changing the make file so that the dependence is on the Org file, not on the source file? You could then arrange for make to call emacs in batch-mode to tangle the source file and then compile it? The original question was trying to avoid recompiling everything generated from a tangle if the content didn't actually change. Because retangling the source rewrites /all/ of the files, and resets the dates, even if nothing has changed, make will then rebuild everything that was tangled, not just the partial set of tangled files that actually changed. Brian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte schulte.e...@gmail.com wrote: This is also after all the development repository, and while I do try very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality. Given that a common recommendation for a bug fix is to 'try commit blah blah blah', would it make sense to have bug fixes go onto a 'maint' branch (as well as master), and new features / changed features stay on the master branch? At the time when 'master' is ready for a new official release, it could then be merged into 'maint' to create the next stable point for bug fixes. Adding features on the same branch as bug fixes, when 'official releases' are not made frequently seems to be a formula for frustration. Thoughts? Brian
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
On Mon, Oct 24, 2011 at 7:12 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: For my information, why do you need to test that 2 suites don't run at the same time? They only write to temp buffers, no? Can they conflict? If they do conflict and only one set of tests should run at a time, shouldn't the second set of tests be queued up so it runs when the first is complete? If this isn't done, I could see a situation where at least one commit remains untested until the next commit. my $0.02; Brian
[O] Fwd: [test] Mark tests with missing dependencies as expected to fail
Neglected forwarding to the list - sorry Eric for the double post. Brian -- Forwarded message -- From: Brian Wightman midlife...@wightmanfam.org Date: Tue, Oct 18, 2011 at 12:02 PM Subject: Re: [O] [test] Mark tests with missing dependencies as expected to fail To: Eric Schulte schulte.e...@gmail.com On Tue, Oct 18, 2011 at 11:22 AM, Eric Schulte schulte.e...@gmail.com wrote: I agree it would be preferable to note that not all tests are run when dependencies are missing, although I don't think it is extremely important. I think some version of the above would be worthwhile if it could be done in a file-wide manner (as are the current dependency checks) and wouldn't require duplicating the dependency check or changing every test form individually. Perhaps a file-local-variable could be used to expect failures for every form defined in the file? Perl's TAP* (http://testanything.org/) uses SKIP results for tests that should not be run because some prerequisite is not available, and TODO tests for those that are expected to fail (due to not being implemented, known breakage, etc). They can be reported separately if the harness wishes. It sounds like this is what is being proposed. Perhaps some prior art could be used. * I reference TAP because it is what I am familiar with, not because it is better or worse than alternatives. Brian
Re: [O] Recurring events with exceptions
(and (your-sexp-here) (not (except-dates-here))) On Tue, Oct 18, 2011 at 11:52 AM, Karl Voit devn...@karl-voit.at wrote: Hi! I am into a process to write a convert tool from my old calendar software[1] to Org-mode. Now I do have to define something like »this event is recurring each week on Wednesday except 2011-10-26 and 2011-11-30«. I already know that complex things have to be done using sexp entries[2] but this does not seem to be possible with sexp either. Before I do have to develop a method that generates multiple distinct events for each recurring definition: is there another way to achieve this? Thanks! 1. jPilot/DateBK6/PalmOS 2. http://www.gnu.org/software/emacs/manual/html_node/emacs/Sexp-Diary-Entries.html -- Karl Voit
Re: [O] How can I review a day?
Never mind - lack of coffee. - Original Message From: MidLifeXis at PerlMonks midlife...@wightmanfam.org To: Robert Inder rob...@interactive.co.uk Cc: emacs-orgmode@gnu.org Sent: Tue, April 19, 2011 10:40:18 AM Subject: Re: [O] How can I review a day? #+BEGIN: clocktable :block today :scope agenda :maxlevel 4 :link 2 #+END: clocktable You can also use agenda-with-archives for the scope if needed. - Original Message From: Robert Inder rob...@interactive.co.uk To: Puneeth Chaganti puncha...@gmail.com Cc: emacs-orgmode@gnu.org Sent: Tue, April 19, 2011 10:06:12 AM Subject: Re: [O] How can I review a day? On 19 April 2011 14:59, Puneeth Chaganti puncha...@gmail.com wrote: So I'd like a way to review the time-line for a day: a way to see all the clock-in/clock-out pairs in order, so I can see any gaps or overlaps. Hit l in agenda mode to enable the log mode. Is this what you need? Whoa! Close, but not touching. I nearly mis-read/understood you. I initially thought you just meant ^C-a-L -- Timeline for current buffer. Which doesn't show any clock-related information. But I realise you actually meant that after I've done that, I should type l to get Log mode, it DOES show clock-related information. That's a really neat feature, and it's very close to what I want. But not quite right. It shows me the sequence of activities I logged time to, and how much time I logged. But it doesn't show me WHAT time I logged I want to check that (after I have manually edited one or more CLOCK lines) I haven't missed some time or double-logged any. And I can't see how to get that information. Robert. -- Robert Inder,0131 229 1052 / 07808 492 213 Interactive Information Ltd, 3, Lauriston Gardens, Edinburgh EH3 9HH Registered in Scotland, Company no. SC 150689 Interactions speak louder than words
