Bugs and suggestions for Org 4.70

Bugs and suggestions for Org 4.70

[Bastien]

Hi Carsten and all,

here is a bug report for Org 4.70 + cvs GNU Emacs (23.0.0.1), followed by a
couple of suggestions.

Bugs :

- Comment syntax: M-; still complains that no comment syntax is defined.

- *Bold* words at the beginning of lines are considered headlines when
   folding/unfolding.

- 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 :

  - « Topicalisation et focalisation dans les phrases françaises en SI »,
    Focus and Background in Romance Languages, Vienne, 23-27 Septembre
    2007.  (abstract joint)
    ^^^^

  ... here "2007" will start a new ordered-list item. 

- Org-mode can't use brackets within a link's label.

  For example: [[http://www.org-fever.org][[org fever]]] - the last "]"
  following "fever" won't be part of the link.  I confess brackets inside
  labels are somewhat exotic and might acutally be confusing, but.. well.

Suggestions :

- 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: ?

- TODO keywords could be stripped out from the iCal export - or at least
  this bit of information could be 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...

- Publishing a narrowed buffer should re-order levels of headlines.  For
  example, if the buffer is narrowed to a third-level headline, then this
  headline should be considered as a first-level headline when exporting
  (and the fourth as a second-level headline, and so on...)

- 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.

  For example, here in France : (current-time-zone) is (7200 "CEST"), which
  means GMT+2 -- not GMT.  I've found there is timezone.el out there, maybe
  a good resource ?

- 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] ...

  ... but maybe the C-c C-c is already *very* busy !

- 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 ?

Here it is.  Sorry for the length ... i'm afraid this is a side-effect of
org-mode itself ;)

Best regards,

-- 
Bastien

Re: Bugs and suggestions for Org 4.70

[Carsten Dominik]

Hi Bastien,

On Apr 11, 2007, at 22:10, Bastien wrote:

> Bugs :
>
> - 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.  It has to do with the problem brouoght back up
yesterday by Leo, that after

    #+TITLE: foo

some lines are considered comments if I set the comment
syntax to "#".  If did stare at the lisp code of
newcomment.el and of `do-auto-fill' for several hours.
If anyone can figure out what the problem is in this case,
please!

> - *Bold* words at the beginning of lines are considered
>   headlines when folding/unfolding.

Yes, this is a known problem, unlikely to be fixed soon,
because of the obvious conflict with the outline regular
expression.  This could be ficed by including " " into
the regexp, but I don't dare to do this because of possible
side effects on many org-mode functions.

Best work-around is to use a different character for marking
bold text, configurable in `org-emphasis-alist'.

>
> - 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.

> - Org-mode can't use brackets within a link's label.

Another issue that is hard to fix.  I believe that emacs-wiki
fixes it by escaping the bracket, and then overlaying a
display property with the correct label.  However, this is at
the expense of direct editability (is that an english word????)
of the label.

I'll take a note, maybe this can be fixed.

> Suggestions :
>
> - 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: ?
>
> - 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.

>
> - 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.

> - Publishing a narrowed buffer should re-order levels of
>   headlines.   For example, if the buffer is narrowed
>   to a third-level headline, then this headline should
>   be considered as a first-level headline when exporting
>   (and the fourth as a second-level headline, and so on...)

>
> - 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?
>
> - 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?

>
>   ... but maybe the C-c C-c is already *very* busy !

It certainly is.  Does that actually bother anyone?
I quite like it.

>
> - 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.
The agenda now has all but replaced it, but I am keeping
it for backward compatibility, and for an easy way to
restrict to a single project or file.

- Carsten



--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: Re: Bugs and suggestions for Org 4.70

[Giovanni Ridolfi]

On Fri, Apr 13, 2007 at 10:41:30AM +0200, Carsten Dominik wrote:
> On Apr 11, 2007, at 22:10, Bastien wrote:
> 
> >- *Bold* words at the beginning of lines are considered
> >  headlines when folding/unfolding.
> 
> Yes, this is a known problem, unlikely to be fixed soon,
> because of the obvious conflict with the outline regular
> expression.  This could be ficed by including " " into
> the regexp, but I don't dare to do this because of possible
> side effects on many org-mode functions.
> 
> Best work-around is to use a different character for marking
> bold text, configurable in `org-emphasis-alist'.
> 

Well, if the line begins with a space such as:

 *bold*
^
the word 'bold' is bold and it is no longer a headline....
at least here:
 WinXP
 GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) of 2007-03-08 on
    LENNART-69DE564 (patched)
 Org-mode version 4.67c

Cheers,
Giovanni

Re: Bugs and suggestions for Org 4.70

[Bastien]

Hi,

Carsten Dominik <dominik@science.uva.nl> 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

Re: Re: Bugs and suggestions for Org 4.70

[Carsten Dominik]

On Apr 13, 2007, at 14:10, Bastien wrote:
>
>>> - 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.

Well, in this case it is even impossible.  How could
you distinguish the two?  I guess the only way would be to require an 
empty line before a new list item, but that is not acceptable.


>
>>> - 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.

Yes, interesting idea, implementation not very fast I am afraid, too 
many other things on my plate right now.

Thanks for all the great ideas, when I find time I will implement
what I think fits in.

- Carsten

Re: Re: Bugs and suggestions for Org 4.70

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

>> 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.
>
> Well, in this case it is even impossible.  How could
> you distinguish the two?  I guess the only way would be to require an empty
> line before a new list item, but that is not acceptable.

The approach i tried to implement was to delimit list environments before
matching list items.  

For example "[\t ]*\([0-9]+\|[-+o]\) " would match a list item and this
item will start a new list environment.  Depending on (match-string 1),
this list environment would be ordered, unordered, etc.  

Then the parser would try to find the end of the list environment before
doing any conversion.  The end of a list environment is often a new line
starting with something else than tabs/whitespaces (this definition my not
be sufficient, of course).

Finally, within the list environment (a region), the parser would process
each list item of a certain type, ignoring number in unordered lists and
dashes in ordered lists ...  but enough with speculations, i just wanted 
to sketch the idea.

> Yes, interesting idea, implementation not very fast I am afraid, too many
> other things on my plate right now.

Thanks very much -- i think everyone agrees it's already difficult to
follow the amazing pace of Org development !

-- 
Bastien

Re: Re: Bugs and suggestions for Org 4.70

[Carsten Dominik]

On Apr 13, 2007, at 14:10, Bastien wrote:

>
>>> - 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)

Since there is always only one project that is being clocked,
this seems a little overkill to me.  Maybe a command to jump
to the item being clocked would be more useful.

- Carsten

Re: Re: Bugs and suggestions for Org 4.70

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Apr 13, 2007, at 14:10, Bastien wrote:
>
>> "%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)
>
> Since there is always only one project that is being clocked, this seems
> a little overkill to me.  Maybe a command to jump to the item being
> clocked would be more useful.

Right.  But there could be some way to define was is considered the project
you're clocked in.  I guess the headline is not always the information we
want -- we might want the file name, the above headline, etc.

-- 
Bastien