* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.