[Orgmode] Re: DocBook exporter for Org-mode
Gour g...@mail.inet.hr writes: Sebastian == Sebastian Rose sebastian_r...@gmx.de writes: Sebastian I highly apreciate the support of Docbook and your Sebastian effort. Yet, I think I don't want to publish XHTML through Sebastian Docbook. +1 I gave up on DocBook long ago. It's pain to author documents in it and the tools are quite weak. Actually nXML mode has made editing DocBook and other XML files a fun process. At least less painful than editing LaTeX files to many people. It is true that many open-source tools around DocBook are still not perfect, but they should be good enough for most of the work of most users. Some commercial tools exist and are better, but they are not free. (I have not used reST, however it does not seem to me that it has more tools than DocBook.) That why I don't like AsciiDoc as well being based on Docbook tool-chain and therefore decided to use reST markup which is much lighter, nicely supported and it can export to many formats (e.g. xhtml, odt, pdf..) I just checked reST markup specifications, and they do look powerful (but not very lightweight). Maybe it *is* time to have a standard to unify all these plain-text based lightweight markup languages: Muse, Org, reST, asciidoc, all kinds of *wiki*, doxygen styles, etc. These languages won't be lightweight and easy to read once they become more powerful. At that point, I'd prefer to go back to LaTeX or DocBook. Therefore I'm interested about any hint how could reST be used with org-mode? That may require some code sharing/merging between rst.el and Org-mode, I guess. :-) Baoqiu ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Tag matches are now case-sensitive
Dear all I just pushed a change that makes tag searches from now on case- sensitive. Making them case-insensitive was difficult to reconcile with an effort to make the agenda faster, and something like Eric's org-collector *a lot* faster. I hope you have not relied on case-insensitivity of tag searches - please check you custom agenda commands if this is an issue. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Is column view buggy?
Hi, I don't know if it's just my setup, but I see many problems when using column view (C-c C-x C-c) on org6.23trans+Emacs23(Bazaar), specially with lots of properties in long lines (more than 1 visual line) or folded contents (where the ellipsis ... is visible). For instance: 1. The cursor isn't visible sometimes when it is over a header which has the ellipsis (...) at the end. 2. When I press the up/down arrows, the cursor goes to the upper/lower line, but 1 cell to the right. This happens just for the first up/down movement after a left/right one. 3. Sometimes the cursor is locked in a cell and I can't move it down with the down arrow key (however, up/left/right work). These problems seem difficult to debug, since I have many possible causes (color theme, changed colors, fonts, changed ellipsis, maybe wrong configuration, …). Should I report these problems in detail or are they already known? Thanks Daniel ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] done-ing a repeating scheduled task now inserts closed timestamp?
Nobody else has commented on this, so perhaps I am doing something wrong. My recollection is that [setting the todo state of a task with a repeating scheduled task to done] did not used to insert a closed timestamp, but now it seems to -- or at least it fails to remove the timestamp. Is this intentional? I use the closed timestamp to indicate that a task can be archived, but perhaps I should not rely on that? I find that most things in org behave in a way that works for me right away, which shows how much thinking goes into its design. However repeated tasks is one thing that has not quite worked for me yet. Repeating items and cyclic diary entries provide part of the functionality I need, but not quite. Basically, I would like repeated tasks and cyclic appointments to disappear from the past when they are done (so that they do not clutter the agenda) but to appear in the future (so that I can, e.g., schedule other appointments around them in the days they occur). Repeating tasks do not appear in the future or the past. Cyclic appointments are close. If I have: ** TODO Check backups 2009-03-05 Thu 11:00 +2d And pass from TODO to DONE this happens: ** TODO Check backups 2009-03-07 Sat 11:00 +2d CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] An then, with l this entry will appear in the agenda, but: - It appears as TODO (rather than DONE) and with the current date, (even though it also does say Closed:) all of which can be confusing. - Non-repeating tasks with a timestamp behave differently: if such a task is marked as done a CLOSED line is also generated (provided the right flags are on) but it does not actually disappear from the agenda (at least for me, even if the manual seems to imply otherwise), independently of the logging (l) state. I think a perhaps better behavior could be that the same line: ** TODO Check backups 2009-03-05 Thu 11:00 +2d is marked as done, then a) a *copy* is made of the TODO item, and that copy is the one that goes to DONE and gets the CLOSED (i.e., a normal task is generated and updated) and b) the repeating task is shifted (without attaching anything to it, since it is a fresh task): ** DONE Check backups 2009-03-05 Sat 11:00 CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] ** TODO Check backups 2009-03-07 Sat 11:00 +2d Apart from behaving more like a normal task this would have in my mind some additional advantages: I like DONE tasks to eventually disappear from my agenda. I do this by archiving them (to sibling). This allows me to easily see that I have not left anything behind in past days. I could now do this with the copied task, independently of the updated repeater. When I want to look at what I did on a certain day I hit the handy v key and the archived, done tasks appear again, including those that originated from the repeater --great! I.e., the repeater leaves behind a trail of normal tasks. Thoughts? Manuel -- --- Manuel Hermenegildo | Prof., C.S.Dept., T.U. Madrid (UPM) Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W) -352-4819 (Fax) --- ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug? setting todo keywords
Hello everybody I'm not able to change the todo keywords in a file with setq org-todo-keywords and restarting org-mode as described in the manual § 5.2.1 . Org-mode version 6.23b GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600) of 2009-02-01 on SOFT-MJASON M$Widows XP -file- -*- mode: org; -*- * TODO 1st head (setq org-todo-keywords '((sequence TODO FEEDBACK VERIFY | DONE DELEGATED))) # + SEQ_TODO: TODO FEEDBACK VERIFY DONE (setq org-todo-keywords '((type Fred Sara Lucy | DONE))) -- If I + go to ))) + C-x C-e + M-x normal-mode (to restart Org-mode) the * TODO sequence is still TODO DONE The sequence is changed (feedback, delegated...) - if I change it via the customization interface - if I use #+SEQ_TODO: and C-c C-c on it I'm puzzled! the sequence is changed with the type keyword (setq org-todo-keywords '((type ^ Is it a bug or do I miss something? cheers, Giovanni __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Article: Synchronizing org Files Using bzr and git
Hi Ian, nice work! On Mar 3, 2009, at 2:42 PM, Ian Barton wrote: I have been working on an article on syncing org files using a version control system for a while. The recent posts about using a usb stick motivated me to try and finish it. You can see the html version at http://www.ian-barton.com/ian-barton/org_vcs/org_vcs.html and get the current version from github at git://github.com/ geekinthesticks/org-vcs.git . This is still a work in progress, but I would welcome any comments. Since it's available via github and I am lazy, please feel free to edit it yourself:) A couple of observations: I have tried to strike a balance between describing something that works and avoiding too many minutiae of VCS options. I am using bzr myself (although I might switch). I am aware that most people on the list use git, so I have tried to give both git and bzr examples. If the git ones are wrong, please let me know! If Carsten thinks it's suitable I would be happy for the article to end up on worg, or wherever he thinks appropriate. First of all, I do not control in any way what gets on Worg. Bastien set up Worg as user-edited content, and this is what it should be. If you aks my opinion, I think your tutorial is *exactly* what Worg was made for! I have not studied it in detail, but it looks useful, addresses a subject that has almost become a FAQ. And if it is up on Worg, bugs will be fixed and improvements made. So please feel free to add your tutorial to Worg. The best place would be the org-tutorial directory, and you should then make a link from the index.org in that same directory. After pushing, it will take 1.5 hours or less to appear on the web. Thanks! - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] outline-agenda sorting consistency
On Mar 3, 2009, at 5:09 AM, Samuel Wales wrote: Hi Carsten, On Thu, Feb 19, 2009 at 12:22, Carsten Dominik domi...@science.uva.nl wrote: 1) priority faces are settable in the agenda. perhaps they could be so in the outline also. This seems more confusing than useful to me. In the agenda, all the tasks are together, so it does make some sense to change fonts. In the outline, I would find it confusing. Are there any other opinions on this? I'll try to provide more detail for at least my case. I would not set the face for the whole headline, just the priority tag itself. I actually find the agenda faces, which often set the entire headline, to be confusing.[1] I would not propose to change the default. For me [#C] and [#A] look alike and it is hard to distinguish them based on the single letter. I basically stopped using C because I kept (mis)perceiving it as important. (I don't use B because it is the same as blank.) What I would do is set C to show in something like (but not the same as) the done todo kw face, and A to show in something like the todo face. This tells me to pay attention less and more, respectively. Others would semioticize (so to speak) differently. Hi Samuel, you can now et faces for each priority, using the variable org-priority-faces, in a way similar to the todo-keyword faces, and the tag faces. Just note that the car in this alist must be a character, not a string. 2) sorting strategy is settable in the agenda. perhaps it could be settable in the outline also. they could share code. To be honest, I never sort the outline, except in rare cases. I would be interested how people use this to get a better case for changing this. I would use it to keep high urgency and -priority tasks at the top and done tasks at the bottom. Also, I sometimes have a large list of disorganized tasks. The tasks need todo state specification, tagging, priority setting, refiling, turning into a plain list, etc.; and sorting seems the best way to focus the organizing. I can only do a little at a time, and can't predict when I can do it, so having it sorted allows me to immediately see gaps. Like this is too urgent to be among the non-urgent tasks. Then I can return to it later without having to refamiliarize myself with the whole list. I can more easily isolate the high priority and high urgency stuff that isn't done, then organize only that. After dealing with metadata, I can make the hierarchy deeper by ontology. Having it work like org-agenda-sorting-strategy would allow the same sorting in both places. Here is how I might do it, were the facility to exist: - done-ish and unimportant stuff at the bottom, important stuff at the top, and uncategorized nodes (i.e. blank todo state, no priority, no urgency) in the middle. - alphabetical order for nodes with the same weight - to calculate the weight of a node: 1) priority a is worth +1000 2) urgent tag gets +1000 3) now tag gets +500 4) todo-ish states (todo, next) get +100 5) /blank todo state/ gets 0 6) zombie states (wait etc.) get -100 7) someday tag gets -500 8) priority c gets -1000 9) done-ish states (done, moot) get -3000 - example: an urgent todo would have a weight of 1100. when it is marked done, it would have a weight of -2000. Outline sorting can be done using a user-defined function, so in principle this should be possible. It is on my list, but not with high priority This is especially useful for long confusing lists. One of the basic principles in Org is that in the notes files, tasks are in context. In the agenda, things are re-arranged and sorted. That is why there is a complex sorting strategy in the agenda, but not in the outline. The agenda is wonderful for other stuff, but for me it is not an editing mode per se. I have never been able to use the agenda for full control over the org file, as some people are able to do. For me (at least on my computer) it is slow. What is slow. Maybe we can improve things? Arbitrary editing is not possible. The keys that work are often different from the ones I use in the outline. If I define a key in the outline, I have to figure out how to define it in the agenda (haven't yet). (add-hook 'org-agenda-mode-hook (lambda () (define-key org-agenda-mode-map key 'command))) - Carsten I find manipulating windows to be cumbersome, especially since for accessibility reasons I have no option but to use very large fonts that make split windows show very few lines (I typically never split windows). I usually can't see all the tags in the agenda because there are not enough columns. I can't scroll the other window in follow mode. Extra keystrokes are required to organize things. I can't easily create an arbitrary outline view of all tasks under a node with it. I can't rearrange and sort as I would in the outline. So for me, while the agenda is indispensable, it is only for showing an
Re: [Orgmode] Article: Synchronizing org Files Using bzr and git
On Tue, Mar 03, 2009 at 01:42:56PM +, Ian Barton wrote: I have been working on an article on syncing org files using a version control system for a while. The recent posts about using a usb stick motivated me to try and finish it. You can see the html version at http://www.ian-barton.com/ian-barton/org_vcs/org_vcs.html and get the current version from github at git://github.com/geekinthesticks/org-vcs.git . Hi Ian, This tutorial was great. I've been using bzr for most of my text files (including org) for some time now, and I'm glad I'm not the only one! I picked up on a couple of things I hadn't thought of, so thanks! I just want to point out a ssmall typo. In Section 8.2.1 'Moving Your Data from bzr to git' you say... , | | Like most things this is easy once you know how. You need the bzr fast-export plugin. | ` I think you mean the 'fast import' plug-in. The rest of the paragraph makes this pretty clear, but I can see some poor newbie trying to figure this out! Well done, and I look forward to seeing any additions you might make. -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Hi Scott, thanks for the report. The handling of the title is one of the weak points of the script (another one being the text before first headline). The reason might be, that I was never sure what to do with it in info-view-mode, plain-view-mode, TOC hidden, TOC. In info-view-mode, the title is displayed on top as `Top: title', which is not what one might expect. Look at http://orgmode.org/worg/org-faq.php - there the title is always visible (fixed toc). Should we do it that way? As the docs say, the slides mode is very experimental... Regards, Sebastian sran...@uakron.edu writes: Hi again, Sorry for the multiple messages. I just noticed one other thing. When I go from slide mode to plain mode, the full table of contents will not be displayed unless I reload the page. Scott Randby ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Email: s.r...@emma-stil.de, sebastian_r...@gmx.de Http: www.emma-stil.de ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Sebastian Rose sebastian_r...@gmx.de writes: thanks for the report. The handling of the title is one of the weak points of the script (another one being the text before first headline). The reason might be, that I was never sure what to do with it in info-view-mode, plain-view-mode, TOC hidden, TOC. In info-view-mode, the title is displayed on top as `Top: title', which is not what one might expect. Look at http://orgmode.org/worg/org-faq.php - there the title is always visible (fixed toc). Should we do it that way? As I look at the code, I find that the title once was moved into the first section for info-view-mode. So now I'll fix it to behave that way again. I'll be back when done. Regards, -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] done-ing a repeating scheduled task now inserts closed timestamp?
On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote: Nobody else has commented on this, so perhaps I am doing something wrong. My recollection is that [setting the todo state of a task with a repeating scheduled task to done] did not used to insert a closed timestamp, but now it seems to -- or at least it fails to remove the timestamp. Is this intentional? I use the closed timestamp to indicate that a task can be archived, but perhaps I should not rely on that? I find that most things in org behave in a way that works for me right away, which shows how much thinking goes into its design. However repeated tasks is one thing that has not quite worked for me yet. Repeating items and cyclic diary entries provide part of the functionality I need, but not quite. Basically, I would like repeated tasks and cyclic appointments to disappear from the past when they are done (so that they do not clutter the agenda) but to appear in the future (so that I can, e.g., schedule other appointments around them in the days they occur). Repeating tasks do not appear in the future or the past. Cyclic appointments are close. If I have: They do appear in the future if you have org-agenda-repeating-timestamp-show-all set to t (which is also the default) ** TODO Check backups 2009-03-05 Thu 11:00 +2d And pass from TODO to DONE this happens: ** TODO Check backups 2009-03-07 Sat 11:00 +2d CLOSED: [2009-03-05 Tue 07:57] That CLOSED show up here is a bug, reported by Samuel Wales, fixed by now. - State DONE from TODO [2009-03-03 Tue 07:57] An then, with l this entry will appear in the agenda, but: Part of the bug that it shows up with l, it should not. No longer does, I think. - It appears as TODO (rather than DONE) and with the current date, (even though it also does say Closed:) all of which can be confusing. - Non-repeating tasks with a timestamp behave differently: if such a task is marked as done a CLOSED line is also generated (provided the right flags are on) but it does not actually disappear from the agenda (at least for me, even if the manual seems to imply otherwise), independently of the logging (l) state. You can make DONE scheduled tasks disappear by setting org-agenda-skip-scheduled-if-done Where does the manual state otherwise? I think a perhaps better behavior could be that the same line: ** TODO Check backups 2009-03-05 Thu 11:00 +2d is marked as done, then a) a *copy* is made of the TODO item, and that copy is the one that goes to DONE and gets the CLOSED (i.e., a normal task is generated and updated) and b) the repeating task is shifted (without attaching anything to it, since it is a fresh task): ** DONE Check backups 2009-03-05 Sat 11:00 CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] ** TODO Check backups 2009-03-07 Sat 11:00 +2d Apart from behaving more like a normal task this would have in my mind some additional advantages: I like DONE tasks to eventually disappear from my agenda. I do this by archiving them (to sibling). This allows me to easily see that I have not left anything behind in past days. I could now do this with the copied task, independently of the updated repeater. When I want to look at what I did on a certain day I hit the handy v key and the archived, done tasks appear again, including those that originated from the repeater --great! I.e., the repeater leaves behind a trail of normal tasks. This is an interesting, alternative proposal for repeating tasks. Anyone else would like to comment on this? - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] bug? setting todo keywords
Hi Giovanni, Giovanni Ridolfi giovanni.rido...@yahoo.it writes: Hello everybody I'm not able to change the todo keywords in a file with setq org-todo-keywords and restarting org-mode as described in the manual § 5.2.1 . Org-mode version 6.23b GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600) of 2009-02-01 on SOFT-MJASON M$Widows XP -file- -*- mode: org; -*- * TODO 1st head (setq org-todo-keywords '((sequence TODO FEEDBACK VERIFY | DONE DELEGATED))) # + SEQ_TODO: TODO FEEDBACK VERIFY DONE (setq org-todo-keywords '((type Fred Sara Lucy | DONE))) -- Is there a reason that you're putting all these lines in your org file? Normally, you would put #1 *or* #3 in your .emacs file and #2 at the top of your org file for in buffer settings. If I + go to ))) + C-x C-e + M-x normal-mode (to restart Org-mode) I think you need to use M-x org-mode-restart to restart org-mode with the new settings. - Matt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: done-ing a repeating scheduled task now inserts closed timestamp?
Manuel Hermenegildo he...@fi.upm.es writes: Repeating tasks do not appear in the future or the past. Cyclic appointments are close. If I have: ** TODO Check backups 2009-03-05 Thu 11:00 +2d And pass from TODO to DONE this happens: ** TODO Check backups 2009-03-07 Sat 11:00 +2d CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] An then, with l this entry will appear in the agenda, but: - It appears as TODO (rather than DONE) and with the current date, (even though it also does say Closed:) all of which can be confusing. - Non-repeating tasks with a timestamp behave differently: if such a task is marked as done a CLOSED line is also generated (provided the right flags are on) but it does not actually disappear from the agenda (at least for me, even if the manual seems to imply otherwise), independently of the logging (l) state. snip Thoughts? I think it will work better if you use SCHEDULED: dates like this: ** TODO Check backups SCHEDULED: 2009-03-05 Thu 11:00 +2d -Bernt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] done-ing a repeating scheduled task now inserts closed timestamp?
On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote: Nobody else has commented on this, so perhaps I am doing something wrong. My recollection is that [setting the todo state of a task with a repeating scheduled task to done] did not used to insert a closed timestamp, but now it seems to -- or at least it fails to remove the timestamp. Is this intentional? I use the closed timestamp to indicate that a task can be archived, but perhaps I should not rely on that? I find that most things in org behave in a way that works for me right away, which shows how much thinking goes into its design. However repeated tasks is one thing that has not quite worked for me yet. Repeating items and cyclic diary entries provide part of the functionality I need, but not quite. Basically, I would like repeated tasks and cyclic appointments to disappear from the past when they are done (so that they do not clutter the agenda) but to appear in the future (so that I can, e.g., schedule other appointments around them in the days they occur). Repeating tasks do not appear in the future or the past. Cyclic appointments are close. If I have: ** TODO Check backups 2009-03-05 Thu 11:00 +2d And pass from TODO to DONE this happens: ** TODO Check backups 2009-03-07 Sat 11:00 +2d CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] An then, with l this entry will appear in the agenda, but: - It appears as TODO (rather than DONE) and with the current date, (even though it also does say Closed:) all of which can be confusing. - Non-repeating tasks with a timestamp behave differently: if such a task is marked as done a CLOSED line is also generated (provided the right flags are on) but it does not actually disappear from the agenda (at least for me, even if the manual seems to imply otherwise), independently of the logging (l) state. I think a perhaps better behavior could be that the same line: ** TODO Check backups 2009-03-05 Thu 11:00 +2d is marked as done, then a) a *copy* is made of the TODO item, and that copy is the one that goes to DONE and gets the CLOSED (i.e., a normal task is generated and updated) and b) the repeating task is shifted (without attaching anything to it, since it is a fresh task): ** DONE Check backups 2009-03-05 Sat 11:00 CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] ** TODO Check backups 2009-03-07 Sat 11:00 +2d Apart from behaving more like a normal task this would have in my mind some additional advantages: I like DONE tasks to eventually disappear from my agenda. I do this by archiving them (to sibling). This allows me to easily see that I have not left anything behind in past days. I could now do this with the copied task, independently of the updated repeater. When I want to look at what I did on a certain day I hit the handy v key and the archived, done tasks appear again, including those that originated from the repeater --great! I.e., the repeater leaves behind a trail of normal tasks. Another idea to get this: Turn on state change notes or at least time stamps. Either globally, or locally for this entry with a LOGGING property: ** TODO Check backups SCHEDULED: 2009-03-05 Thu 11:00 +2d :PROPERTIES: :LOGGING: DONE(!) :END: (yes, scheduled, thanks Bernt...) Then each time you go through the DONE state, a time stamp will be recorded like this (I am assuming that you have org-log-into-drawer set...) ** TODO Check backups SCHEDULED: 2009-04-28 Tue 11:00 +2d :LOGBOOK: - State DONE from TODO [2009-03-04 Wed 14:25] - State DONE from TODO [2009-03-02 Mon 14:25] - State DONE from TODO [2009-02-28 Sat 14:25] - State DONE from TODO [2009-02-26 Thu 14:25] :END: :PROPERTIES: :LOGGING: DONE(!) In the agenda, if you press `C-u l', these state notes will become visible. I believe this will take care of it, right?? - Carsten Thoughts? Manuel -- --- Manuel Hermenegildo | Prof., C.S.Dept., T.U. Madrid (UPM) Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W) -352-4819 (Fax) --- ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Hi Scott, this is fixed now in v.0.1.0.4 As always, the script is available on repo_or_cz: http://repo.or.cz/w/Worg.git?a=blob_plain;f=code/org-info-js/org-info.js;hb=e11bc7fe538a513d899f4d006bf5f887f35dd8ce Regards, Sebastian Sebastian Rose sebastian_r...@gmx.de writes: Hi Scott, thanks for the report. The handling of the title is one of the weak points of the script (another one being the text before first headline). The reason might be, that I was never sure what to do with it in info-view-mode, plain-view-mode, TOC hidden, TOC. In info-view-mode, the title is displayed on top as `Top: title', which is not what one might expect. Look at http://orgmode.org/worg/org-faq.php - there the title is always visible (fixed toc). Should we do it that way? As the docs say, the slides mode is very experimental... Regards, Sebastian sran...@uakron.edu writes: Hi again, Sorry for the multiple messages. I just noticed one other thing. When I go from slide mode to plain mode, the full table of contents will not be displayed unless I reload the page. Scott Randby ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Email: s.r...@emma-stil.de, sebastian_r...@gmx.de Http: www.emma-stil.de ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: DocBook exporter for Org-mode
Hi Gour, Gour g...@mail.inet.hr writes: Sebastian == Sebastian Rose sebastian_r...@gmx.de writes: Sebastian I highly apreciate the support of Docbook and your Sebastian effort. Yet, I think I don't want to publish XHTML through Sebastian Docbook. +1 I gave up on DocBook long ago. It's pain to author documents in it and the tools are quite weak. That why I don't like AsciiDoc as well being based on Docbook tool-chain and therefore decided to use reST markup which is much lighter, nicely supported and it can export to many formats (e.g. xhtml, odt, pdf..) Therefore I'm interested about any hint how could reST be used with org-mode? Apart from odt output, I'd be curious to know what reST can do that org-mode markup and export cannot. Footnotes, tables, hyperlinks, images---I've found org-mode to be a really great authoring tool for exporting both to xhtml, ascii, and LaTeX/pdf output. (And, of course, using latex2rtf, it's trivial to convert the tex files org-mode produces into files that can be edited in Open Office.) (I'd use muse, but it's not so 'standard' as reST for non-Emacs users.) I wonder if the ascii export from org would be difficult to convert to reST markup. Section headers and footnotes in the ascii export seem pretty close to the corresponding markup in reST. Just a thought - Matt ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] bug? setting todo keywords
--- Mer 4/3/09, Matthew Lundin m...@imapmail.org ha scritto: Giovanni Ridolfi wrote: Hi, Matthew, thanks for replying. -file- -*- mode: org; -*- * TODO 1st head (setq org-todo-keywords '((sequence TODO FEEDBACK VERIFY | DONE DELEGATED))) # + SEQ_TODO: TODO FEEDBACK VERIFY DONE (setq org-todo-keywords '((type Fred Sara Lucy | DONE))) -- Is there a reason that you're putting all these lines in your org file? Well I'd like to have all the settings exploiting Local variables (for some reasons, last but not least to answer variables polls faster and with less work for Manish ;). But, IMHO :-), local variables are bad beasts, being difficult to configure. So first of all I wanted to be sure I could change the todo-keywords on a per file basis with setq. Only then I will fight with the local variables syntax.. Normally, you would put #1 *or* #3 in your .emacs file and #2 at the top of your org file for in buffer settings. BTW It works also if it is in the middle. If I + go to ))) + C-x C-e + M-x normal-mode (to restart Org-mode) I think you need to use M-x org-mode-restart to restart org-mode with the new settings. It doesn't work either. Thanks anyway. I suspect I have to change also some other variable or setting besides org-todo-keyword, but I don't have any idea. Giovanni __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Article: Synchronizing org Files Using bzr and git
Mark Elston wrote:
Just a note. Be careful of the use of colors. For example,
you have quoted strings in yellow in section 3.3. This color
makes the strings almost invisible on my screen. This makes
it hard to read.
Also, is there a single-page or pdf version of this material?
Mark,
Sorry about the yellow I hadn't noticed it. I am trying to fix it, but
it seems to be defeating my very limited css skills. The css generated
by org is:
pre class=src src-emacs-shell
*~
/pre
pre class=src src-emacs-shell
bzr add *.org
/pre
In my stylesheet I am trying things like:
pre.src {
font-style: bold;
color: black;
}
span.src-emacs-shell {color: black;}
However, I can't get the span (which should affect the quoted text) to
work. I would appreciate it if someone could point me in the righ direction.
Once I have sorted this I will generate a PDF version.
Ian.
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] bug? setting todo keywords
Hi Giovanni, I am doing exactly what you do: C-c C-e after the setq form, then M-x normal-mode. Works perfectly. The only reason I can think of is that you somehow managed to make org-todo-keywords a local variable. This can happen with a File Variable section in the buffer, or if you have something like (make-variable-buffer-local 'org-todo-keywords) in .emacs or elsewhere. You can check in the org buffer with C-h v org-todo-keywords RET If the variable is local in that buffer, the Help window will say so. org-todo-keywords should *not* be a local variable. However, if it is, your setq evaluation will set the local value only. Then you restart the major mode with normal-mode or similar, and the first thing this will do is *deleting* all local variables. HTH - Carsten On Mar 4, 2009, at 11:54 AM, Giovanni Ridolfi wrote: Hello everybody I'm not able to change the todo keywords in a file with setq org-todo-keywords and restarting org-mode as described in the manual § 5.2.1 . Org-mode version 6.23b GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600) of 2009-02-01 on SOFT- MJASON M$Widows XP -file- -*- mode: org; -*- * TODO 1st head (setq org-todo-keywords '((sequence TODO FEEDBACK VERIFY | DONE DELEGATED))) # + SEQ_TODO: TODO FEEDBACK VERIFY DONE (setq org-todo-keywords '((type Fred Sara Lucy | DONE))) -- If I + go to ))) + C-x C-e + M-x normal-mode (to restart Org-mode) the * TODO sequence is still TODO DONE The sequence is changed (feedback, delegated...) - if I change it via the customization interface - if I use #+SEQ_TODO: and C-c C-c on it I'm puzzled! the sequence is changed with the type keyword (setq org-todo-keywords '((type ^ Is it a bug or do I miss something? cheers, Giovanni __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: done-ing a repeating scheduled task now inserts closed timestamp?
Carsten Dominik domi...@science.uva.nl writes: On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote: I think a perhaps better behavior could be that the same line: ** TODO Check backups 2009-03-05 Thu 11:00 +2d is marked as done, then a) a *copy* is made of the TODO item, and that copy is the one that goes to DONE and gets the CLOSED (i.e., a normal task is generated and updated) and b) the repeating task is shifted (without attaching anything to it, since it is a fresh task): ** DONE Check backups 2009-03-05 Sat 11:00 CLOSED: [2009-03-05 Tue 07:57] - State DONE from TODO [2009-03-03 Tue 07:57] ** TODO Check backups 2009-03-07 Sat 11:00 +2d Apart from behaving more like a normal task this would have in my mind some additional advantages: I like DONE tasks to eventually disappear from my agenda. I do this by archiving them (to sibling). This allows me to easily see that I have not left anything behind in past days. I could now do this with the copied task, independently of the updated repeater. When I want to look at what I did on a certain day I hit the handy v key and the archived, done tasks appear again, including those that originated from the repeater --great! I.e., the repeater leaves behind a trail of normal tasks. This is an interesting, alternative proposal for repeating tasks. Anyone else would like to comment on this? Here are some comments :) I've thought that copying the repeated task would be useful as well but it might not be worth the effort to get it right for the general case. My concern in copying it is I want most of the content copied too. I regularly add check box lists to repeated tasks with a list of things to do and properties to reset the check boxes. The new copied task would ideally (for me) keep the :PROPERTIES: drawer and the content but not the :LOGBOOK: drawer. Any notes and things would go in the LOGBOOK drawer that shouldn't be carried forward. ,[ before copy ] | ** TODO Weekly Review |SCHEDULED: 2009-03-09 Mon ++1w |:LOGBOOK:... |:PROPERTIES: |:RESET_CHECK_BOXES: t |:END: | |- [ ] Do this |- [ ] Do that |- [ ] Do another thing | |Skip these | |- [ ] Used to be Important task 1 |- [ ] Used to be Important task 2 | | ** Next task ` After copying for repeat I'd like the new task to be: ,[ after copy (new copied task) ] | ** TODO Weekly Review |SCHEDULED: 2009-03-16 Mon ++1w |:PROPERTIES: |:RESET_CHECK_BOXES: t |:END: | |- [ ] Do this |- [ ] Do that |- [ ] Do another thing | |Skip these | |- [ ] Used to be Important task 1 |- [ ] Used to be Important task 2 | | ** Next task ` The DONE task should probably have the check boxes retained checked, and the new copy has the checkboxes cleared. This seems like it could get overly complicated real fast. :( I could also see this for more involved tasks where you want to propagate the subtree too (like my bookkeeping task has lots of steps which I keep as separate tasks below the repeated tasks). Copying the level 2 task (Q2 Accounting) would need to copy all of the subtasks in the tree and strip out the :LOGBOOK: drawers from the copy. ** TODO Q2 Accounting :PROJECT: DEADLINE: 2009-04-30 Thu +1y :PROPERTIES: :Effort: 3:00 :ORDERED: t :END: *** TODO January Accounting [0/17] [0%] :NEXT: :LOGBOOK:... :PROPERTIES: :RESET_CHECK_BOXES: t :END: - [ ] Enter Personal Expenses - [ ] Enter credit card charges - [ ] Balance credit card statement - [ ] Enter Cheques and payments - [ ] Enter Invoices - Receive Payments - [ ] Balance Bank accounts ... - [ ] Get USD value at month end - [ ] Foreign Exchange Adjustments - [ ] Print Reports - [ ] File receipts and reports *** TODO February Accounting [0/17] [0%]... *** TODO Mileage Jan - Mar :PROPERTIES:... | | Date| Car | From |To | Total | Where | Why | |---+-+-+---+---+---++---| | # | | | | | || | *** TODO March Accounting [0/17] [0%]... TODO Record personal mileage details... *** TODO GST [0/3] [0%] :LOGBOOK:... :PROPERTIES: :Effort: 0:10 :RESET_CHECK_BOXES: t :END: - [ ] Print GST Reports - [ ] File receipts and reports - [ ] File GST Tax Return After writing all this... it would probably be easier just to extract out the :LOGBOOK: entries and duplicate the subtree structure for the completed tasks. (ie. the copy is the completed task and just
[Orgmode] Re: Article: Synchronizing org Files Using bzr and git
Ian Barton li...@manor-farm.org writes:
Mark Elston wrote:
Just a note. Be careful of the use of colors. For example,
you have quoted strings in yellow in section 3.3. This color
makes the strings almost invisible on my screen. This makes
it hard to read.
Also, is there a single-page or pdf version of this material?
Mark,
Sorry about the yellow I hadn't noticed it. I am trying to fix it, but
it seems to be defeating my very limited css skills. The css generated
by org is:
pre class=src src-emacs-shell
*~
/pre
pre class=src src-emacs-shell
bzr add *.org
/pre
In my stylesheet I am trying things like:
pre.src {
font-style: bold;
color: black;
}
span.src-emacs-shell {color: black;}
However, I can't get the span (which should affect the quoted text) to
work. I would appreciate it if someone could point me in the righ
direction.
Once I have sorted this I will generate a PDF version.
The span has a hardcoded style element which specifies the colour
span style=color: rgb(255, 255, 85);Imported sources./span
I don't think you will be able to override that with CSS. You need to
somehow remove the embedded style from the exported source.
-Bernt
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: DocBook exporter for Org-mode
Sebastian I highly apreciate the support of Docbook and your Sebastian effort. Yet, I think I don't want to publish XHTML through Sebastian Docbook. Googling brings up quite some interesting formats supported through DocBook. These are some of the formats I found on the first glance: * ODT * SWX * (somwhat limited) MSword * Java Help * Windows Help * Entire Websites I just did a quick search only and I think more intensive search would reveal many more. -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Article: Synchronizing org Files Using bzr and git
On Mar 4, 2009, at 3:37 PM, Bernt Hansen wrote:
Ian Barton li...@manor-farm.org writes:
Mark Elston wrote:
Just a note. Be careful of the use of colors. For example,
you have quoted strings in yellow in section 3.3. This color
makes the strings almost invisible on my screen. This makes
it hard to read.
Also, is there a single-page or pdf version of this material?
Mark,
Sorry about the yellow I hadn't noticed it. I am trying to fix it,
but
it seems to be defeating my very limited css skills. The css
generated
by org is:
pre class=src src-emacs-shell
*~
/pre
pre class=src src-emacs-shell
bzr add *.org
/pre
In my stylesheet I am trying things like:
pre.src {
font-style: bold;
color: black;
}
span.src-emacs-shell {color: black;}
However, I can't get the span (which should affect the quoted text)
to
work. I would appreciate it if someone could point me in the righ
direction.
Once I have sorted this I will generate a PDF version.
The span has a hardcoded style element which specifies the colour
span style=color: rgb(255, 255, 85);Imported sources./span
I don't think you will be able to override that with CSS. You need to
somehow remove the embedded style from the exported source.
I think this is related to the value of org-export-htmlize-output-type.
It should be `inline-css' or `css', seems to me that you have set it
to `font'.
- Carsten
-Bernt
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Article: Synchronizing org Files Using bzr and git
Bernt Hansen be...@norang.ca writes:
Mark,
Sorry about the yellow I hadn't noticed it. I am trying to fix it, but
it seems to be defeating my very limited css skills. The css generated
by org is:
pre class=src src-emacs-shell
*~
/pre
pre class=src src-emacs-shell
bzr add *.org
/pre
In my stylesheet I am trying things like:
pre.src {
font-style: bold;
color: black;
}
span.src-emacs-shell {color: black;}
However, I can't get the span (which should affect the quoted text) to
work. I would appreciate it if someone could point me in the righ
direction.
Once I have sorted this I will generate a PDF version.
The span has a hardcoded style element which specifies the colour
span style=color: rgb(255, 255, 85);Imported sources./span
I don't think you will be able to override that with CSS. You need to
somehow remove the embedded style from the exported source.
M-x customize-variable RET htmlize-output-type
and set it to `css' or `inline-css'.
Your setting is `font'
Best,
--
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.: +49 (0)511 - 36 58 472
Fax: +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http: www.emma-stil.de
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Sebastian Rose wrote: Hi Scott, this is fixed now in v.0.1.0.4 Thanks, it works. I do have some suggestions for the title. 1. Unfortunately, I cannot use the ftoc:t option. For reasons I won't go into here, I cannot have the table of contents displayed on one side of the page. If I use ftoc:t, then the table of contents will always be displayed at the top which is not what I need. What I need is for the title to be independent of the table of contents. 2. I like the idea of having the title always visible in info-view-mode. However, others may not. Is it possible to add a title display option to the code? That way the user could decide which option to use. Maybe something like this: To always display the title in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:always To never display the title in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:never To only display the title above the table of contents in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:top I think the default should be either infotitledisplay:always or infotitledisplay:top with my preference being infotitledisplay:always. In plain-view-mode it makes sense to me to have the title at the top, I don't see any need to have title display options for this mode. Unfortunately, my knowledge of Javascript is very limited, so I'm not able to write the code for these options at this time. But I'd be happy to test any changes you make. Scott As always, the script is available on repo_or_cz: http://repo.or.cz/w/Worg.git?a=blob_plain;f=code/org-info-js/org-info.js;hb=e11bc7fe538a513d899f4d006bf5f887f35dd8ce Regards, Sebastian Sebastian Rose sebastian_r...@gmx.de writes: Hi Scott, thanks for the report. The handling of the title is one of the weak points of the script (another one being the text before first headline). The reason might be, that I was never sure what to do with it in info-view-mode, plain-view-mode, TOC hidden, TOC. In info-view-mode, the title is displayed on top as `Top: title', which is not what one might expect. Look at http://orgmode.org/worg/org-faq.php - there the title is always visible (fixed toc). Should we do it that way? As the docs say, the slides mode is very experimental... Regards, Sebastian sran...@uakron.edu writes: Hi again, Sorry for the multiple messages. I just noticed one other thing. When I go from slide mode to plain mode, the full table of contents will not be displayed unless I reload the page. Scott Randby ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Hi Scott, in info-view-mode the title is by default in the first section to avoid scrolling. But you may pull the latest version and append '_title-above' to the `view:' option, to leave it above regardless of view-mode. #+INFOJS_OPT: view:info_title-above #+INFOJS_OPT: view:plain_title-above Best Regards, Sebastian Scott Randby sran...@uakron.edu writes: Sebastian Rose wrote: Hi Scott, this is fixed now in v.0.1.0.4 Thanks, it works. I do have some suggestions for the title. 1. Unfortunately, I cannot use the ftoc:t option. For reasons I won't go into here, I cannot have the table of contents displayed on one side of the page. If I use ftoc:t, then the table of contents will always be displayed at the top which is not what I need. What I need is for the title to be independent of the table of contents. 2. I like the idea of having the title always visible in info-view-mode. However, others may not. Is it possible to add a title display option to the code? That way the user could decide which option to use. Maybe something like this: To always display the title in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:always To never display the title in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:never To only display the title above the table of contents in info-view-mode, add the following to the org file: #+INFOJS_OPT: infotitledisplay:top I think the default should be either infotitledisplay:always or infotitledisplay:top with my preference being infotitledisplay:always. In plain-view-mode it makes sense to me to have the title at the top, I don't see any need to have title display options for this mode. Unfortunately, my knowledge of Javascript is very limited, so I'm not able to write the code for these options at this time. But I'd be happy to test any changes you make. Scott As always, the script is available on repo_or_cz: http://repo.or.cz/w/Worg.git?a=blob_plain;f=code/org-info-js/org-info.js;hb=e11bc7fe538a513d899f4d006bf5f887f35dd8ce Regards, Sebastian Sebastian Rose sebastian_r...@gmx.de writes: Hi Scott, thanks for the report. The handling of the title is one of the weak points of the script (another one being the text before first headline). The reason might be, that I was never sure what to do with it in info-view-mode, plain-view-mode, TOC hidden, TOC. In info-view-mode, the title is displayed on top as `Top: title', which is not what one might expect. Look at http://orgmode.org/worg/org-faq.php - there the title is always visible (fixed toc). Should we do it that way? As the docs say, the slides mode is very experimental... Regards, Sebastian sran...@uakron.edu writes: Hi again, Sorry for the multiple messages. I just noticed one other thing. When I go from slide mode to plain mode, the full table of contents will not be displayed unless I reload the page. Scott Randby ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Email: s.r...@emma-stil.de, sebastian_r...@gmx.de Http: www.emma-stil.de ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Org-Info.js Issue
Sebastian Rose wrote: in info-view-mode the title is by default in the first section to avoid scrolling. Alright, now I understand the issue. But you may pull the latest version and append '_title-above' to the `view:' option, to leave it above regardless of view-mode. #+INFOJS_OPT: view:info_title-above #+INFOJS_OPT: view:plain_title-above Great. Thanks for your work and quick responses. Scott ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: DocBook exporter for Org-mode
Baoqiu == Baoqiu Cui cbao...@yahoo.com writes: Baoqiu It is true that many open-source tools around DocBook are still Baoqiu not perfect, but they should be good enough for most of the work Baoqiu of most users. Some commercial tools exist and are better, but Baoqiu they are not free. (I have not used reST, however it does not Baoqiu seem to me that it has more tools than DocBook.) Well, frankly speaking, I consider that XML simply sucks as authoring format. I was playing with FOP several years ago and I'd never replace it with TeX typesetting. Baoqiu I just checked reST markup specifications, and they do look Baoqiu powerful (but not very lightweight). Well, reST is, imho, (similar to markdown), much more readable than XML with all those brackets. Baoqiu Maybe it *is* time to have a standard to unify all these Baoqiu plain-text based lightweight markup languages: Muse, Org, reST, Baoqiu asciidoc, all kinds of *wiki*, doxygen styles, etc. Maybe Creole (http://en.wikipedia.org/wiki/Creole_(markup) )? Baoqiu These languages won't be lightweight and easy to read once they Baoqiu become more powerful. At that point, I'd prefer to go back to Baoqiu LaTeX or DocBook. I do not miss any feature in reST for my writing, the whole Python docs is written with it and it is for me still much readable in 'source' form than DocBook. Baoqiu That may require some code sharing/merging between rst.el and Baoqiu Org-mode, I guess. :-) Heh, I'm curious to know more about it. ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgp6SxdvXon3m.pgp Description: PGP signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: DocBook exporter for Org-mode
Matthew == Matthew Lundin m...@imapmail.org writes: Hi Matthew, Matthew Apart from odt output, I'd be curious to know what reST can do Matthew that org-mode markup and export cannot. Footnotes, tables, Matthew hyperlinks, images---I've found org-mode to be a really great Matthew authoring tool for exporting both to xhtml, ascii, and Matthew LaTeX/pdf output. (And, of course, using latex2rtf, it's Matthew trivial to convert the tex files org-mode produces into files Matthew that can be edited in Open Office.) I like and plan to learn org-mode to extend the present use greatly, but similar to Muse, its use is 'limited' to Emacs users while I've need to share some docs (e.g. writing documentation for software application) with non-Emacs users, so using more 'standardized' markup is a 'pro' here. Matthew I wonder if the ascii export from org would be difficult to Matthew convert to reST markup. Section headers and footnotes in the Matthew ascii export seem pretty close to the corresponding markup in Matthew reST. Just a thought Dunno more about Asciidoc, but it would be great if Pandoc (http://johnmacfarlane.net/pandoc/) would have full parser for reST 'cause it represents any supported markup in 'native' state before doing conversion and it even outputs to Docbook :-) So, my main point of using reST is more 'standard' and lightweight input markup with the plethora of output formats. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgp9aRYG4Us8Z.pgp Description: PGP signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: DocBook exporter for Org-mode
Sebastian == Sebastian Rose sebastian_r...@gmx.de writes: Sebastian I just did a quick search only and I think more intensive Sebastian search would reveal many more. Check Pandoc's features: Pandoc is a Haskell library for converting from one markup format to another, and a command-line tool that uses this library. It can read markdown and (subsets of) reStructuredText, HTML, and LaTeX, and it can write markdown, reStructuredText, HTML, LaTeX, ConTeXt, PDF, RTF, DocBook XML, OpenDocument XML, ODT, GNU Texinfo, MediaWiki markup, groff man pages, and S5 HTML slide shows. In the past I also played with: http://txt2tags.sourceforge.net/ Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpEkCzHctWnx.pgp Description: PGP signature ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Tag Searches
Hi, Whenever a tag search is done, the beginning of the lines containing the desired tags are highlighted (in yellow with my setup). I can see why this is desired behavior, but I don't want my tag searches to highlight anything. First, I don't like the way the highlighting looks, and second, the highlighting forces me to do C-u C-c C-c twice if I want to recompute the values in a table. Being lazy, I only want to do C-u C-c C-c once. So, is there a way to set org-mode so that it won't highlight the results of a tag search? I've tried customizing various variables, but nothing I've tried works, and I can't find anything about this in the manual. Oh yes, I'm using org-mode 6.23 in emacs 22 though this has been an issue for me all the versions of org-mode I've used. Scott Randby ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Buffer *temp* modified; kill anyway?
Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Cheers - bw -- Bill White . bi...@wolfram.com . http://members.wolfram.com/billw No ma'am, we're musicians. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: DocBook exporter for Org-mode
Hi Gour, Gour g...@mail.inet.hr writes: Baoqiu == Baoqiu Cui cbao...@yahoo.com writes: Baoqiu It is true that many open-source tools around DocBook are still Baoqiu not perfect, but they should be good enough for most of the work Baoqiu of most users. Some commercial tools exist and are better, but Baoqiu they are not free. (I have not used reST, however it does not Baoqiu seem to me that it has more tools than DocBook.) Well, frankly speaking, I consider that XML simply sucks as authoring format. I was playing with FOP several years ago and I'd never replace it with TeX typesetting. I knew it must be FOP that you did not like. ;-) I had similar experience using FOP, and I (and all other team members) had to find workarounds when hitting problems in FOP (like formatting footnotes in lists or tables). Don't know if you have tried XEP from RenderX. I have not found any problems in XEP. I don't think it's bad to use XML as authoring format, even though I think TeX would still be the ultimate typesetting tool. Baoqiu I just checked reST markup specifications, and they do look Baoqiu powerful (but not very lightweight). Well, reST is, imho, (similar to markdown), much more readable than XML with all those brackets. Many people who don't like LaTeX can say similar things about LaTeX. ;-) The main problem with all these lightweight markup languages is that there is a limitation on their expressing power. They are perfect tools for quickly publishing blogs, wikis, simple web sites, documentation of source code, etc., but will quickly hit their limit when they are used for more serious publishing. Baoqiu Maybe it *is* time to have a standard to unify all these Baoqiu plain-text based lightweight markup languages: Muse, Org, reST, Baoqiu asciidoc, all kinds of *wiki*, doxygen styles, etc. Maybe Creole (http://en.wikipedia.org/wiki/Creole_(markup) )? Thanks for the link! Haven't heard about it. Baoqiu That may require some code sharing/merging between rst.el and Baoqiu Org-mode, I guess. :-) Heh, I'm curious to know more about it. ;) I don't know much about rst.el, and am still new to Org-mode, so cannot say much on this. :-) Thanks, Baoqiu ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Buffer *temp* modified; kill anyway?
Bill White bi...@wolfram.com wrote: Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Bill, I just tried exporting the following: , | * Lisp source code | | #+begin_src emacs-lisp | (defun org-xor (a b) | Exclusive or. | (if a (not b) b)) | #+end_src ` and did not have the problem you describe. Can you post a minimal example? Version info: Org-mode version 6.23trans GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-07-01 on alphaville.zko.hp.com htmlize-version 1.34 Nick ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Buffer *temp* modified; kill anyway?
On Wed Mar 04 2009 at 12:38, Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Bill, I just tried exporting the following: , | * Lisp source code | | #+begin_src emacs-lisp | (defun org-xor (a b) | Exclusive or. | (if a (not b) b)) | #+end_src ` and did not have the problem you describe. Can you post a minimal example? Here's one that triggers it: , | * Lisp source code | | #+begin_src message | From: Nick Dokos nicholas.do...@hp.com | Subject: Re: [Orgmode] Buffer *temp* modified; kill anyway? | To: Bill White bi...@wolfram.com | Cc: emacs-orgmode@gnu.org | Date: Wed, 04 Mar 2009 13:38:32 -0500 (from Gnus) | Reply-To: nicholas.do...@hp.com | X-Sent: 1 hour, 9 minutes, 51 seconds ago | Message-ID: 9344.1236191...@alphaville.usa.hp.com | #+end_src ` Interestingly, the message is not triggered when I use your example with its #+begin_src emacs-lisp, nor does #+begin_src mma trigger it (using Tim Wichmann's mma.el). My versions are: - Org-mode version 6.23trans - GNU Emacs 23.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2009-02-14 on billw-desktop - htmlize-version 1.34 - message.el version 1.169 (from the emacs cvs checkout above) Thanks for the example - I didn't realize that some src modes didn't trigger the problem. Cheers - bw -- Bill White . bi...@wolfram.com . http://members.wolfram.com/billw No ma'am, we're musicians. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Buffer *temp* modified; kill anyway?
Bill White bi...@wolfram.com wrote: On Wed Mar 04 2009 at 12:38, Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Bill, I just tried exporting the following: , | * Lisp source code | | #+begin_src emacs-lisp | (defun org-xor (a b) | Exclusive or. | (if a (not b) b)) | #+end_src ` and did not have the problem you describe. Can you post a minimal example? Here's one that triggers it: , | * Lisp source code | | #+begin_src message | From: Nick Dokos nicholas.do...@hp.com | Subject: Re: [Orgmode] Buffer *temp* modified; kill anyway? | To: Bill White bi...@wolfram.com | Cc: emacs-orgmode@gnu.org | Date: Wed, 04 Mar 2009 13:38:32 -0500 (from Gnus) | Reply-To: nicholas.do...@hp.com | X-Sent: 1 hour, 9 minutes, 51 seconds ago | Message-ID: 9344.1236191...@alphaville.usa.hp.com | #+end_src ` Interestingly, the message is not triggered when I use your example with its #+begin_src emacs-lisp, nor does #+begin_src mma trigger it (using Tim Wichmann's mma.el). My versions are: - Org-mode version 6.23trans - GNU Emacs 23.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2009-02-14 on billw-desktop - htmlize-version 1.34 - message.el version 1.169 (from the emacs cvs checkout above) Thanks for the example - I didn't realize that some src modes didn't trigger the problem. The problem seems to arise in the following code from org-exp.el:org-export-format-source-code-or-example: ... (setq rtn (with-temp-buffer (insert rtn) (if (functionp mode) (funcall mode) (fundamental-mode)) (font-lock-fontify-buffer) (org-export-htmlize-region-for-paste (point-min) (point-max ... The with-temp-buffer macro looks like this (it's in subr.el): (defmacro with-temp-buffer (rest body) Create a temporary buffer, and evaluate BODY there like `progn'. See also `with-temp-file' and `with-output-to-string'. (declare (indent 0) (debug t)) (let ((temp-buffer (make-symbol temp-buffer))) `(let ((,temp-buffer (generate-new-buffer *temp*))) ;; FIXME: kill-buffer can change current-buffer in some odd cases. (with-current-buffer ,temp-buffer (unwind-protect (progn ,@body) (and (buffer-name ,temp-buffer) (kill-buffer ,temp-buffer))) The *temp* buffer that is created ends up with the body of the begin_src/end_src construct as its contents, but in the emacs-lisp instance, the call to kill-buffer in the macro succeeds without the Buffer modified question being asked, whereas in the message case, it asks the question. In both cases, however the temp buffer seems modified to me.[1] So I don't understand the difference in behavior between the two cases, but maybe this provides enough detail for a better elisper than me to understand and explain to the rest of us. Nick [1] I added a call to debug in the original code, like this: (setq rtn (with-temp-buffer (let ((foo)) (insert rtn) (if (functionp mode) (funcall mode) (fundamental-mode)) (font-lock-fontify-buffer) (setq foo (org-export-htmlize-region-for-paste (point-min) (point-max))) (debug nil (buffer-name)) foo))) and checked the *temp* buffer when I got to the breakpoint, but in both cases it looks modified to my eye (I also evaluated (buffer-modified-p) in each case: it returned t). And I also checked kill-buffer-query-functions and kill-buffer-hook in the two cases: they are the same. In particular, in my emacs, kill-buffer-query-functions has the value (server-kill-buffer-query-function) and kill-buffer-hook has the value (reftex-kill-buffer-hook tramp-flush-file-function preview-kill-buffer-cleanup browse-url-delete-temp-file vc-kill-buffer-hook) Mark me mystified. ___ Emacs-orgmode mailing list Remember: use `Reply All' to
Re: [Orgmode] Buffer *temp* modified; kill anyway?
Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: On Wed Mar 04 2009 at 12:38, Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Bill, So I don't understand the difference in behavior between the two cases, but maybe this provides enough detail for a better elisper than me to understand and explain to the rest of us. OK - I think I know why: the mode of the temp buffer is set according to the language in the begin_src construct: emacs-lisp-mode in one case, message-mode (and a bunch of minor modes) in the other. The difference is that the latter associates the buffer with a file, whereas the former does not. It's that difference that makes kill-buffer behave differently. I suspect that the thing to do is to mark the buffer unmodified. Here's a patch: diff --git a/lisp/org-exp.el b/lisp/org-exp.el index a0d1e5f..c20112f 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -2472,6 +2472,7 @@ Numbering lines works for all three major backends (html, latex, and ascii). (funcall mode) (fundamental-mode)) (font-lock-fontify-buffer) + (set-buffer-modified-p nil) (org-export-htmlize-region-for-paste (point-min) (point-max (if (string-match pre\\([^]*\\)\n? rtn) Nick ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-exp-bibtex.el - add support to citing bibtex in both html and latex exports
On Tue, Mar 3, 2009 at 3:34 AM, Carsten Dominik domi...@science.uva.nl wrote: Now how do we want to do this with org-mode? 1) The user is responsible for creating a bib-file using whatever tools she prefers (e.g. bib2bib). 2) Add an option to just select the entries that are used in the org-file. Nothing fancy. I think (1) and (2) would be really nice. 3) Add a generic API to select+sort+format the entries. (3) seems to be indeed more than necessary. I for one would be perfectly happy if the entries would come out in the sequence of citation, which will likely be automatic? Agreed. Alphabetic sorting would be a nice optional extra, but just (1) and (2) would be great. Cheers Will -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] My Python solution to generating unique Ids in headlines
Recently I asked about a method of inserting a unique number in a headline. My requirement is to be able to uniquely identify a particular headline when exporting data to another system (ListPro on Palm/Windows). I settled on using a small Python script, since I am not a Lisp programmer. 1. I created a text file todononum.txt which contains the next number to use. 2. I created the following script to read this file, return the next available number formatted in a unique, easy to find string, for example [#310]. # script next_todo.py import sys nextnum_file = C:/charles/gtd/todonum.txt try: f = open(nextnum_file, 'r') except IOError: print Unable to open %s. Program terminating. % nextnum_file sys.exit(1) val = int(f.readline()) + 1 f.close() of = open(nextnum_file, 'w') of.write(%d\n % val) of.close() print [#%s] % val 3. I created a one line batch file nextnum.bat (I'm on Windows!) containing: python c:/charles/gtd/next_todo.py 4. In org-mode I insert the unique id by positioning the cursor at the end of the headline text, then entering the command ESC-1 ESC-! nextnum RET Ctl-D The Ctrl D is needed to remove a carriage return (not sure why it is there. Can someone give me Lisp code equivalent of the command sequene above? I know it is something to do with (shell command ) The end result now looks like *** Post to org-mode list about next sequential [#315] :COMPUTER: Once I have Lisp code to implement the command sequence I will have a satisfactory solution to generating the unique id when I need it. --- Charles Cave Sydney, NSW, Australia Email: charles_c...@optusnet.com.au Follow me on Twitter: www.twitter.com/ozcaveman --- ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] My Python solution to generating unique Ids in headlines
Charles Cave charles_c...@optusnet.com.au wrote: ... print [#%s] % val ... ESC-1 ESC-! nextnum RET Ctl-D The Ctrl D is needed to remove a carriage return (not sure why it is there. Try import sys sys.stdout.write([%d] % val) instead of print. It should work on Windows as well (but I have not tested it there). Can someone give me Lisp code equivalent of the command sequene above? I know it is something to do with (shell command ) (shell-command nextnum t) It may be necessary to specify a complete path to the command. The end result now looks like *** Post to org-mode list about next sequential [#315] :COMPUTER: Once I have Lisp code to implement the command sequence I will have a satisfactory solution to generating the unique id when I need it. But I still don't understand why you need an external program: what is wrong with (insert (format [%s] (org-id-new)))? Are the IDs too ugly or is there some other problem? The trouble with unique IDs in files is that it's easy for them to get out of sync (leading to non-uniqueness), e.g. if there are two processes trying to get a unique id at the same time. Nick ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: My Python solution to generating unique Ids in headlines
Nick Dokos nicholas.dokos at hp.com writes: Try import sys sys.stdout.write([%d] % val) Thanks. That works fine. (shell-command nextnum t) This worked fine. It may be necessary to specify a complete path to the command. I diodnt need to because the .BAT file was in a directory which is part of the PAHT list. By the way, I had to include a beginning line of @ECHO OFF in the bat file. But I still don't understand why you need an external program: what is wrong with (insert (format [%s] (org-id-new)))? Are the IDs too ugly or is there some other problem? I'm struggling to find documentation or installing and using org-id. I added the line (require 'org-id) to my .eamcs file then discovered a variable to customise the method to internal or to use an external command uuidgen which doesnt exist on Windows. How do I change the name of the external command from uuidgent to nextnum The trouble with unique IDs in files is that it's easy for them to get out of sync (leading to non-uniqueness), e.g. if there are two processes trying to get a unique id at the same time. This shouldnt be a problem as I am the only user. Thanks for your help, Charles ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Buffer *temp* modified; kill anyway?
On Wed Mar 04 2009 at 16:26, Nick Dokos nicholas.do...@hp.com wrote: Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: On Wed Mar 04 2009 at 12:38, Nick Dokos nicholas.do...@hp.com wrote: Bill White bi...@wolfram.com wrote: Hi all - Buffer *temp* modified; kill anyway? is driving me nuts. Has anyone seen this error message when html-exporting pages that contain #+begin_src ? I get this once for every #+begin_src ... #+end_src group on a page. I assume it's coming from htmlize.el, but I haven't been able to isolate the problem with edebug. I'm using the latest htmlize.el from http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el Any ideas what's going on and how to silence it? If it weren't for this I'd be able to publish without babysitting the process through source-heavy files. Bill, So I don't understand the difference in behavior between the two cases, but maybe this provides enough detail for a better elisper than me to understand and explain to the rest of us. OK - I think I know why: the mode of the temp buffer is set according to the language in the begin_src construct: emacs-lisp-mode in one case, message-mode (and a bunch of minor modes) in the other. The difference is that the latter associates the buffer with a file, whereas the former does not. It's that difference that makes kill-buffer behave differently. I suspect that the thing to do is to mark the buffer unmodified. Here's a patch: That did it - what a relief! Your elisp skills are pretty sharp. I was looking in entirely the wrong place to solve this. Many thanks! bw -- Bill White . bi...@wolfram.com . http://members.wolfram.com/billw No ma'am, we're musicians. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
