Re: [Orgmode] 4.70 org-goto bug
I've discovered that this problem was only occuring at work, and not at home. I think my site installation of emacs 22 was messed up, perhaps colliding with emacs21. And possibly confusing the org-mode install. In truth I have no idea, but a clean reinstall seems to have things working normally. For now anyway... :) R. Carsten Dominik wrote: I cannot reproduce that bug. Anyone? - Carsten On Apr 9, 2007, at 12:13, Rick Moynihan wrote: Hi, I've been playing with org-mode 4.70 and I'm really liking the multiple TODO sequences. However, I seem to have encountered a bug with org-goto. When navigating between headings of the same level with "f" and "b", if I try and move too far (i.e. I'm at either the first or last level of indentation and I push f/b respectively) I get the error: error "before first heading". Then ALL of my emacs keybindings fail, I can't seem to switch buffers or even kill the debug buffer. Strangely sometimes I can't seem to generate the error, so it doesn't seem to happen EVERY time, though restarting Emacs and navigating straight to an org-mode buffer through the agenda and instantly trying to cause the bug through running C-c C-j and then generating the error through the process described above seems to cause it every time. Could there be something funny in my config? R. ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode -- Carsten Dominik Sterrenkundig Instituut "Anton Pannekoek" Universiteit van Amsterdam Kruislaan 403 NL-1098SJ Amsterdam phone: +31 20 525 7477 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Bugs and suggestions for Org 4.70
Carsten Dominik <[EMAIL PROTECTED]> 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 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Bugs and suggestions for Org 4.70
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 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bugs and suggestions for Org 4.70
Hi, Carsten Dominik <[EMAIL PROTECTED]> 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:19700329T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T03 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
Re: [Orgmode] Re: Bugs and suggestions for Org 4.70
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 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Empty lines in subtrees (was: [bug] misbehavior of org-shiftmetaup)
- Me (2007-04-12) wrote:- > Dear Carsten, > > I think this bug has been there for quite some time as it is also in > 4.67c. > > To reproduce: >o Open the attached file and set it in org-mode >o Go to "* Heading 1" and issue 'C-x n s' >o Move cursor to subtree: "** Item 2" >o M-x org-shiftmetaup [...] This bug is now fixed in org 4.71. However, it will now add an empty line to the subtree, and then bring all empty lines along when org-shiftmetaup. So after shuffling a few times, users can be left with: , | * Heading 1 | ** Item 1 |Read this book. | ** Item 2 |Go to supermarket and get a printer | | | | | * Heading 2 ` I guess this is because: When narrowing to subtree, the "newline" at the end of the last subtree is left out and thus org-shiftmetaup introduce another one. Regards, -- Leo (GPG Key: 9283AA3F) ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Adding latex packages
On Apr 3, 2007, at 18:00, Matthieu Lemerre wrote: Hello, I wondered if it was possible to include custom Latex packages when processing embedded LaTeX fragments in org. In 4.71, the entire header will be contained in the option `org-format-latex-header'. This should be global or per-file options. The point is that there are plenty of good LaTeX environments that it would be useful to have in org (for instance algorithm or tikz). One of these environments is tikzpicture, and using tikzpicture in org would allow to create high-quality graphics in org documents. There is one remaining difficulty though; tikz pictures aren't extracted with dvipng. I guess this last issue you have to take up with the dvipng maintainers. What do you think? Good idea, thanks! - Carsten -- Carsten Dominik Sterrenkundig Instituut "Anton Pannekoek" Universiteit van Amsterdam Kruislaan 403 NL-1098SJ Amsterdam phone: +31 20 525 7477 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Org-mode 4.71
Hi I have released org-mode version 4.71 at http://www.astro.uva.nl/~dominik/Tools/org This has only small changes and some bug fixes. Enjoy! - Carsten Changes in Version 4.71 --- - New variables to customize the header and data tags in exported HTML:`org-export-table-header-tags' and `org-export-table-data-tags'. This follows a request from Scott Otterson. - New option `org-format-latex-header' for customizing the header of the LaTeX file used to convert embedded LaTeX to images. Thanks to `Matthieu Lemerre' for the suggestion. - The prefix version of `org-todo-list' works again. This means that `C-1 C-c a t' produces the list of TODO entries for the first TODO keyword. If you use different TODO setups in different agenda files, be careful: This number now refers to the list of *all* todo keywords used in files that are scanned for the agenda. - Many bug fixes. ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bugs and suggestions for Org 4.70
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 ___ Emacs-orgmode mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-orgmode
