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