emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Bugs and suggestions for Org 4.70


From: Bastien
Subject: [Orgmode] Re: Bugs and suggestions for Org 4.70
Date: Fri, 13 Apr 2007 14:10:59 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.0 (gnu/linux)

Hi,

Carsten Dominik <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]