From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Bugs and suggestions for Org 4.70 Date: Fri, 13 Apr 2007 14:10:59 +0200 Message-ID: <871wio1nl8.fsf@bzg.ath.cx> References: <87k5willk1.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HcKgd-0002kW-Rn for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 08:15:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HcKgb-0002kK-So for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 08:15:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HcKgb-0002kH-PO for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 08:15:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HcKcK-0006Zm-E8 for emacs-orgmode@gnu.org; Fri, 13 Apr 2007 08:11:04 -0400 Received: by ug-out-1314.google.com with SMTP id j3so526336ugf for ; Fri, 13 Apr 2007 05:11:03 -0700 (PDT) In-Reply-To: (Carsten Dominik's message of "Fri\, 13 Apr 2007 10\:41\:30 +0200") 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: emacs-orgmode@gnu.org Hi, Carsten Dominik writes: >> - Comment syntax: M-; still complains that no comment syntax is defined. > > I would like to change this but I have given up to understand > this issue. Ok, i understand this. >> - *Bold* words at the beginning of lines are considered >> headlines when folding/unfolding. > > Yes, this is a known problem, unlikely to be fixed soon, It does not happen very often anyway, and the workaround is very easy, no worry. >> - If a list item contains a number that find itself at the beginning of >> a line (within this list item), this number will be considered as a >> start for another ordered-list item when exporting. For example : > > Yes, this is a problem. Again, I would not know how to fix it. Mmhh. It may require a full rewriting of the lists parsing funcs; i didn't check your code for that, but having spent a good amount of time trying to implement something like this for my old bhl-mode, I know list parsing is always challenging. >> - I often attach a location to scheduled/deadlined events. Why not >> using LOCATION in addition to SCHEDULED or DEADLINE ? This would also >> end up in a new "LOCATION:" entry in the .ics export. Maybe default >> locations could be defined in some #+LOCATIONS: ? What about this suggestion ? I dare say this might turn out to be the most useful suggestion i've made so far. As far as i know, having a structured way to store locations for scheduled tasks or events is quite common in other organizers and text-based organizers like Org could again prove themselves very flexible when dealing with this. For example, we might have several defaults locations, or put links to a Google map URL, or even prioritize/sort the events depending on distance between their locations, etc. >> - TODO keywords could be stripped out from the iCal export - or at least >> this bit of information could be optional ? > > This would look better in the ics export for sure, but if people are > using more than one TODO state, it looses information. Yes. I'm using several TODO states, but i don't feel the need to keep them in the .ics output. I guess others would like to keep this piece of info, that's why i was suggesting to make this optional. >> - It would be nice if we had some feedback in the modeline telling us >> what project / headline is currently clocked in -- suggestion stolen >> from the planner mailing list... > > I like this idea. However, it would probably take up a lot of space in > the mode line..... What do you suggest as the content of the label? I > guess the elapsed time since the clock was started, and some info about > the item. Yes. Since headlines styles heavily depends on users' habits, why not use a new format (like `org-email-link-description-format') ? org-clocked-in-task-modeline-format examples : "%e - %.15h" : shows elapsed time and the first 15 characters of the headline (excluding TODO/tags keywords) "%e - [%s%d] %t %p %h %T" : shows elapsed time, scheduled/dealine state, TODO keyword, priority, full headline and tags. "%c (%e)" : only shows parent category elapsed time Formatting options : %e elapsed time %f file %c category %t todo state %p priority %h headline field %T tags %s scheduled (default: "S" for scheduled) %d deadline (default: "D" for deadline) ... >> - Taking (cadr (current-time-zone)) as the exported timezone in .ics >> format is not always accurate since the car of (current-time-zone) is >> relevant to the definition of the local timezone. > > Hmmm. What exactly does the ics format want there? Right now it would > be CEST, is that not understood by calendar programs? What would they > need? It seems that the current Org information (X-WR-TIMEZONE: CEST) is okay for most programs, but sometimes a VTIMEZONE component might be required. For example, it looks like that VTIMEZONE is required when you insert a Google calendar in another page - weird (and not fully tested yet.) Here is a sample VTIMEZONE component : BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE The trouble is that "Europe/Paris" has to be set by hand somewhere, since (current-time-zone) is the same for a lot of european locations. >> - Instead of telling us that this is not an ordered list, C-c C-c on >> unordered list items could cycle through these states : >> >> - ... >> - [ ] ... >> - [X] ... > > I guess it would not cycle, but switch from nothing to [ ] and after that > just toggle between the states. I don't think it should make [X] > disappear entirely. Do you agree? Yes. >> ... but maybe the C-c C-c is already *very* busy ! > > It certainly is. Does that actually bother anyone? I quite like it. I like it as well! It's a very busy Emacs key in general anyway. >> - Org-timeline might be aware of several files? -- the default files >> being org-agenda-files. But maybe combination of org-agenda / >> org-agenda-ndays is enough? > > I would think so. The timeline is really a leftover, because it was the > first agenda-like view I implemented. Ok, then i understand better. Thanks for your answers, i'm back to lurking again :) -- Bastien