Re: [O] Problem exporting code
Thomas S. Dye writes: > I think you and I have different definitions of "problem". From my > user's perspective, something I "get away with," i.e., that doesn't have > an effect on my work and productivity, isn't a problem. That may well be true. I'm firmly in the "fail fast and crash loudly" camp. In other words, if there is a problem, it should make itself known at the earliest possible moment in a way that makes clear that it needs to be fixed ASAP. I encounter many folks that disagree with that position, but usually only until one of those problems that fail to clearly announce themselves causes them to lose important work later on. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Using non-org files as agenda files?
On 1/22/13, Sven Bretfeld wrote: > Is it anyhow possible to use a .tex file as an org-agenda-file? It might be possible to put an ID marker in the document. A command then would take you to a headline in a .org file. That headline can then have all Org features. 1:1 mapping. Another command would take you back to that position in the document. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] Using non-org files as agenda files?
Sven Bretfeld writes:
> Dear all
>
> Is it anyhow possible to use a .tex file as an org-agenda-file?
>
> This might seem a silly question. The reason is that I stick to auctex
> for writing my documents. But it would be nice to be able to insert a
> todo item directly at an appropriate place within a tex-file and have it
> integrated in org-agenda-view.
One approach could be to use babel. That is, have an org file in which
all your latex sits as code segments. You can then edit each individual
code segment (C-c ') using auctex but keep org as an outliner and task
manager. You do lose some capabilities of auctex, specifically to do
with cross-referencing support, I would imagine. But you gain all the
power of org and continue to be able to use auctex's keybindings when
desired.
I've attached a simple example. Tangling the file (C-c C-v t) will
create l.tex which you can then process as desired.
> Maybe this can be done by a workaround using ipa.el (in-place
> annotations) and setting an orgmode file as ipa-file? Any experiences?
Thanks for reminding me of this. I had meant to try it out and forgot!
(forgot to create an org todo item... have done so now ;-)
HTH,
eric
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613
#+TITLE: Testing tangling etc. for latex
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2013-01-23 Wed
#+PROPERTY: tangle yes
* Cover material
#+begin_src latex
\documentclass{scrartcl}
\title{The document}
\author{ESF}
\begin{document}
\maketitle
#+end_src
* Introduction
In the introduction, we talk about the problem and why it is important.
#+begin_src latex
\section{Introduction}
\label{sec:intro}
Yes, here I talk about the problem.
#+end_src
* End matter
#+begin_src latex
% could put the bibliography here, for instance
\end{document}
#+end_src
Re: [O] org-caldav feedback
David Engster writes: [...] > I think I found a better solution. I pushed a change to org-caldav which > allows to set org-icalendar-timezone to the string "UTC", which will put > events using universal time. The server should then transpose it to the > timezone you have set in your SOGo preferences. It works for me (for > SOGo, mind you; other calendar servers don't work well with that). David, for those of us not using SOGo (I use Google), what should we do? I've not updated the version of org-caldav I'm using yet. By the way, I will take this opportunity to say that org-caldav is working like a charm for me. Although I haven't really pushed it to the limits, for day to day stuff it's working very well. I've had to clear out the org-caldav-xxx.el file in .emacs.d a couple of times but that's typically due to my doing things on the same entry in both calendar systems (org and Google). However, clearing out the file and having org-caldav re-sync everything from scratch is a simple and good enough solution for when problems arise. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613
[O] Wrong non-interactive behavior of org-insert-heading breaks org-mobile-pull
I've been working for a while to track down a problem that manifests in org-mobile-pull. It turns out the issue is actually in org-mode itself. Specifically (I think this is the right conclusion), if org-insert-heading-respect-content is called non-interactively, and the heading on which it's operating is invisible, then it actually inserts the heading under the previous higher-level visible heading. Example: I have a testing org file, synced up to MobileOrg, containing in part: * Top level 2 ** Second level 3 *** Under second 3 ** Second level 4 On my phone, I added a new heading "Test node C" under the parent "Under second 3." Expected result of org-mobile-pull: * Top level 2 ** Second level 3 *** Under second 3 Test node C ** Second level 4 Actual result of org-mobile-pull: * Top level 2 ** Second level 3 *** Under second 3 ** Second level 4 ** Test node C ~~ Exhaustive findings from edebug sessions follow: The way it's supposed to work is: 1. Find the parent (in this case, by olp). 2. Go to the end of the line. 3. org-insert-heading-respect-content: This should locate the end of the third level subtree (which is the same as the beginning of "Second level 4"), and then insert a new third level heading "*** " here. 4. Then org-mobile-edit demotes the new subheading and inserts the content. But, if I do org-mobile-pull with all of the top-level headings collapsed, what actually happens is: 1. Find the parent (in this case, by olp). 2. Go to the end of the line. 3. org-insert-heading-respect-content: First shows the parent subtree (the code snip is from org-insert-heading): (t ;; somewhere in the line (save-excursion (setq previous-pos (point-at-bol)) (end-of-line) (setq hide-previous (outline-invisible-p))) (and org-insert-heading-respect-content (org-show-subtree)) (org-show-subtree) calls (org-end-of-subtree), and this identifies the right point. But, showing the subtree (at least in my installation) shows the node's payload and any child nodes, but *it does not show the heading itself*. Then a little bit later we get: (when (featurep 'org-inlinetask) (while (and (not (eobp)) (looking-at "\\(\\*+\\)[ \t]+") (>= (length (match-string 1)) org-inlinetask-min-level)) (org-end-of-subtree nil t))) I'm not using inline tasks, so this falls through to (org-end-of-subtree nil t). This call explicitly clears the INVISIBLE-OK flag... so, the end-of-subtree location that it identifies is the next visible heading**and NOT the right place (which is hidden). This is the next top-level heading (because we started with all the top headings collapsed). Then, continuing blindly on, a new top-level heading is added, then demoted, and the fourth level heading but I added on my phone has become a second-level heading. ** Note: org-end-of-subtree reads the wrong level of the "current" heading in this instance, I think because it does (org-back-to-heading invisible-ok). Since invisible-ok is false, this would go back to the previous heading that is exposed, which in my test is top-level. So it seems this particular call to org-end-of-subtree assumes that the correct parent node is visible at that moment, but this assumption is not necessarily valid during org-mobile-pull. I suppose it could be fixed by changing 'nil' to 't' but I have no idea if this would break something else. I'll leave that to the experts to decide. hjh
Re: [O] block quotes in prose?
On Tue, Jan 22, 2013 at 6:13 PM, Peter Salazar wrote: > 1. What's the best way to demarcate block quotes in org-mode? I'd like a way > to demarcate them that makes it visually clear at a glance that it's a block > quote and not regular text. > > I would prefer not to have to put them inside #+BEGIN_QUOTE and #+END_QUOTE > references, because I'd rather not have any content in my buffer that > distracts me from my actual writing. > > In Markdown-Mode, for instance, I just prefix a block quote with a > and the > line automatically changes color: > > http://i.imgur.com/AUsYJ.png > > Org-mode is infinitely more powerful than Markdown-Mode, so I'd just like a > way to work with lots of prose and block quotes in org-mode that will be > easy and visually pleasing. I'm primarily concerned about how it appears in > the org-mode editor, not in export. > Looking around, at least some of this appears defined in /path/to/org-src/lisp/org-faces.el. I don't know enough elisp to tell you how to make Org treat "> text..." the same as #+begin_quote. Perhaps you could figure out where the face change is for lines like #+latex: and #+begin_src, as they both change the face of the text immediately after (no need for an #+end_ command to tell Org to go back to the default face). You might be able to add "^> text" to the list of face-sensitive regexps to look for (using ^ as symbol for beginning of line). ETA: after some more grepping, it looks like you could add something in two places: 1) org-faces.el Search the file for "defface" and make a new face. I've not done this, but you can definitely copy/yank some existing definitions and tweak to your liking. 2) org.el Find a matching fontify function to see how the fontification is done. They look pretty complicated... but perhaps it's possible to tweak one to fontify "^> text...". Perhaps the easiest would be to find a face you like and just add "^> text..." to the existing list of things org already fontifies with that style. In other words, add "^> text" regexp to the existing hunt for lines that start with #+ in order to get src code fontification applied. > 2. It would also be cool to find a way to make bulleted lists appear in a > different color if possible, or a workaround to simulate this. As in? - item 1 - item 2 I'm sure that's possible, too. Can't imagine this will become global, but you could surely create your own git branch if you figure out how or someone tells you how. Good luck! John > > Thanks! > >
Re: [O] Export of subtree does not include header
On Fri, Jan 18, 2013 at 4:35 AM, Søren Aagaard Mikkelsen wrote: > I have used orgmode for a while, but hasn't used any of its advanced > features that much. I'm currently writing a minutes report and what to > export a specific subtree, e.g. > > * Minutes from <2013-01-11> > > * Minutes from <2013-01-18><--- Want to export this only > > Then I press C-c @, which marks the subtree, and then I press C-c C-e > and export it as a pdf-document. > > The problem is that I want the top section to remain the same, i.e. "Minutes > from > <2013-01-18>" is the top section and the others to be subsection of > that. > > Currently, it surely exports the right subtree but the top-section is > not "Minutes from <2013-01-18>", but the bullet after that. I get the same behavior. Does it need to export it in a "tree" like format, or would you be okay with your top level headline (the one you want exported, but which is currently not) being the actual title of the document? Or is that what you're currently getting. With default settings (org-export-latex-title-command "\\maketitle"), I get the top-most headline of the marked subtree as my document title and the next level headline as the first section. Is this what you're getting, or the top headline text isn't showing up in the document at all? If having it as the title would work, you would get: -- [centered]Minutes from <2013-01-18>[centered] A bit of white space Any text directly under "Minutes from <2013-01-18>"... [section] The first headline under "Minutes from <2013-01-18>" [section] text under that headline [section 2] The second headline under "Minutes from <2013-01-18>" [section] text under that headline -- If it's just the centered text/bit white space gap you don't like, I'm sure there's LaTeX header arguments you could put in your Org document or setupfile to left-align the title and remove the space. What do you think of that option? Also... just to save you *one* keystroke, you can put your cursor on the headline of interest and do =C-e 1 p=, which I think does the same as marking the whole subtree with =C-c @ C-e p=. John > >
Re: [O] agenda question about representing items
Arun Persaud wrote: > Hi > > many of my projects have the following form: > > * project name > ** subtask > *** TODO item1 > SCHEDULED: > > sometimes it looks like > > * project name > ** subtask > *** TODO item2 [1/3] > - [X] task1 > - [ ] task2 > - [ ] task3 > SCHEDULED: > > currently my agenda view shows something like > > : TODO > > e.g. > home: Scheduled: TODO look into customize agenda views > > I'm wondering if it is possible to customize this, so that it will > display something like the following: > > : projectname->subtask->TODO look into customize agenda > views > > that is adding some breadcrumbs in front of the item to make it clearer > what the context of the TODO item is. > org-agenda-prefix-format can probably be adjusted to do some of this. In particular, %t can deal with the timestamp and %(expression) can evaluate a lisp expression: all you need to do is write a function to get the pieces you want. > For the second kind of items it would be nice to see something like this > in the agenda: > > : projectname->subtask->TODO item2 -> task2 > > e.g. also add the next item in the list that needs to be done. > > Any ideas? > I don't know how to do this or even if it is possible without mucking around with the code. But if history is any guide, it's probably possible :-) Nick
Re: [O] session with python-mode.el complains of void py-toggle-shells
Myles English wrote: > Hi, > > I think it should be possible to execute a python block in a session > using python-mode.el but get this message: > > "Symbol's function definition is void: py-toggle-shells" > > Using the latest git head and opening this file with: > > $ emacs -Q thisfile.org > > then executing these src blocks in order, shows the problem: > > #+BEGIN_SRC emacs-lisp > (require 'org) > (org-babel-do-load-languages >'org-babel-load-languages >'((python . t))) > #+END_SRC > > #+RESULTS: > | (python . t) | > > * A heading > > This works okay: > > #+begin_src python :results output :session a > import sys > #+end_src > > #+RESULTS: > > Try with python3: > > #+begin_src elisp > (setq org-babel-python-command "python3" > py-python-command "python3" > ) > #+end_src > > #+RESULTS: > : python3 > > works also: > > #+begin_src python :results output :session a > import sys > #+end_src > > #+RESULTS: > > Try using python-mode.el: > > #+begin_src elisp > (setq org-babel-python-mode 'python-mode) > (load-file "/usr/share/emacs/site-lisp/python-mode.el") > #+end_src > > #+RESULTS: > : t > > #+begin_src python :results output :session a > import sys > #+end_src > > Gives this *Message*: > > org-babel-python-initiate-session-by-key: Symbol's function definition > is void: py-toggle-shells > > Do I need to configure something else? > I get in trouble much sooner than you do: when evaluating the first code block. The error in my case was that run-python was called with the wrong number of args (from the same function: it's a couple of lines before py-toggle-shells is called). I'm running GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-12-29 and run-python does indeed need a required arg in this version: , | run-python is an interactive autoloaded compiled Lisp function in | `python.el'. | | (run-python CMD &optional DEDICATED SHOW) | | Run an inferior Python process. | Input and output via buffer named after | `python-shell-buffer-name'. If there is a process already | running in that buffer, just switch to it. ` So I changed the call to (run-python py-python-command) and then all the code blocks could execute with no problem. Has run-python changed signature recently? This may or may not be the problem you are running into however. Nick
[O] agenda question about representing items
Hi many of my projects have the following form: * project name ** subtask *** TODO item1 SCHEDULED: sometimes it looks like * project name ** subtask *** TODO item2 [1/3] - [X] task1 - [ ] task2 - [ ] task3 SCHEDULED: currently my agenda view shows something like : TODO e.g. home: Scheduled: TODO look into customize agenda views I'm wondering if it is possible to customize this, so that it will display something like the following: : projectname->subtask->TODO look into customize agenda views that is adding some breadcrumbs in front of the item to make it clearer what the context of the TODO item is. For the second kind of items it would be nice to see something like this in the agenda: : projectname->subtask->TODO item2 -> task2 e.g. also add the next item in the list that needs to be done. Any ideas? Thanks Arun
[O] session with python-mode.el complains of void py-toggle-shells
Hi, I think it should be possible to execute a python block in a session using python-mode.el but get this message: "Symbol's function definition is void: py-toggle-shells" Using the latest git head and opening this file with: $ emacs -Q thisfile.org then executing these src blocks in order, shows the problem: #+BEGIN_SRC emacs-lisp (require 'org) (org-babel-do-load-languages 'org-babel-load-languages '((python . t))) #+END_SRC #+RESULTS: | (python . t) | * A heading This works okay: #+begin_src python :results output :session a import sys #+end_src #+RESULTS: Try with python3: #+begin_src elisp (setq org-babel-python-command "python3" py-python-command "python3" ) #+end_src #+RESULTS: : python3 works also: #+begin_src python :results output :session a import sys #+end_src #+RESULTS: Try using python-mode.el: #+begin_src elisp (setq org-babel-python-mode 'python-mode) (load-file "/usr/share/emacs/site-lisp/python-mode.el") #+end_src #+RESULTS: : t #+begin_src python :results output :session a import sys #+end_src Gives this *Message*: org-babel-python-initiate-session-by-key: Symbol's function definition is void: py-toggle-shells Do I need to configure something else? Thanks, Myles
Re: [O] How to deal with small projects which are often changing their status/ person
M writes: > I hope it is clear what I mean, there are a lot of small steps and each time > creating a new task takes much time and I have to copy the name of the > "project" again and again... > > Maybe it would be better to add all the notes about the progress as notes in > the Logbook and change the Heading of the task each time, but that also > seems strange to me... This is exactly what I do, and it works great for me. If you enable state-change logging for the TODO keywords you use most, you can keep a fully annotated and time-stamped history of how the TODO has progressed. I make the heading something generic (ie, "Article XYZ") and note what has to be done next in the logbook. I like the idea of a single TODO for a single "thing", even if that thing has multiple steps. I often don't know what those steps are going to be (arguments over email, waiting for someone to get back from vacation, blocking on another task, etc) so I need flexibility. In practice, most of my complex tasks start at TODO, bounce back and forth between NEXT and WAITING, and finally end up at DONE. Changes between WAITING and NEXT are logged, so I end up with a LOGBOOK full of neatly stamped changes, each one with a description (plus links to emails and all) of progress. This "feels right" to me. My main custom agenda view has a block each for WAITING and NEXT headings. > Would there be a way to make the "children" inherit automatically a text > from the project name, e. g. Wouldn't this be best taken care of with tags and tag inheritance? I also put colleagues' names in tags, when something requires their participation, which makes it easy get a view of "stuff John should be doing". The problem with the logbook approach is that logbook entries are fairly limited beasts (you can't tag them, for instance), and I'm probably already on the verge of abusing them. Next on my list would be sorting agenda items by timestamp of most recent log entry, and also an agenda hotkey to display the most recent log entry for the TODO under point. Possibly what I should be considering is a state-change trigger that actually creates a sub-heading TODO, rather than a logbook entry. Hope something in there's useful! Eric
Re: [O] Bug: `org-next-link' doesn't wrap around [7.9.3d (7.9.3d-GNU-Emacs-24-3 (commit e8f5b0ad) @ /usr/local/share/emacs/24.3.50/lisp/org/)]
On Tue, 22 Jan 2013 22:19:19 +0100 Bastien wrote: > I don't understand what "wrap around" means exactly. > > Can you describe exactly how the commands should behave? Sorry, it's my carelessness. At the limit of the buffer, the search fails once, and then wraps around, just like `isearch-forward'. There is no bug, anyway. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
[O] block quotes in prose?
1. What's the best way to demarcate block quotes in org-mode? I'd like a way to demarcate them that makes it visually clear at a glance that it's a block quote and not regular text. I would prefer not to have to put them inside #+BEGIN_QUOTE and #+END_QUOTE references, because I'd rather not have any content in my buffer that distracts me from my actual writing. In Markdown-Mode, for instance, I just prefix a block quote with a > and the line automatically changes color: http://i.imgur.com/AUsYJ.png Org-mode is infinitely more powerful than Markdown-Mode, so I'd just like a way to work with lots of prose and block quotes in org-mode that will be easy and visually pleasing. I'm primarily concerned about how it appears in the org-mode editor, not in export. 2. It would also be cool to find a way to make bulleted lists appear in a different color if possible, or a workaround to simulate this. Thanks!
[O] Using non-org files as agenda files?
Dear all Is it anyhow possible to use a .tex file as an org-agenda-file? This might seem a silly question. The reason is that I stick to auctex for writing my documents. But it would be nice to be able to insert a todo item directly at an appropriate place within a tex-file and have it integrated in org-agenda-view. Maybe this can be done by a workaround using ipa.el (in-place annotations) and setting an orgmode file as ipa-file? Any experiences? Thanks Sven
Re: [O] How to deal with small projects which are often changing their status/ person
M writes: > Hi Thomas, > > thanks for your reply! > > Sure I know Bernt Hansen's web page and I'm already using his configuration > for my system. (I'm still learning Emacs and org-mode, so it was easier to > start with an existing setup). > > I already know and use the capture and refile feature, > my problem is that I have the feeling to do more administration of tasks > than really doing them if I track such projects like the one described with > org-mode and create a sub-task for each step. > Especially as I'd have to re-type each time again the name of the project if > I want it to appear in my agenda explicitly and not only: > WAITING John: Feedback > (and I would not know which text it is about). Good news. With Bernt's setup you are off to a good start. Perhaps Properties will do what you want? These are inherited by sub-trees, so they will follow Task 1, Task 2, etc. * Topic XYZ :PROPERTIES: :CATEGORY: XYZ :END: ** DONE Task 1 ** TODO Task 2 The CATEGORY property shows up in my Agenda, so I would know that Task 2 belonged to XYZ. This is how I manage the dozen or so open work projects I have at any one time. We assign each project a number, which I put in the CATEGORY property. When I generate my daily agenda, I see the project number beside each TODO task. See Chapter 7 of the manual for details. hth, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
[O] FW: How to deal with small projects which are often changing their status/ person
> Von: M > Datum: Tue, 22 Jan 2013 23:22:59 +0100 > An: Thorsten Jolitz > Unterhaltung: [O] How to deal with small projects which are often changing > their status/ person > Betreff: Re: [O] How to deal with small projects which are often changing > their status/ person > > I agree, that sending edited documents by e-mail is not the best available > approach. > > Using Google Docs for partly confidential information concerning products of a > company is a no-go in my opinion (same for dropbox etc.) > > Maybe you misunderstood my initial question: > it is not about a tool to keep track of changes to the documents, but a way to > keep track of the project in MY todo-lists managed by org-mode. > > Some ideas I had in the meantime: > - creating templates for such projects which already contain the "standard" > sub-tasks. > > > > >> Von: Thorsten Jolitz >> Datum: Tue, 22 Jan 2013 22:55:15 +0100 >> An: >> Betreff: Re: [O] How to deal with small projects which are often changing >> their status/ person >> >> M writes: >> >>> it is not about programming and it is not about plain text files, but MS >>> Office (Word) files.. >>> >>> Dropbox is not an option, maybe a document management system (DMS) with >>> versioning, but it is not in place yet. >>> And even if there is, how could I then track my workflow with Emacs? >> >> Maybe I shouldn't say this on this list, but this actually sounds to me >> like a perfect use case for Google Docs, which is very similar to Word, >> can import and export to Word (or simply replace it if the Docs are not >> too complex), and is very well suited for collaborative work on the same >> documents with automatic backup in the clouds and versioning. >> >> I think its all about avoiding to work locally on different copies of a >> document and then send it back and forth by email. Thats just too >> old-school in my eyes. >> >> -- >> cheers, >> Thorsten >> >> -- Ende der weitergeleiteten Nachricht
Re: [O] How to deal with small projects which are often changing their status/ person
Hi Thomas, thanks for your reply! Sure I know Bernt Hansen's web page and I'm already using his configuration for my system. (I'm still learning Emacs and org-mode, so it was easier to start with an existing setup). I already know and use the capture and refile feature, my problem is that I have the feeling to do more administration of tasks than really doing them if I track such projects like the one described with org-mode and create a sub-task for each step. Especially as I'd have to re-type each time again the name of the project if I want it to appear in my agenda explicitly and not only: WAITING John: Feedback (and I would not know which text it is about). > Von: "Thomas S. Dye" > Datum: Tue, 22 Jan 2013 11:39:13 -1000 > An: M > Cc: emacs orgmode-mailinglist > Betreff: Re: How to deal with small projects which are often changing their > status/ person > > A terrific source of ideas about how to organize projects with Org mode > is Bernt Hansen's web page, http://doc.norang.ca/org-mode.html > > See especially his section 6 about adding tasks quickly with Capture.
Re: [O] Bug: `org-next-link' doesn't wrap around [7.9.3d (7.9.3d-GNU-Emacs-24-3 (commit e8f5b0ad) @ /usr/local/share/emacs/24.3.50/lisp/org/)]
Hi Xue, Xue Fuqiao writes: > The way to reproduce this bug: > emacs -Q test.org > C-c C-x C-p > > It doesn't wrap around. I don't understand what "wrap around" means exactly. Can you describe exactly how the commands should behave? Thanks, -- Bastien
Re: [O] How to deal with small projects which are often changing their status/ person
"Nicolas Richard" writes: > I use one trick which might be of interest to some people : when I have > a dropbox folder with text (in my case, these are .tex and related > files) files that will be worked on collaboratively, I first follow > these steps in the directory : > > dropbox exclude add .git > git init > git add . > git commit -m "Initial commit" > > (it is important that the first step comes first, this avoids the .git > directory from being synched to everyone sharing the folder) > > From that moment on, I can monitor changes using git diff which I find > much easier (in particular thank to magit) than Dropbox's own > facilities. Everytime there are new chages, I usually commit them in > order to have some history saved locally (though less complete than the > history in dropbox, since I probably won't commit after every single > change). Thats a nice way to enable Emacs/Org-mode/Magit users to work with fellows from the Microsoft universe - thanks for the tip. -- cheers, Thorsten
Re: [O] How to deal with small projects which are often changing their status/ person
M writes: > it is not about programming and it is not about plain text files, but MS > Office (Word) files.. > > Dropbox is not an option, maybe a document management system (DMS) with > versioning, but it is not in place yet. > And even if there is, how could I then track my workflow with Emacs? Maybe I shouldn't say this on this list, but this actually sounds to me like a perfect use case for Google Docs, which is very similar to Word, can import and export to Word (or simply replace it if the Docs are not too complex), and is very well suited for collaborative work on the same documents with automatic backup in the clouds and versioning. I think its all about avoiding to work locally on different copies of a document and then send it back and forth by email. Thats just too old-school in my eyes. -- cheers, Thorsten
[O] Bug in new exporter with babel blocks
Hello, I’m dealing with a puzzling bug in the new exporter. As background, I’ve written a custom function to process special-blocks, to replicate in the new exporter the functionality of the org-exp-blocks package (http://orgmode.org/worg/org-contrib/org-exp-blocks.html). Because I need the un-processed text inside the special-block (not parsed into an org-elements structure nor escaped for LaTeX special characters), I use the :contents-begin and -end properties of the element to extract this information. These values aren’t accurate in the presence of babel source blocks. In order to reproduce this, extract the attached elisp and org files into your home directory, adjust the paths to point to an up-to-date git checkout of the org sources (I am on today’s commit 196c579), and eval-buffer the lisp file in an emacs -Q (I am using an up-to-date trunk checkout of the meacs sources). Then look in the *Messages* buffer to see what follows “RESULT IS: “. It should be “bar”; I get something else (specifically “ 1)” from the middle of the babel block). Deleting the babel block from the org file and re-running the export call delivers the expected “RESULT IS: bar” message. (Note that the final output is correct because the test elisp falls back to the original definition of ‘org-e-latex-special-block’, but in my use the output is wrong because I rely on the result of the buffer-substring call.) I’m not sure if this is a long-standing problem or not; this is the first time I’ve combined babel with my custom special-blocks code. I’m also at a loss of how to debug the internals of org-elements and org-export, two complex bits of machinery. I guess the value of the :contents-begin and -end properties needs to be fixed in any case. I’d also be happy to discover another, better way of getting the raw text content of the special-block that doesn’t succumb to this problem. Thanks in advance, Aaron Ecay org-bug.el Description: application/emacs-lisp * Intro #+name: setup #+begin_src elisp :results output :exports both (+ 1 1) #+end_src foo #+begin_foo bar #+end_foo baz
Re: [O] Problem exporting code
Thorsten Jolitz writes: > I found a really nice alternative keymap here: > http://emacswiki.org/emacs/OutlineMinorMode Thanks -- but that's quite bigger than just using Org ;) -- Bastien
Re: [O] Problem exporting code
Hi Achim, Achim Gratz writes: > Bastien writes: >> So I'm seriously questioning the value of having Org as an ELPA >> package and I'm thinking of removing this possibility until Emacs >> package install is fixed (Achim is working on this, but it looks >> like the change will not be in Emacs anytime soon.) > > I've to admit that I've had that thought too, but it seems that doing > this would perhaps even lower the attention that Emacs' maintainers give > to that problem. This is using Org users as hostages, I don't want to do this. > Until they admit any change into Emacs we could still > work around with advising require and salvage the ELPA users (I still > think we should do it anyway since a number of users will keep using > older Emacs versions). Yes, it is a hairy hack. It is :) We should remove advices, not add other ones, especially if the hack hides a bigger problem for Emacs. I will ping the community at large to have a better idea on how such a change would affect the community. -- Bastien
Re: [O] How to deal with small projects which are often changing their status/ person
Thanks Thorsten for your reply! it is not about programming and it is not about plain text files, but MS Office (Word) files.. Dropbox is not an option, maybe a document management system (DMS) with versioning, but it is not in place yet. And even if there is, how could I then track my workflow with Emacs? Kind regards Martin > Von: Thorsten Jolitz > Datum: Tue, 22 Jan 2013 22:14:42 +0100 > An: > Betreff: Re: [O] How to deal with small projects which are often changing > their status/ person > > M writes: > > Hi, > >> At the moment there are many little projects where I >> >> * get a text from someone (or write it myself) >> * have to read and edit it >> * send it oer email to 1 or 2 other colleagues which have to read / edit it >> * get it back and check the changes >> * maybe send the text again to the original author >> * then finally release the text for publication >> >> ... and you imagine, there is not only 1 such text at once but several of >> them. >> >> I wonder what is an approriate way to keep track of such workflows with >> org-mode.. > > this doesn't sound so different from several programmers working on the > same source code file, so I suspect that GIT is the best and the most > popular solution for collaborative work on plain text files. > > If you/your fellow workers don't use GIT or another VCS, there is still > dropbox - put your project text files in your dropbox folder and share > them with other, there are automatic backups of older versions by > Dropbox. > > Or you wait for colorg to be released, that would probably fit your > needs exactly > > -- > cheers, > Thorsten > >
Re: [O] How to deal with small projects which are often changing their status/ person
Thorsten Jolitz writes: > If you/your fellow workers don't use GIT or another VCS, there is still > dropbox - put your project text files in your dropbox folder and share > them with other, there are automatic backups of older versions by > Dropbox. I use one trick which might be of interest to some people : when I have a dropbox folder with text (in my case, these are .tex and related files) files that will be worked on collaboratively, I first follow these steps in the directory : dropbox exclude add .git git init git add . git commit -m "Initial commit" (it is important that the first step comes first, this avoids the .git directory from being synched to everyone sharing the folder) >From that moment on, I can monitor changes using git diff which I find much easier (in particular thank to magit) than Dropbox's own facilities. Everytime there are new chages, I usually commit them in order to have some history saved locally (though less complete than the history in dropbox, since I probably won't commit after every single change). (As a side note : another way to use git + dropbox is to have your .git directory sync'd between your different computers, but I don't like this very much, and obviously this would be for a completely different purpose.) -- Nico.
Re: [O] How to deal with small projects which are often changing their status/ person
Aloha M, M writes: > Hi, > > I'm working with org-mode to document my work and to keep track of tasks and > projects. > > At the moment there are many little projects where I > > * get a text from someone (or write it myself) > * have to read and edit it > * send it oer email to 1 or 2 other colleagues which have to read / edit it > * get it back and check the changes > * maybe send the text again to the original author > * then finally release the text for publication > > ... and you imagine, there is not only 1 such text at once but several of > them. A terrific source of ideas about how to organize projects with Org mode is Bernt Hansen's web page, http://doc.norang.ca/org-mode.html See especially his section 6 about adding tasks quickly with Capture. I organize projects something like this, where the first level heading names the project and sub-headings are tasks or task groups for the project: * Topic XYZ ** DONE Create text ** WAITING Revisions by Colleague ABC ** TODO Finalize text ** TODO Submit text When something comes in via email, I quickly file it to refile.org, read other emails, etc. Then, when convenient, I go through refile.org and put things where they should go. Bernt's setup using ido makes it possible to get to Topic XYZ quickly, where the choices can be narrowed and the appropriate file location easily found. I try to discipline myself so a DEADLINE or SCHEDULE is always attached to a TODO item. It is easy for me to skip the weekly project review that the GTD approach recommends, and attaching DEADLINE and SCHEDULE means that fewer things fall through the cracks. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] inherited-tags problem in agenda
Hi Kiwon, Kiwon Um writes: > From the release_7.9.3, the inherited tags are incorrectly disappeared > from the agenda view. The inherited tags are not shown for the tasks > with DEADLINE in the agenda view. This is now fixed in the maint and master branches, it will be in Org 7.9.4 and most probably in Emacs 23.4. Thanks for reporting this! Best, -- Bastien
Re: [O] view only tags related topics
Hi, m.atef.rad...@cryptolab.net writes: > i could easily search for tags .. no problem there .. just i want to view > result that i searched for and hide others (see screen shot) result just > marked yellow .. i want to hide unwanted results .. thanks C-h v org-show-hierarchy-above RET HTH, -- Bastien
Re: [O] Org ELPA update broken?
Hi Alan, Alan L Tyree writes: > I suspect that this is not being updated properly. The latest version > shown by M-x list-packages is org-plus-contrib 20130114 It is updated every week. The current version is 20130121. HTH, -- Bastien
Re: [O] How to deal with small projects which are often changing their status/ person
M writes: Hi, > At the moment there are many little projects where I > > * get a text from someone (or write it myself) > * have to read and edit it > * send it oer email to 1 or 2 other colleagues which have to read / edit it > * get it back and check the changes > * maybe send the text again to the original author > * then finally release the text for publication > > ... and you imagine, there is not only 1 such text at once but several of > them. > > I wonder what is an approriate way to keep track of such workflows with > org-mode.. this doesn't sound so different from several programmers working on the same source code file, so I suspect that GIT is the best and the most popular solution for collaborative work on plain text files. If you/your fellow workers don't use GIT or another VCS, there is still dropbox - put your project text files in your dropbox folder and share them with other, there are automatic backups of older versions by Dropbox. Or you wait for colorg to be released, that would probably fit your needs exactly -- cheers, Thorsten
[O] How to deal with small projects which are often changing their status/ person
Hi, I'm working with org-mode to document my work and to keep track of tasks and projects. At the moment there are many little projects where I * get a text from someone (or write it myself) * have to read and edit it * send it oer email to 1 or 2 other colleagues which have to read / edit it * get it back and check the changes * maybe send the text again to the original author * then finally release the text for publication ... and you imagine, there is not only 1 such text at once but several of them. I wonder what is an approriate way to keep track of such workflows with org-mode.. I'm using MS Outlook for mails and so when I receive a mail, I store a hyperlink pointing to that mail in Outlook. For a process like the one above I would have a task * TODO Write Text about topic XY and send it to colleague(s)... then * WAIT Colleage(s): Feedback on Text about topic XY * TODO check feedback/changes of Colleagues and edit again, and send for approval * TODO send to original author * WAIT for Feedback of original author (if changes, repeat process above) * TODO send text to publishing colleague or similar... I hope it is clear what I mean, there are a lot of small steps and each time creating a new task takes much time and I have to copy the name of the "project" again and again... Maybe it would be better to add all the notes about the progress as notes in the Logbook and change the Heading of the task each time, but that also seems strange to me... Would there be a way to make the "children" inherit automatically a text from the project name, e. g. * Text about topic XY for publishing in ABC ** WAIT John: Feedback on Text about topic XY for publishing in ABC ** Send Text about topic XY for publishing in ABC to Ellen for approval ... in a way that " Text about topic XY for publishing in ABC" is filled in automatically by a placeholder? Or what is your way for tracking such workflows in org-mode? Kind regards Martin
Re: [O] org-caldav feedback
Torsten Wagner writes: > I did not had time to play with the different parameters. For now I simply > added all of them. > I guess it has to do either with the timezone or with the daylight settings. > Maybe you want to add this to a "How-to install for SOGo" as a workaround. I think I found a better solution. I pushed a change to org-caldav which allows to set org-icalendar-timezone to the string "UTC", which will put events using universal time. The server should then transpose it to the timezone you have set in your SOGo preferences. It works for me (for SOGo, mind you; other calendar servers don't work well with that). > One problem remain. If I change something in the caldav calendar, the time > information in org get lost completely. > E.g. > * Meeting <2013-01-16 Wed 14:00> > becomes > * Meeting > It subsitutes the right entry and hence I believe it gets the ID stuff right. > However, it seems to have trouble to interpret the time information right (and > ignore them?). > If there is a way to help you debugging this please let me know. My test suite runs fine with the SOGo server, so I'm guessing it has to do with how you format your entries. Does this also happen when you put the timestamp underneath the heading? On a general note, I find manipulating Org entries rather delicate and wonder why there are no helper functions to change things like headings, timestamps, etc., which take care of the multitude of possibilities how entries can be formatted. My guess is that org-elements might be the solution for this, but I haven't looked at it yet... -David
Re: [O] Problem exporting code
Bastien writes: Hi Bastien, >> Why do you consider outline(-minor-mode) as completely unusable? > > Because of the keybindings. I found a really nice alternative keymap here: http://emacswiki.org/emacs/OutlineMinorMode ,-- | ; Outline-minor-mode key map | (define-prefix-command 'cm-map nil "Outline-") | ; HIDE | (define-key cm-map "q" 'hide-sublevels); Hide everything but the top-level headings | (define-key cm-map "t" 'hide-body) ; Hide everything but headings (all body lines) | (define-key cm-map "o" 'hide-other); Hide other branches | (define-key cm-map "c" 'hide-entry); Hide this entry's body | (define-key cm-map "l" 'hide-leaves) ; Hide body lines in this entry and sub-entries | (define-key cm-map "d" 'hide-subtree) ; Hide everything in this entry and sub-entries | ; SHOW | (define-key cm-map "a" 'show-all) ; Show (expand) everything | (define-key cm-map "e" 'show-entry); Show this heading's body | (define-key cm-map "i" 'show-children) ; Show this heading's immediate child sub-headings | (define-key cm-map "k" 'show-branches) ; Show all sub-headings under this heading | (define-key cm-map "s" 'show-subtree) ; Show (expand) everything in this heading & below | ; MOVE | (define-key cm-map "u" 'outline-up-heading); Up | (define-key cm-map "n" 'outline-next-visible-heading) ; Next | (define-key cm-map "p" 'outline-previous-visible-heading) ; Previous | (define-key cm-map "f" 'outline-forward-same-level); Forward - same level | (define-key cm-map "b" 'outline-backward-same-level) ; Backward - same level | (global-set-key "\M-o" cm-map) `-- -- cheers, Thorsten
Re: [O] Problem exporting code
Achim Gratz writes: > Thomas S. Dye writes: >> Interesting, this Emacs distribution removed Org a few days ago. I'm not >> certain why the distributor refers to this as "a rather drastic >> measure." From my perspective as a user, whose interests required using >> the git version of Org from the beginning, the Emacs distribution of Org >> has been nothing but trouble, leading to perplexing (for me) problems >> with mixed installs that I would rather have avoided. > > That's not an entirely fair thing to say. Using an Emacs with a built-in > Org version just makes some problems more prominent that maybe you got > away with in the past. Apologies if I was unfair. I just don't know (perhaps out of ignorance) how the Org that ships with Emacs has been a benefit to me. I think you and I have different definitions of "problem". From my user's perspective, something I "get away with," i.e., that doesn't have an effect on my work and productivity, isn't a problem. BTW, it was your build system that helped me recognize I had a mixed install, so I could finally squash some bugs that had pestered and perplexed me for a long time. What a relief that was! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Problem exporting code
Bastien writes: > So I'm seriously questioning the value of having Org as an ELPA > package and I'm thinking of removing this possibility until Emacs > package install is fixed (Achim is working on this, but it looks > like the change will not be in Emacs anytime soon.) I've to admit that I've had that thought too, but it seems that doing this would perhaps even lower the attention that Emacs' maintainers give to that problem. Until they admit any change into Emacs we could still work around with advising require and salvage the ELPA users (I still think we should do it anyway since a number of users will keep using older Emacs versions). Yes, it is a hairy hack. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Problem exporting code
Thomas S. Dye writes: > Interesting, this Emacs distribution removed Org a few days ago. I'm not > certain why the distributor refers to this as "a rather drastic > measure." From my perspective as a user, whose interests required using > the git version of Org from the beginning, the Emacs distribution of Org > has been nothing but trouble, leading to perplexing (for me) problems > with mixed installs that I would rather have avoided. That's not an entirely fair thing to say. Using an Emacs with a built-in Org version just makes some problems more prominent that maybe you got away with in the past. > Installation of the git version is *easy* now, even for someone with my > limited skills. I didn't have any luck with the ELPA version when it > first came out, but the ELPA system works great and it seems like an > ideal channel to distribute Org. So, even a user like me has very little > difficulty using a non-Emacs version of Org. Package manager, ELPA and the way it interacts with Emacs' built-in packages certainly needs some more work. Right now things might be a little more rough than everybody would like. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] commenting out a SCHEDULED line does not remove todo from agenda.
Am 22.01.2013 16:43, schrieb Bastien: > Hi Rainer and all, > > Rainer Stengele writes: > >> As my agenda was and is slow and only became faster after Bastiens >> optimisations lately I do not want to motivate changes which makes the >> agenda creation slower again. I am happy with setting a '#' at bol. > > I fixed this. The check is now done checking the text property > 'font-lock-comment-face which is the one for such lines. From the > tests I did, this is as fast as checking for the next character. > > Please have a go and let me know if this work. > > Best, > Bastien, thanks a lot, works as expected! Cheers, Rainer
Re: [O] Bug in org-agenda.el
Bastien writes: > Achim Gratz writes: >> Probably yes, although there are other variables that should probably be >> bound in this case (and maybe others). > > If you can think of some others, please let us know. The docstring of org-minutes-to-clocksum-string says: "Format number of minutes as a clocksum string. The format is determined by `org-time-clocksum-format', `org-time-clocksum-use-fractional' and `org-time-clocksum-fractional-format' and `org-time-clocksum-use-effort-durations'." so these are the obvious candidates. I'm not familiar enough with the inner workings of the agenda code to decide whether these customizations should be tzemporarily be disabled. The code that introduced them is relatively new, so the author(s) might know a bit more about that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] commenting out a SCHEDULED line does not remove todo from agenda.
Hi Rainer and all, Rainer Stengele writes: > As my agenda was and is slow and only became faster after Bastiens > optimisations lately I do not want to motivate changes which makes the > agenda creation slower again. I am happy with setting a '#' at bol. I fixed this. The check is now done checking the text property 'font-lock-comment-face which is the one for such lines. From the tests I did, this is as fast as checking for the next character. Please have a go and let me know if this work. Best, -- Bastien
Re: [O] org-caldav feedback
Hi David, great thanks a lot this solved the time shift problem. I did not had time to play with the different parameters. For now I simply added all of them. I guess it has to do either with the timezone or with the daylight settings. Maybe you want to add this to a "How-to install for SOGo" as a workaround. One problem remain. If I change something in the caldav calendar, the time information in org get lost completely. E.g. * Meeting <2013-01-16 Wed 14:00> becomes * Meeting It subsitutes the right entry and hence I believe it gets the ID stuff right. However, it seems to have trouble to interpret the time information right (and ignore them?). If there is a way to help you debugging this please let me know. Thanks again a lot Torsten (setq org-caldav-calendar-preamble > "BEGIN:VCALENDAR > PRODID:-//Inverse inc./SOGo 2.0.3a//EN > VERSION:2.0 > BEGIN:VTIMEZONE > TZID:Europe/Berlin > X-LIC-LOCATION:Europe/Berlin > 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 > ") > > If it works for you with such a timezone definition, it'd be interesting > to know if SOGo needs all of that or if you could drop most of this > stuff. > > -David >
Re: [O] Redmine backend for org-sync
Hi Daimrod, Daimrod writes: > It's far from complete but I plan to work on it. I mostly use github, so > it's most likely that I'll focus on its backend. > > [1] https://github.com/daimrod/org-sync Glad to know you work on this. Let us know when we can merge your changes in org-sync.git and advertize them wider! All best, -- Bastien
Re: [O] Bug: Table editor manual bug [7.9.3+ (7.9.3+-GNU-Emacs-24-3 (commit 4cac75153) @ /usr/local/share/emacs/24.2.92/lisp/org/)]
Xue Fuqiao writes: > Your bug report will be posted to the Org-mode mailing list. > > > In (info "(org) Built-in table editor"): > > `C-c C-c (`org-table-align')' > Re-align the table without moving the cursor. > > But it *does* move the cursor. I think it should be: > Re-align the table without moving the cursor to other fields. I don't think it is a real problem but I fixed it anyway. Please provide more constructive changes, I know you can! Thanks, -- Bastien
Re: [O] [PATCH] Small type correction
Samuel Loury writes: > This is a minor typo correction, Applied, thanks! -- Bastien
Re: [O] Bug in org-agenda.el
Hi Achim, Achim Gratz writes: > Probably yes, although there are other variables that should probably be > bound in this case (and maybe others). If you can think of some others, please let us know. Thanks, -- Bastien
Re: [O] Bug in org-agenda.el
Hi Vincent, Vincent Beffara writes: > I am afraid to change the code, so I just customized Com'on, don't be afraid! > org-time-clocksum-use-effort-durations to nil and everything works for > now. But presumably this should be fixed by letting it be nil while > formatting the end timestamp, somewhere near line 6404 of > org-agenda.el ? Yes, thanks. I fixed this in master. Best, -- Bastien
Re: [O] [PATCH] Re: #+PROPERTY documentation
Hi Daimrod, Daimrod writes: >> Thanks for your efforts! > > Is it better? Yes, close to perfect. As noted in the link I gave, you need to use `C-x 4 a' in the section of the manual you changed in order to create a proper ChangeLog. In your case, the ChangeLog should start like this: * org.texi (Property syntax, Buffer-wide header arguments): Also, please add only one such footnote. Having twice the same footnote is confusing for the readers -- if they remember "there is a footnote for this..." they will not be able to remember if it was the first or the second one. Choose the one that is the most important -- given that the information is already available in another section. > I'll also reformat my other patches. Thanks! -- Bastien
Re: [O] [bug] org-insert-link fails on special characters in headlines
Hi William, William Léchelle writes: > I'm getting plenty of awful > >> Invalid read syntax: ) > > even though I cannot be sure it's not just me not being able to > apply a patch. Mhh... I hope that's the case and that Samuel's patch is fine :) > I tried :') Yes, thanks! -- Bastien
Re: [O] Checklist bug in version 7.9.3a
Hi Robert, Robert Horn writes: > If you go to the first line in the list of check boxes, line "Use > Cases", and use "C-u C-u C-c C-c", it will set all of the checkboxes > in the list to partial "[-]". If you try it again you get the error > "user-error: Cannot toggle this checkbox (uncheccked subitems?)". Fixed in master, thanks. -- Bastien
Re: [O] [PATCH] Re: #+PROPERTY documentation
Bastien writes:
> Daimrod writes:
>
>> Here is a patch for this:
>
> Thanks. Please add a proper ChangeLog to it.
>
> See http://orgmode.org/worg/org-contribute.html#sec-5
Thanks.
> You also need to add TINYCHANGE at the bottom of the
> git commit message.
>
> Thanks for your efforts!
Is it better?
I'll also reformat my other patches.
From 4c71f10ecfdd8e44642cb18d27fe42a9b17fe1b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?=
Date: Mon, 21 Jan 2013 23:45:47 +0100
Subject: [PATCH] Documentation: Add footnotes to recall the user to refresh
the org buffer when settings are changed
* doc/org.texi: Add a footnote to the following sections:
- (info "(org) Property syntax")
- (info "(org) Buffer-wide header arguments")
TINYCHANGE
---
doc/org.texi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 61f1ee5..c2bdd58 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -4954,7 +4954,9 @@ publishers and the number of disks in a box like this:
@end example
If you want to set properties that can be inherited by any entry in a
-file, use a line like
+file, use a line like@footnote{As
+with all these in-buffer settings, pressing @kbd{C-c C-c} activates any
+changes in the line.}
@cindex property, _ALL
@cindex #+PROPERTY
@example
@@ -13252,7 +13254,9 @@ of @code{#+PROPERTY:} lines placed anywhere in an Org mode file (see
For example the following would set @code{session} to @code{*R*}, and
@code{results} to @code{silent} for every code block in the buffer, ensuring
that all execution took place in the same session, and no results would be
-inserted into the buffer.
+inserted into the buffer.@footnote{As
+with all these in-buffer settings, pressing @kbd{C-c C-c} activates any
+changes in the line.}
@example
#+PROPERTY: session *R*
--
1.7.10.4
--
Daimrod/Greg
pgp9K8GOyUhnU.pgp
Description: PGP signature
Re: [O] [PATCH] Re: #+PROPERTY documentation
Daimrod writes: > Here is a patch for this: Thanks. Please add a proper ChangeLog to it. See http://orgmode.org/worg/org-contribute.html#sec-5 You also need to add TINYCHANGE at the bottom of the git commit message. Thanks for your efforts! -- Bastien
Re: [O] [PATCH] Bug fix: delete indirect buffer's window only when it exists.
Hi Muchenxuan, Muchenxuan Tong writes: > Thanks for pointing out. It's my fault, when-let is defined in slime.el > and not the Emacs core library. > > The following patch should be OK: I've applied the patch. Please do not insert patches in the body of the message, attach them. Also, you can use git format-patch to send them, it's easier for me to apply. Thanks, -- Bastien
Re: [O] [PATCH] Bug fix: delete indirect buffer's window only when it exists.
Ok. Thanks. On 22 Jan 2013, at 21:25, Bastien wrote: > Hi Muchenxuan, > > Muchenxuan Tong writes: > >> Thanks for pointing out. It's my fault, when-let is defined in slime.el >> and not the Emacs core library. >> >> The following patch should be OK: > > I've applied the patch. Please do not insert patches in the body of > the message, attach them. Also, you can use git format-patch to send > them, it's easier for me to apply. > > Thanks, > > -- > Bastien
Re: [O] #+PROPERTY documentation
Hi Daimrod, Daimrod writes: > Ok, I've already sent an assignment request for another patch and it > should be confirmed by the end of the week. Don't be too optimistic, it takes usually longer, at least three weeks. You can still send patches, we will apply them when the FSF confirmed your assignment is processed. This leaves a window for discussing the change, if needed. Thanks for your contributions! -- Bastien
Re: [O] #+PROPERTY documentation
Achim Gratz writes: > Nick Dokos writes: >> I believe that just as with code changes, doc changes also need FSF >> copyright assignment. > > The FSF owns the copyright to all of Org, including the > documentation. More precisely, the FSF owns the copyright of GNU Emacs, and assignments are signed but the contributors for contributions to GNU Emacs. Since Org is part of GNU Emacs, the FSF owns the copyright for the Org manual that is part of GNU Emacs. It does not own the copyright for changes that are ahead of GNU Emacs and not yet merged. But we ask contributors to proceed with the assignment ahead of the merge, that's easier. > So yes, anything over 20 lines non-trivial chnages needs to be assigned > to FSF. Indeed. -- Bastien
Re: [O] Problem exporting code
Hi Ken, Ken Williams writes: > I also wrote to him and suggested he remove the (require > 'org-install) statement from his default.el, because it was causing > warnings for people who upgrade org. Indeed. I've removed the warning from the maint/master branches, the file will be silently loaded if people still have (require 'org-install) in their config. > Perhaps it would be better to change it to a conditional on the > version number? Ideally yes, but relying on version numbers supposes that the distribution correctly have an org-version.el file. Since I don't know how Vincent package Org in this distro, it's not safe to rely on this. I'm waiting for his answer and report progress, if any. -- Bastien
Re: [O] Problem exporting code
On Tue, Jan 22, 2013 at 1:49 AM, Bastien wrote: > Hi Thomas and all, > > t...@tsdye.com (Thomas S. Dye) writes: > > > Ken Williams writes: > > > >>> I've been using this: > >>> - http://vgoulet.act.ulaval.ca/en/emacs/mac/ > > Thanks for the pointer, I was not aware of this distribution. > > > Interesting, this Emacs distribution removed Org a few days ago. > > This is a wrong move. Also, the NEWS entry in > http://vgoulet.act.ulaval.ca/pub/emacs/NEWS-mac suggests that Org's > maintainers are recommending to install Org as an external package, > which is a false statement too. > > I just wrote to Vincent asking for more details and offering to help > to ease his life as a maintainer for this Emacs distribution. > I also wrote to him and suggested he remove the (require 'org-install) statement from his default.el, because it was causing warnings for people who upgrade org. Perhaps it would be better to change it to a conditional on the version number? -Ken
Re: [O] Problem exporting code
Bastien writes: Hi Bastien, >> I'm asking just out of curiosity, and to learn a bit more, there are >> no urgent problems to be solved on my side here. > > You're welcome! Thanks for the answer, so there is not really a fundamental problem with outline-minor-mode nor is it difficult to replace it with org-struct. -- cheers, Thorsten
[O] ICS-export and Google Calendar: tags/CATEGORIES not imported
Hi! My Org-mode export generates entries like this one: BEGIN:VEVENT UID: TS-a79f58e8-127e-485d-813b-d81c46f70c9e DTSTART:20121205T163000 DTEND:20121205T18 SUMMARY:This is the event DESCRIPTION: Here goes the first parts of the notes/content CATEGORIES:@town,misc END:VEVENT I would like to use/read the CATEGORIES (@town and misc - corresponding to the list of tags) in Google Calendar. I want to use it on my Android devices, to be precise. In my online Google Calendar I do not see anything about those categories. On my Android devices either. I supposed that Google does not support this field. However, I could only find [1] with an description of the Google Calendar supported format. Quite unspecific IMHO. Is there someone facing the same issue? 1. https://support.google.com/calendar/bin/answer.py?hl=en&answer=45664 -- Karl Voit
Re: [O] Problem exporting code
Hi Thorsten, Let's assume that you don't use ELPA for installing Org. When installing a recent Org, either from an archive or from a git clone, you only need to add the correct load-path, as described in the manual -- for example: (add-to-list 'load-path "~/path/to/orgdir/lisp") > In this thread, I was told that I'm causing 'a future train wreck' with > my habit to simply trash the org folder from the Emacs installation and > replace it with a symlink to the git version in my home dir (I had > enough trouble with mixed installs, and this seems to avoid them - > having only the git version, no Elpa and no Emacs version). No train will die in your experiments. :) But removing Emacs Org is not necessary. > Now I was told there will be troubles with the autoloads, and I would > like to understand better what the possible implications are. I do 'make > autoloads' in the git version of org, so there is a loaddefs.el. There > is of course another loaddefs.el in the Emacs directory that is not > updated when I replace the Emacs org folder with a symlink to the > (slightly different) git version. The implication of removing Emacs Org is that some Org functions will still be autoloaded from Emacs loaddefs.el while the autoloads will not point to the correct, existing, directory. > Is there really 'big trouble' possible due to this? Should I run 'make > autoloads' in the Emacs installation directory again? No. You should just install Org as an archive or as a git clone, and add the correct load-path. If you forget to add the load-path, you will simply be using Org from Emacs, that's all. >> Also, I consider outline.el to be completely unusable, and Org is >> first an enhanced version of it, which Emacs strongly needs. I plan >> to push so that files in Emacs use org.el when they use outline.el. > > When I started with Emacs, I had one .emacs init-file that became more > and more chaotic over time (and a real pain for navigation and > maintainment). Then I started to use a multi-file set-up, first Elisp > files, then using .org files via the starter-kit. > > Now I know about M-x occur and recently discovered that > outline-minor-mode enables me to define my own outline-regexps in an .el > file, so I'm back to the start - using one big /.emacs.d/init.el, but > this time with all the outline functionality. > > Here is a short excerpt from the init.el, showing that my > outline-headings just look like outcommented org-headings: > > , > | ;; * Recovery from Problems > | > | ;; ** Debugging > | > | (when section-debugging (message "99 Debugging...") > | > | ... > | > | (message "99 Debugging... Done")) > | > | ;; Local Variables: > | ;; coding: utf-8 > | ;; mode: emacs-lisp > | ;; eval: (outline-minor-mode) > | ... > | ;; outline-regexp: ";; [*]+ " > | ;; End: > ` > > Except for the extraordinary weird key-bindings of outline-minor-mode > (e.g. C-c @ C-n), that I still did not manage to override (with the > usual Org-mode bindings), I'm very satisfied with this set-up, it gives > me the best of both worlds (full outline functionality and the very > simple and direct approach of having just one init.el). I simply use this: (add-hook 'emacs-lisp-mode-hook 'orgstruct-mode) (global-set-key (kbd "C-M-]") (lambda () (interactive) (org-cycle t))) (global-set-key (kbd "M-]") (lambda () (interactive) (ignore-errors (end-of-defun) (beginning-of-defun)) (org-cycle))) C-M-] and M-] fold the whole buffer or the current defun. > Why do you consider outline(-minor-mode) as completely unusable? Because of the keybindings. > And how > would you replace it in my use case with org(-struct?)? See above. > I'm asking just > out of curiosity, and to learn a bit more, there are no urgent problems > to be solved on my side here. You're welcome! -- Bastien
Re: [O] Problem exporting code
Bastien writes:
Hi Bastien,
your post touches two topics that I'm currently dealing with, so here
are two questions with regards to this topics:
(1)
>> I'm not certain why the distributor refers to this as "a rather
>> drastic measure." From my perspective as a user, whose interests
>> required using the git version of Org from the beginning, the Emacs
>> distribution of Org has been nothing but trouble, leading to
>> perplexing (for me) problems with mixed installs that I would rather
>> have avoided.
>
> The distribution of Org as a built-in package in Emacs is *not* the
> problem.
>
> Installing Org through git or through .tar.gz/.zip on top of the Emacs
> distribution does not create problems if you follow the instructions
> in the manual -- I made a special effort to simplify them.
I recently experienced some casual trouble when updating Org-mode from
Git (I simply updated at a moment, when actual org.el wouldn't load due to a
bug that was to be fixed soon fixed soon. Here is the related thread on
the mailing list:
[[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87ehhmnqu6@googlemail.com][Email
from Thorsten Jolitz: Re: {BUG} `org-load-noerror-m]]
In this thread, I was told that I'm causing 'a future train wreck' with
my habit to simply trash the org folder from the Emacs installation and
replace it with a symlink to the git version in my home dir (I had
enough trouble with mixed installs, and this seems to avoid them -
having only the git version, no Elpa and no Emacs version).
Now I was told there will be troubles with the autoloads, and I would
like to understand better what the possible implications are. I do 'make
autoloads' in the git version of org, so there is a loaddefs.el. There
is of course another loaddefs.el in the Emacs directory that is not
updated when I replace the Emacs org folder with a symlink to the
(slightly different) git version.
Is there really 'big trouble' possible due to this? Should I run 'make
autoloads' in the Emacs installation directory again?
(2)
> Also, I consider outline.el to be completely unusable, and Org is
> first an enhanced version of it, which Emacs strongly needs. I plan
> to push so that files in Emacs use org.el when they use outline.el.
When I started with Emacs, I had one .emacs init-file that became more
and more chaotic over time (and a real pain for navigation and
maintainment). Then I started to use a multi-file set-up, first Elisp
files, then using .org files via the starter-kit.
Now I know about M-x occur and recently discovered that
outline-minor-mode enables me to define my own outline-regexps in an .el
file, so I'm back to the start - using one big /.emacs.d/init.el, but
this time with all the outline functionality.
Here is a short excerpt from the init.el, showing that my
outline-headings just look like outcommented org-headings:
,
| ;; * Recovery from Problems
|
| ;; ** Debugging
|
| (when section-debugging (message "99 Debugging...")
|
| ...
|
| (message "99 Debugging... Done"))
|
| ;; Local Variables:
| ;; coding: utf-8
| ;; mode: emacs-lisp
| ;; eval: (outline-minor-mode)
| ...
| ;; outline-regexp: ";; [*]+ "
| ;; End:
`
Except for the extraordinary weird key-bindings of outline-minor-mode
(e.g. C-c @ C-n), that I still did not manage to override (with the
usual Org-mode bindings), I'm very satisfied with this set-up, it gives
me the best of both worlds (full outline functionality and the very
simple and direct approach of having just one init.el).
Why do you consider outline(-minor-mode) as completely unusable? And how
would you replace it in my use case with org(-struct?)? I'm asking just
out of curiosity, and to learn a bit more, there are no urgent problems
to be solved on my side here.
--
cheers,
Thorsten
Re: [O] #+PROPERTY documentation
Nick Dokos writes: > Daimrod wrote: > >> John Hendy writes: >> >> > On Mon, Jan 21, 2013 at 12:41 PM, Daimrod wrote: >> >> Hi, >> >> >> >> It would be nice if the documentation mentioned the need to reparse the >> >> org buffer with `C-c C-c' when a property is set with #+PROPERTY. >> >> (info "(org) Property syntax") >> > >> > As in adding to the header arguments? Yeah, probably wouldn't hurt, >> > though it is, as stated below, documented that *any* change to the >> > header arguments requires C-c C-c. >> > >> > On a side note, is there the possibility for "normal" users to submit >> > git based changes to the manual? I know how to do this for Worg, but >> > I'd be happy to update stuff in the manual, too, when I catch them. >> > These sorts of things could be tweaked by the finder and it would save >> > the maintenance team a bit -- just scan the commit and notes for >> > rationale and accept. >> >> Sure, one can modify the file doc/org.texi. And you're right, I should >> have submit a patch. >> > > I believe that just as with code changes, doc changes also need FSF > copyright assignment. Ok, I've already sent an assignment request for another patch and it should be confirmed by the end of the week. > Nick -- Daimrod/Greg pgpKUC7Fa73Fv.pgp Description: PGP signature
