From: Bastien <bzg@altern.org>
To: emacs-orgmode@gnu.org
Subject: Re: Bugs and suggestions for Org 4.70
Date: Fri, 13 Apr 2007 14:10:59 +0200 [thread overview]
Message-ID: <871wio1nl8.fsf@bzg.ath.cx> (raw)
In-Reply-To: <dc6c00c39bc3ab4415ad828b5180578b@science.uva.nl> (Carsten Dominik's message of "Fri\, 13 Apr 2007 10\:41\:30 +0200")
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
next prev parent reply other threads:[~2007-04-13 12:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871wio1nl8.fsf@bzg.ath.cx \
--to=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).