From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Elston Subject: Re: Automatic Update of Org files Date: Fri, 06 Feb 2009 10:54:05 -0800 Message-ID: <498C874D.30103@advantest-ard.com> References: <498B623A.4080000@advantest-ard.com> <20524da70902051440qd49dd48p7a5da8ff2a22670f@mail.gmail.com> <498B72A1.8060701@advantest-ard.com> Reply-To: m.elston@advantest-ard.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVVq6-0000KV-4N for emacs-orgmode@gnu.org; Fri, 06 Feb 2009 13:54:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVVq5-0000Jt-5V for emacs-orgmode@gnu.org; Fri, 06 Feb 2009 13:54:09 -0500 Received: from [199.232.76.173] (port=39984 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVVq4-0000Jn-Vw for emacs-orgmode@gnu.org; Fri, 06 Feb 2009 13:54:09 -0500 Received: from [192.84.20.196] (port=1329 helo=mailhub.ardeng.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVVq4-0003NO-Bl for emacs-orgmode@gnu.org; Fri, 06 Feb 2009 13:54:08 -0500 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Thole Cc: Org Mode List David, This sound interesting and similar to what I am doing. I didn't want to have to parse the Org file but it may be that I have no choice in the matter. I may be able to make some of this easier on myself by putting all (or most) generated information in a block of some kind that allows me to keep it as text without having to really 'parse' it. This would make the 'merge' process simpler. As for your wishlist items I am not so concerned with the 'postback' as I am not just looking at my own issues but those in my group as well. I won't mark something as done until it has been completed in TestTrack. My biggest concern is keeping any notes I add to items I have extracted from these various sources during an update process. I tried the org-registry package mentioned by Samuel but it didn't load and initialize. I am not sure but I think it may be due to the fact that my 'org-agenda-files' variable is set to a directory and not a list of files. You say you are using Python. I have used Perl since I found a SOAP package for Perl and I haven't seen one for Python and I need it for accessing TestTrack. I would prefer Python otherwise. I would be interested in seeing what you have. It may give me some ideas. Mark * David Thole wrote (on 2/6/2009 7:19 AM): > Something I've been working on and am continuing to work on is kinda a > middleware script like what you're doing. It's in python now - and have > a few who contacted me personally who are interested in this once I get > the refactor complete. > > Basically what I've done is try to merge stuff in from our Redmine > system here (Redmine is another ticket tracking system). The workflow I > came up with, at least for the script is: > > 1. Query redmine, get all my assigned issues. > 2. Open the org file, read and parse through everything in there > (currently it goes for the dates that I have for scheduled, and I want > to eventually get it so that all the notes as well as time logging will > be captured too. > 3. Merge the two sources together (I use two hashed arrays, basically > it's something like array[ISSUEID] = array, where the second array > contain inforamtion such as the title, project, due date, date > scheduled, etc). I use rules such as that the deadlines are determined > in the Redmine system, so that takes priority over my due date - but the > date scheduled would be captured, and the state (TODO/DONE/ETC). The > status is determined, currently, within Redmine - I haven't figured out > a good way yet on dealing with that yet. > > Kinda on my wishlist: > > 1. A "postback" to Redmine, say I update the status to complete, I > wouldn't mind if there was a good way to push that information to > redmine, using my comments in my ticket to add perhaps - or maybe > allowing for a certain type of tag. > 2. To handle notes, the checked sub-items that can occur, etc. > > It's still a work in progress, but part of my work is to try and allow a > more pluggable system so that other ticket management systems can be > represented. > > Still working on the refactoring..let me know if this interests you at all. > > -David > > On Thu, Feb 5, 2009 at 5:13 PM, Mark Elston > wrote: > > Samuel, > > Thanks for the info. I will have to digest this and see if it > fits. > > One concern I have with this approach (and I may not have fully > grasped what you intended) is that the original source files have > the current information like deadlines, etc that I want used > when creating my agenda for the week. If I want more information > about the agenda item I will navigate to it and hit which > takes me to the generated Org file. Once there, I would like to > be able to add notes as necessary. > > Alternatively, I suppose I could navigate to the notes if there is > a simple mechanism for this. I don't really understand all you > described below but I will try playing with it and see what comes > out. > > Mark > > * Samuel Wales wrote (on 2/5/2009 2:40 PM): > > IIUC, source is not under your complete control. You need it > orgified > but also annotated. There are various annotation mechanisms. My > comments on the remember redesign might be relevant. > > You could consider going backward. Have your org file contain links > to the read-only stuff. Put entry IDs in the read-only stuff. > > Dunno if this helps. > > Here is something I had lying around: > > Another feature is to have org-registry show on the mode > line when a link points to the current buffer's object (w3m > page, file, dired, etc.). You click on it to go to the org > file link. See my remember suggestions in a previous thred > for more re annotations, bookmarks, and registry. > > I proposed this before: > > === snip > > Extension #2 to the bookmark idea. > > My idea is to always have annotations available for > emacs-w3m, dired, files, like org-annotate-file, just with > more modes. > > You can see in the mode line that whatever buffer you are in > has an annotation, and you can make an annotation. You can > also go to the annotation. > > The annotations are stored in an org file anywhere in the > hierarchy. Thus, if you want, annotations on a doctor's web > site can be stored in the entry for that doctor that is in > your org file. If you visit that web site from any source, > even Google, the mode line says that it is annotated. Then > you can pull up that entry with a command. > > Likewise with files or dired or whatever. For example, you > can comment org.el or /etc/passwd without having to modify > them. > > Remember code seems a plausible place to arrange for > choosing a location and putting a note into it. Annotations > are like bookmarks with text that also go the other > direction. It's natural to combine the idea of a bookmark > and the idea of an annotation. > > You might want the mode line to say "there is bookmark to > this (web page, file, etc.)" as one character and "there is > a text note about this" as another character. Thus, if you > have annotated a file and the file is unmodified, you will > see "-u:--!!" and if you have merely bookmarked the location > without commenting on it, then you will see "-u:--!-". > === snip > > > > > _______________________________________________ > 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 > >