emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* Bugs and suggestions for Org 4.70
@ 2007-04-11 20:10 Bastien
  2007-04-13  8:41 ` Carsten Dominik
  0 siblings, 1 reply; 8+ messages in thread
From: Bastien @ 2007-04-11 20:10 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: Bugs and suggestions for Org 4.70
    2007-04-11 20:10 Bugs and suggestions for Org 4.70 Bastien
  @ 2007-04-13  8:41 ` Carsten Dominik
    2007-04-13 10:41   ` Giovanni Ridolfi
    2007-04-13 12:10   ` Bastien
    0 siblings, 2 replies; 8+ messages in thread
  From: Carsten Dominik @ 2007-04-13  8:41 UTC (permalink / raw)
    To: Bastien; +Cc: emacs-orgmode
  
  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
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: Re: Bugs and suggestions for Org 4.70
      2007-04-13  8:41 ` Carsten Dominik
    @ 2007-04-13 10:41   ` Giovanni Ridolfi
      2007-04-13 12:10   ` Bastien
      1 sibling, 0 replies; 8+ messages in thread
    From: Giovanni Ridolfi @ 2007-04-13 10:41 UTC (permalink / raw)
      To: emacs-orgmode
    
    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
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

  • * Re: Bugs and suggestions for Org 4.70
      2007-04-13  8:41 ` Carsten Dominik
      2007-04-13 10:41   ` Giovanni Ridolfi
    @ 2007-04-13 12:10   ` Bastien
      2007-04-13 12:38     ` Carsten Dominik
      2007-04-18  6:55     ` Carsten Dominik
      1 sibling, 2 replies; 8+ messages in thread
    From: Bastien @ 2007-04-13 12:10 UTC (permalink / raw)
      To: emacs-orgmode
    
    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
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

  • • * Re: Re: Bugs and suggestions for Org 4.70
        2007-04-13 12:10   ` Bastien
      @ 2007-04-13 12:38     ` Carsten Dominik
        2007-04-13 13:11       ` Bastien
        2007-04-18  6:55     ` Carsten Dominik
        1 sibling, 1 reply; 8+ messages in thread
      From: Carsten Dominik @ 2007-04-13 12:38 UTC (permalink / raw)
        To: Bastien; +Cc: emacs-orgmode
      
      
      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
      
      ^ permalink raw reply	[flat|nested] 8+ messages in thread

    • • * Re: Re: Bugs and suggestions for Org 4.70
          2007-04-13 12:38     ` Carsten Dominik
        @ 2007-04-13 13:11       ` Bastien
          0 siblings, 0 replies; 8+ messages in thread
        From: Bastien @ 2007-04-13 13:11 UTC (permalink / raw)
          To: emacs-orgmode
        
        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
        
        ^ permalink raw reply	[flat|nested] 8+ messages in thread

    • * Re: Re: Bugs and suggestions for Org 4.70
        2007-04-13 12:10   ` Bastien
        2007-04-13 12:38     ` Carsten Dominik
      @ 2007-04-18  6:55     ` Carsten Dominik
        2007-04-18  9:17       ` Bastien
        1 sibling, 1 reply; 8+ messages in thread
      From: Carsten Dominik @ 2007-04-18  6:55 UTC (permalink / raw)
        To: Bastien; +Cc: emacs-orgmode
      
      
      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
      
      ^ permalink raw reply	[flat|nested] 8+ messages in thread

    • • * Re: Re: Bugs and suggestions for Org 4.70
          2007-04-18  6:55     ` Carsten Dominik
        @ 2007-04-18  9:17       ` Bastien
          0 siblings, 0 replies; 8+ messages in thread
        From: Bastien @ 2007-04-18  9:17 UTC (permalink / raw)
          To: Carsten Dominik; +Cc: emacs-orgmode
        
        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
        
        ^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-04-18  9:22 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-11 20:10 Bugs and suggestions for Org 4.70 Bastien
2007-04-13  8:41 ` Carsten Dominik
2007-04-13 10:41   ` Giovanni Ridolfi
2007-04-13 12:10   ` Bastien
2007-04-13 12:38     ` Carsten Dominik
2007-04-13 13:11       ` Bastien
2007-04-18  6:55     ` Carsten Dominik
2007-04-18  9:17       ` Bastien

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).