[O] Hiding "future" tasks in tags-todo agenda view

2011-10-14 Thread Neilen Marais
Hi,

I've recently switched from using tracks (http://getontracks.org/) to
org mode for GTD task management. One neat tracks feature that I am
struggling to reproduce is the "show task from date". If you add a
task with no date set, they show up immediately in the context next
action lists, but if you have a "show from" date in the future, it
only shows the task from that date onwards.

Scheduling timestamps (http://orgmode.org/worg/org-faq.html#sec-16-9)
seem like they should do exactly that, but they don't seem to work in
my custom org-agenda that I use to show only items with a NEXT todo
state and an assigned context. However, it shows all items
irrespective of the scheduling setting. 

(setq org-agenda-custom-commands
  '(
("c" "Context Next Tasks" 
 tags-todo (mapconcat 'car my-org-context-tag-alist "|")
 ((org-agenda-skip-function '(org-agenda-skip-entry-if 
  'nottodo '("NEXT")))
  (org-agenda-sorting-strategy '(tag-up))
  (org-agenda-overriding-header "Context Next Tasks")
  ))
))

How can I make this custom agenda skip items that are scheduled in the
future, while also keeping unscheduled tasks? I have also tried adding 
  (org-agenda-entry-types '(:scheduled))
but that did not seem to make any difference.




Re: [O] Column view capture specific parts only

2011-10-14 Thread Johnny
Giovanni Ridolfi  writes:

> Johnny  writes:
>
>> I have a nice outline set up in column view and would like to capture
>> different versions of this into org-tables. 
>
> A case-study org file would have helped here. :-(

Sorry, my bad. I attach an example file below, based on your ideas, and
put a subheading with the desired result below the actual result. Hope
this clarifies a bit. :) 

* Outline structure
  :PROPERTIES:
  :COLUMNS:  %20ITEM %lead %review %approve
  :ID:   e48fa5a5-864b-46cd-a578-b88fe5f570be
  :END:

** Topic A
*** Subtopic 1
:PROPERTIES:
:lead: john
:review:   jane
:approve: jake
:END:

** Topic B
*** Subtopic 2
:PROPERTIES:
:approve: jim
:lead: kim
:review:   tim
:END:

* Capture outline structure

** Only lead showing
   :PROPERTIES:
   :COLUMNS:  %15ITEM %lead
   :END:
   #+BEGIN: columnview :hlines 1 :id e48fa5a5-864b-46cd-a578-b88fe5f570be
   | ITEM| lead | review | approve |
   |-+--++-|
   | * Outline structure |  || |
   | ** Topic A  |  || |
   | *** Subtopic 1  | john | jane   | jake|
   | ** Topic B  |  || |
   | *** Subtopic 2  | kim  | tim| jim |
   #+END

*** Desired result
   | ITEM| lead |
   |-+--|
   | * Outline structure |  |
   | ** Topic A  |  |
   | *** Subtopic 1  | john |
   | ** Topic B  |  |
   | *** Subtopic 2  | kim  |

** Only review showing
   :PROPERTIES:
   :COLUMNS:  %15ITEM %review
   :END:
   #+BEGIN: columnview :hlines 1 :id e48fa5a5-864b-46cd-a578-b88fe5f570be
   | ITEM| lead | review | approve |
   |-+--++-|
   | * Outline structure |  || |
   | ** Topic A  |  || |
   | *** Subtopic 1  | john | jane   | jake|
   | ** Topic B  |  || |
   | *** Subtopic 2  | kim  | tim| jim |
   #+END

*** Desired result
   | ITEM| review |
   |-+|
   | * Outline structure ||
   | ** Topic A  ||
   | *** Subtopic 1  | jane   |
   | ** Topic B  ||
   | *** Subtopic 2  | tim|

** Only approve showing
   :PROPERTIES:
   :COLUMNS:  %15ITEM %approve
   :END:
   #+BEGIN: columnview :hlines 1 :id e48fa5a5-864b-46cd-a578-b88fe5f570be
   | ITEM| lead | review | approve |
   |-+--++-|
   | * Outline structure |  || |
   | ** Topic A  |  || |
   | *** Subtopic 1  | john | jane   | jake|
   | ** Topic B  |  || |
   | *** Subtopic 2  | kim  | tim| jim |
   #+END

*** Desired result
   | ITEM| approve |
   |-+-|
   | * Outline structure | |
   | ** Topic A  | |
   | *** Subtopic 1  | jake|
   | ** Topic B  | |
   | *** Subtopic 2  | jim |


-- 
Johnny


Re: [O] Recursive org-agenda-files

2011-10-14 Thread Neilen Marais
Matthew,

Matthew Sauer  gmail.com> writes:

> 
> My understanding is that you want a file that gets moved into the
> active directory to be automatically included in the agenda?
> From worg:
> You can simply include the directory (as one of the items) in the
> value of the variable org-agenda-files:
> 
> (setq org-agenda-files '("/my/special/path/org/active/"))

Thanks for the suggestion. Tried it already and found that it is unfortunately 
not recursive. I tend to make directories with projects under the active 
directory, then put the org file and supporting files in the directory. E.g.

active/proj1/proj1.org
active/prof1/info.pdf 

etc

What's nice about this is that my project notes, todos and support files are 
close to each other. Also, I can simply use the dired listing of the active dir 
as my "active projects list" in GTD parlance :)
>  Not that playing with agenda hooks might have some advantages.

I have indeed cooked up a hooky solution that should have hit the list by the 
time you read this :)

Cheers
Neilen




Re: [O] Recursive org-agenda-files

2011-10-14 Thread Neilen Marais
Hi Nick,

Nick Dokos  hp.com> writes:

> Seek and ye shall find:
> 
> C-h v org-agenda--hook RET
> 
> will list all the matching hooks. Which one to choose? I'll leave that up
> to the interested reader

Indeed, doing 

(load-library "find-lisp")

(add-hook 'org-agenda-mode-hook (lambda () 
(setq org-agenda-files 
  (find-lisp-find-files "~/Dropbox/GTD/ActiveProjects" "\.org$"))
))

fixes it good. Fantastic, thanks!

Cheers
Neilen




Re: [O] property values and timestamps

2011-10-14 Thread Skip Collins
> Still a proof-of-concept, but better than the first attempt - set
> recursive minibuffers locally and use the standard keybinding:

That was easy. I'm looking forward to this making its way into the
main repository. Where else would a recursive minibuffer make sense?
How about putting links into properties. Or timestamps into links. Or
timestamps into capture fields. The possibilities are endless :-)

Thanks.



Re: [O] property values and timestamps

2011-10-14 Thread Nick Dokos
Nick Dokos  wrote:

> Skip Collins  wrote:
> 
> > > org-time-stamp-inactive uses the minibuffer, and calling
> > > a function that uses the minibuffer *from* the minibuffer (as
> > > org-set-property would do) make emacs unhappy.
> > 
> > Elisp does seem to allow recursive minibuffers:
> > http://www.gnu.org/software/emacs/elisp/html_node/Recursive-Mini.html
> > 
> > Would the implementation of this for org-set-property be straightforward?
> > 
> 
> Oh, very nice: I didn't know about that. Here's a proof-of-concept
> snippet, redefining the org-completing-read function to bind
> org-time-stamp-inactive to a key ("!" in the following, but you will
> probably want to season to taste):
> 
> (setq enable-recursive-minibuffers t)
> 
> (defun org-completing-read (&rest args)
>   "Completing-read with SPACE being a normal character."
>   (let ((minibuffer-local-completion-map
>(copy-keymap minibuffer-local-completion-map)))
> (org-defkey minibuffer-local-completion-map " " 'self-insert-command)
> (org-defkey minibuffer-local-completion-map "?" 'self-insert-command)
> (org-defkey minibuffer-local-completion-map "!" 'org-time-stamp-inactive)
> (apply 'org-icompleting-read args)))
> 
> It even seems to work!-)
> 

Still a proof-of-concept, but better than the first attempt - set
recursive minibuffers locally and use the standard keybinding:

--8<---cut here---start->8---
(defun org-completing-read (&rest args)
  "Completing-read with SPACE being a normal character."
  (let ((minibuffer-local-completion-map
 (copy-keymap minibuffer-local-completion-map))
(enable-recursive-minibuffers t))
(org-defkey minibuffer-local-completion-map " " 'self-insert-command)
(org-defkey minibuffer-local-completion-map "?" 'self-insert-command)
(org-defkey minibuffer-local-completion-map (kbd "C-c !") 
'org-time-stamp-inactive)
(apply 'org-icompleting-read args)))
--8<---cut here---end--->8---

Nick



Re: [O] property values and timestamps

2011-10-14 Thread Nick Dokos
Skip Collins  wrote:

> > org-time-stamp-inactive uses the minibuffer, and calling
> > a function that uses the minibuffer *from* the minibuffer (as
> > org-set-property would do) make emacs unhappy.
> 
> Elisp does seem to allow recursive minibuffers:
> http://www.gnu.org/software/emacs/elisp/html_node/Recursive-Mini.html
> 
> Would the implementation of this for org-set-property be straightforward?
> 

Oh, very nice: I didn't know about that. Here's a proof-of-concept
snippet, redefining the org-completing-read function to bind
org-time-stamp-inactive to a key ("!" in the following, but you will
probably want to season to taste):

--8<---cut here---start->8---
(setq enable-recursive-minibuffers t)

(defun org-completing-read (&rest args)
  "Completing-read with SPACE being a normal character."
  (let ((minibuffer-local-completion-map
 (copy-keymap minibuffer-local-completion-map)))
(org-defkey minibuffer-local-completion-map " " 'self-insert-command)
(org-defkey minibuffer-local-completion-map "?" 'self-insert-command)
(org-defkey minibuffer-local-completion-map "!" 'org-time-stamp-inactive)
(apply 'org-icompleting-read args)))
--8<---cut here---end--->8---

It even seems to work!-)

Thanks,
Nick



Re: [O] property values and timestamps

2011-10-14 Thread Skip Collins
> org-time-stamp-inactive uses the minibuffer, and calling
> a function that uses the minibuffer *from* the minibuffer (as
> org-set-property would do) make emacs unhappy.

Elisp does seem to allow recursive minibuffers:
http://www.gnu.org/software/emacs/elisp/html_node/Recursive-Mini.html

Would the implementation of this for org-set-property be straightforward?



Re: [O] `f' in agenda view

2011-10-14 Thread Rainer Stengele
Am 13.10.2011 15:59, schrieb Dave Abrahams:
> 
> on Thu Oct 13 2011, Rainer Stengele  wrote:
> 
>> Am 13.10.2011 10:47, schrieb Rainer Stengele:
>>
>>> Me too I sometimes run into this situation where I just want to
>>> shift past-dated items to today.
>>> I never had a use case where I wanted to shift an item from "past" to 
>>> "past+n-days>> Rainer
>>>
>> Well, as indicated somewhere else a "C-c C-s +1" for shifting to tomorrow or 
>> "C-c C-s ."
>> for shifting to today does exactly what I wanted.
>> "The power is in the house" already.
> 
> Yeah, it's just a question of having to think absolutely when you want
> to think incrementally.  That's a lot of keystrokes when what I want is
> to hit `f' (or something) 3 times to move the items to three days from
> now.
> 

Having bound
F3 to kmacro-start-macro-or-insert-counter
F4 kmacro-end-or-call-macro

for the first entry in the agenda I want to shift
forward 3 days I enter

F3 C-c C-s +3  F4

for each following entry I put point in the line and press F4

for 3 items that makes a total of 8+2=10 keypresses
for 4 items that makes a total of 8+3=11 keypresses
etc.

Best,
Rainer



Re: [O] No updates on git server?

2011-10-14 Thread Eric Schulte
Hi Rainer,

I pull from the orgmode.org git server (which I believe is preferred
over the repo.or.cz server) and the last commit I see if from Monday so
I believe there simply hasn't been any new commits in the last few days.

Best -- Eric

Rainer M Krug  writes:

> Hi
>
> I am updating from git daily (from git://repo.or.cz/org-mode.git) , but
> haven't received any updates during the last two days - is there a problem
> or has org reached a stable state?
>
> Rainer

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] LaTeX export crashes

2011-10-14 Thread Sebastien Vauban
Hi Ken,

Ken Williams wrote:
> Hi, the following document makes a LaTeX export (C-c C-e d) crash with "Args
> out of range: "", -1, 0". After that,
>
> --
> #+TITLE: Test doc
> #+AUTHOR: Ken Williams
>
> Some stuff.
>
> #+begin_src R
> 5+5
> #+end_src
> --
>
> Is this a known problem?

Works for me, with Org-mode version 7.7 (release_7.7.381.ge8629.dirty).

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Can not export to LaTeX anymore

2011-10-14 Thread daniel



Hi, 

I face a similar problem with my org-mode. So several months my
org-mode installation won't export to LaTeX and as I noticed today the
export of a project with org-jekyll etc. doesn't work either (but I do
not cover that error in this post):

- GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1)\n of 2011-03-04 
on allspice, modified by Debian

- I installed org-mode via a git repository in my home directory and put
  the following lines in my .emacs file:

  (setq load-path (cons "/home/dbr/sw/org-mode/lisp" load-path))
  (setq load-path (cons "/home/dbr/sw/org-mode/contrib/lisp" load-path))
  (require 'org-install)

- Therefore org-version is: Org-mode version 7.7 (release_7.7.380.g54d7df.dirty)

I then created a file "a.org":

--8<--
#+TITLE: a.org
#+AUTHOR:Daniel 
#+EMAIL: daniel@monkey
#+DATE:  2011-10-14 Fr
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 
path:http://orgmode.org/org-info.js
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:   
#+LINK_HOME: 
#+XSLT:

* Heading 

Export me !
--8<--
The options have been included with C-c C-e t.

After a org-export-as-latex I got the message: 

org-export-preprocess-string: Cannot open load file: org-nil

The *Backtrace* is:

--8<--
Debugger entered--Lisp error: (file-error "Cannot open load file" "org-nil")
  require(org-nil nil)
  org-export-preprocess-string(#("#+TITLE: a.org\n#+AUTHOR:
Daniel\n#+EMAIL: daniel@monkey\n#+DATE:  2011-10-14 
Fr\n#+DESCRIPTION:\n#+KEYWORDS:\n#+LANGUAGE:  en\n#+OPTIONS:   H:3 num:t toc:t 
\\n:nil @:t ::t |:t ^:t -:t f:t *:t <:t\n#+OPTIONS:   TeX:t LaTeX:t skip:nil 
d:nil todo:t pri:nil tags:not-in-toc\n#+INFOJS_OPT: view:nil toc:nil ltoc:t 
mouse:underline buttons:0 
path:http://orgmode.org/org-info.js\n#+EXPORT_SELECT_TAGS: 
export\n#+EXPORT_EXCLUDE_TAGS: noexport\n#+LINK_UP:   \n#+LINK_HOME: 
\n#+XSLT:\n\n" 0 8 (fontified nil font-lock-fontified t) 8 13 (fontified nil) 
13 18 (fontified nil font-lock-fontified t) 18 19 (fontified nil 
font-lock-fontified t) 19 28 (fontified nil font-lock-fontified t) 28 32 
(fontified nil font-lock-fontified t) 32 38 (fontified nil font-lock-fontified 
t) 38 39 (fontified nil) 39 47 (fontified nil font-lock-fontified t) 47 52 
(fontified nil) 52 65 (fontified nil font-lock-fontified t) 65 66 (fontified 
nil) 66 73 (fontified nil font-lock-fontified t) 73 79 (fontified nil) 79 92 
(fontified nil font-lock-fontified t) 92 93 (fontified nil) 93 107 (fontified 
nil font-lock-fontified t) 107 108 (fontified nil font-lock-fontified t) 108 
119 (fontified nil font-lock-fontified t) 119 120 (fontified nil 
font-lock-fontified t) 120 135 (fontified nil font-lock-fontified t) 135 136 
(fontified nil font-lock-fontified t) 136 203 (fontified nil 
font-lock-fontified t) 203 204 (fontified nil font-lock-fontified t) 204 276 
(fontified nil font-lock-fontified t) 276 277 (fontified nil 
font-lock-fontified t) 277 346 (fontified nil font-lock-fontified t) 346 375 
(fontified nil font-lock-fontified t) 375 376 (fontified nil rear-nonsticky 
(mouse-face highlight keymap invisible intangible help-echo org-linked-text) 
font-lock-fontified t) 376 377 (fontified nil font-lock-fontified t) 377 405 
(fontified nil font-lock-fontified t) 405 406 (fontified nil 
font-lock-fontified t) 406 437 (fontified nil font-lock-fontified t) 437 438 
(fontified nil font-lock-fontified t) 438 451 (fontified nil 
font-lock-fontified t) 451 452 (fontified nil font-lock-fontified t) 452 465 
(fontified nil font-lock-fontified t) 465 466 (fontified nil 
font-lock-fontified t) 466 473 (fontified nil font-lock-fontified t) 473 474 
(fontified nil font-lock-fontified t) 474 475 (fontified nil)) :for-LaTeX t 
:emph-multiline t :add-text nil :comments nil :skip-before-1st-heading nil 
:LaTeX-fragments nil :timestamps t :footnotes t)
  org-export-latex-first-lines((:latex-image-options "width=10em" :exclude-tags 
("noexport") :select-tags ("export") :publishing-directory nil :timestamp nil 
:expand-quoted-html t :html-table-tag "" :xml-declaration (("html" 
. "") ("php" . "\"; ?>")) :html-postamble auto 
:html-preamble t :html-extension "html" :inline-images maybe :convert-org-links 
t :agenda-style "" :style-extra "" :style "" :style-include-scripts t 
:style-include-default t :table-auto-headline t :tables t :time-stamp-file t 
:creator-info t :email-info nil :author-info t :email "daniel@monkey" ...) nil)
  org-export-as-latex(nil)
  call-interactively(org-export-as-latex)
  org-export(nil)
  call-interactively(org-export nil nil)
--8<--

I read in an older post that there may be a problem with parts of the
old installation that is still "somewhere". But I installed the newest
version as written in the manual.


Kind regards,


Daniel 





Re: [O] How to get numbered lists (1), (2), … ?

2011-10-14 Thread Marius Hofert
Hi all,

I am quite impressed by this discussion, thanks a lot.
I am an org-mode user for just a couple of days, and an emacs user for four 
weeks today. Needless to say, I can't contribute anything useful to this 
discussion. 
The only thing(s) I would like to say is/are:
(1) If it is not too complicated from a technical point of view, I would 
strongly recommend to enable lists like (1), (2), etc.  I gave some reasons in 
one of my earlier e-mails in this thread. There are many more (from a 
typography point of view, but also from a technical point of view [e.g., if you 
have auto-pairing of parentheses enabled, it's just more convenient.]). 
(2) From a LaTeX point of view, I am sure the experts here (and I mean everyone 
in this thread except me) know the LaTeX package "enumitem". It gives the 
greatest flexibility of creating lists I know of and behaves better in many 
circumstances than other enumerate-like environments. So I can only recommend 
using this approach for making lists (in which way this is possible/desirable I 
can't tell since I'm not an org-mode expert).

I will certainly become a heavy org-mode user in the next months/years. Lists 
like (1), (2),... I would definitely use a lot.

Cheers,

Marius


On 2011-10-14, at 14:05 , Jambunathan K wrote:

> 
>>  What about letting go those two variables and create
>>  `org-list-bullet-types', which would be a list of strings like:
>> 
>>   '("-" "+" "*" "1." "1)" "(1)" "a." "a)" "A)" "A.")
>> 
>>  It would be hard-coded but every bullet type could be opt-in or
>>  opt-out via customize. The default value should be as short as
>>  possible like '("-" "+" "*" "1." "a.").
>> 
>>  I can work it out in a few days if we agree.
> 
> What percentage of users (OK, not percentage of users but numbers of
> users) you think will *actually* exercise the opt-in and opt-out
> configuration if provided?
> 
> If the number of hands raised is in single digits, I would assume that
> it is more of a niche feature and let go of it.
> 
> Is it psychologically very taxing to see 1. instead of a (1) in an Org
> buffer. Could it be so taxing that a user's productivity will be
> impacted by it?
> 
> Or 
> 
> Is it that more varieties of bullets is needed for creating "rich"
> deeply nested lists so that each level of the list can take on a
> different bullet for better differentiation.
> -- 





Re: [O] How to get numbered lists (1), (2), … ?

2011-10-14 Thread suvayu ali
Hi everyone,

On Fri, Oct 14, 2011 at 2:05 PM, Jambunathan K  wrote:
> Is it psychologically very taxing to see 1. instead of a (1) in an Org
> buffer. Could it be so taxing that a user's productivity will be
> impacted by it?
>

For my personal use I don't care much as long as there are
ordered/enumerated and unordered/plain lists to choose from, after all
only the exported file is for public consumption. :) However I
strongly feel _against_ the '*' syntax. Its too close to a headline.
It is also unusable if one chooses not to use indentation for the text
under a headline (e.g. below). I often prefer this as deeply nested
(say, level 4) headlines often start to run out of columns due to
wrapping.

** Heading

Some list
* list item 1
* list item 2

> Or
>
> Is it that more varieties of bullets is needed for creating "rich"
> deeply nested lists so that each level of the list can take on a
> different bullet for better differentiation.

This is pretty much the reason I switch list types. Something like:

1) some broad point
   + Case 1
 - comment on something of note
   + Case 2
2) another broad point

That said, I would probably use the customize option.

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] How to get numbered lists (1), (2), … ?

2011-10-14 Thread Carsten Dominik

On 14.10.2011, at 13:31, Nicolas Goaziou wrote:

> Hello,
> 
> Nick Dokos  writes:
> 
>> Marius Hofert  wrote:
>> 
>> 
>>> What do you mean by "better solution"? As far as I can tell, your
>>> approach is precisely what Suvayu pointed to.
>> 
>> No: what Suvayu pointed to can be done with the standard latex exporter,
>> so it would not require changes to org-list-generic-to-latex. Just add
>> something like this at the top of your org file:
>> 
>> #+LATEX: \renewcommand{\theenumi}{(\arabic{enumi})}
>> 
>> It's better in that it is simpler. There are drawbacks however: the
>> above produces lists like this:
>> 
>> (1). foo
>> (2). bar
>> 
>> with a period after the closing paren.
>> 
>>> Using your approach, of course much more is possible, please look at
>>> the create "enumitem" package with all its customizations.
>>> 
>> 
>> That is true: which one is "better" depends on one's requirements (both
>> the desired output and how much pain one is willing to suffer in order
>> to get there).
>> 
>>> But this approach is a no-go for me (at least at the moment) mainly
>>> due to the following reasons (please let me know if I'm wrong, I'm a
>>> total newbie to org-mode):
>> 
>>> 1) I have about 40 lists in one file. Having to put in special LaTeX
>>> commands is not an option (maybe on only has to type it in once, but
>>> then it can easily get overseen, e.g., when you move lists around and
>>> the one containing the LaTeX commands is not the first one in the
>>> document anymore)
>> 
>> That's no problem: the LATEX_HEADER line goes in once at the top
>> of the org file. You can move lists around at will.
>> 
>>> 2) org-mode is basically a "better" text-mode. I don't want to have
>>> LaTeX code in there if I print it as a .txt file.
>>> 
>>> Is there a solution without having to put #+LATEX_HEADER:
>>> \usepackage{enumerate} before each list? Can this be set anywhere in
>>> the preferences?
>>> 
>> 
>> You can customize the latex preamble that org adds to latex files to do
>> that. The disadvantage is that you get the modified preamble always.
>> See the org-export-latex-packages-alist variable for one way to do that.
>> 
>>> But I assume that I still have to put in lists in org-mode like this:
>>> 1.,2.,... or 1),2),... and can't put them in like this (1),(2),...?
>> 
>> Correct: that would require changes to org-list.el I think - but Nicolas
>> will have to say the final word on this. All the solutions so far work
>> by modifying the latex output only, not the way you enter the list into
>> the org file.
> 
> - On the Org part:
> 
>  I have nothing against (1) as item bullets, as it doesn't interfere
>  with any existing Org syntax.

That is not the only criterion.  Adding new syntax elements make more
ASCII sequences special.  The Org markup is a heuristic set of
special elements, and there is merrit in keeping it small.  We already
have more bullets and in particular numbered types - and so far
I have not seen a compelling reason to add more.

- Carsten

> I just think it shouldn't be available
>  by default (much like alphabetical ordered lists).
> 
>  The implementation isn't hard /per se/ (at least less changes are
>  required than implementing, for example, roman numbered lists), but
>  I also think there should be some cleanup with regards to item
>  bullets. So far, there is `org-plain-list-ordered-item-terminator' and
>  `org-alphabetical-lists' to tweak them. We should avoid adding a third
>  one.
> 
>  What about letting go those two variables and create
>  `org-list-bullet-types', which would be a list of strings like:
> 
>   '("-" "+" "*" "1." "1)" "(1)" "a." "a)" "A)" "A.")
> 
>  It would be hard-coded but every bullet type could be opt-in or
>  opt-out via customize. The default value should be as short as
>  possible like '("-" "+" "*" "1." "a.").
> 
>  I can work it out in a few days if we agree.
> 
> - On the LaTeX part:
> 
>  Most of the time, it's better to let LaTeX choose its bullets than
>  enforcing code produced to mimic Org buffer. In other words, a "(1)"
>  bullet should only mean "enumerate item" instead of "enumerate item
>  like (1)".
> 
>  Though, in the past months, I have been working on a overhaul of the
>  whole export system (as a part of a bigger project). If I ever finish
>  it, and if it ever hits Org core, the LaTeX back-end should make it
>  easier to use "inparaenum" and "paraitem" packages directly from Org
>  syntax (via #+attr_latex header).
> 
>  For now, I think solutions offered in this thread are sufficient, if
>  not practical.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> 




Re: [O] How to get numbered lists (1), (2), … ?

2011-10-14 Thread Jambunathan K

>   What about letting go those two variables and create
>   `org-list-bullet-types', which would be a list of strings like:
>
>'("-" "+" "*" "1." "1)" "(1)" "a." "a)" "A)" "A.")
>
>   It would be hard-coded but every bullet type could be opt-in or
>   opt-out via customize. The default value should be as short as
>   possible like '("-" "+" "*" "1." "a.").
>
>   I can work it out in a few days if we agree.

What percentage of users (OK, not percentage of users but numbers of
users) you think will *actually* exercise the opt-in and opt-out
configuration if provided?

If the number of hands raised is in single digits, I would assume that
it is more of a niche feature and let go of it.

Is it psychologically very taxing to see 1. instead of a (1) in an Org
buffer. Could it be so taxing that a user's productivity will be
impacted by it?

Or 

Is it that more varieties of bullets is needed for creating "rich"
deeply nested lists so that each level of the list can take on a
different bullet for better differentiation.
-- 



Re: [O] How to get numbered lists (1), (2), … ?

2011-10-14 Thread Nicolas Goaziou
Hello,

Nick Dokos  writes:

> Marius Hofert  wrote:
>
>
>> What do you mean by "better solution"? As far as I can tell, your
>> approach is precisely what Suvayu pointed to.
>
> No: what Suvayu pointed to can be done with the standard latex exporter,
> so it would not require changes to org-list-generic-to-latex. Just add
> something like this at the top of your org file:
>
> #+LATEX: \renewcommand{\theenumi}{(\arabic{enumi})}
>
> It's better in that it is simpler. There are drawbacks however: the
> above produces lists like this:
>
> (1). foo
> (2). bar
>
> with a period after the closing paren.
>
>> Using your approach, of course much more is possible, please look at
>> the create "enumitem" package with all its customizations.
>> 
>
> That is true: which one is "better" depends on one's requirements (both
> the desired output and how much pain one is willing to suffer in order
> to get there).
>
>> But this approach is a no-go for me (at least at the moment) mainly
>> due to the following reasons (please let me know if I'm wrong, I'm a
>> total newbie to org-mode):
>
>> 1) I have about 40 lists in one file. Having to put in special LaTeX
>> commands is not an option (maybe on only has to type it in once, but
>> then it can easily get overseen, e.g., when you move lists around and
>> the one containing the LaTeX commands is not the first one in the
>> document anymore)
>
> That's no problem: the LATEX_HEADER line goes in once at the top
> of the org file. You can move lists around at will.
>
>> 2) org-mode is basically a "better" text-mode. I don't want to have
>> LaTeX code in there if I print it as a .txt file.
>> 
>> Is there a solution without having to put #+LATEX_HEADER:
>> \usepackage{enumerate} before each list? Can this be set anywhere in
>> the preferences?
>> 
>
> You can customize the latex preamble that org adds to latex files to do
> that. The disadvantage is that you get the modified preamble always.
> See the org-export-latex-packages-alist variable for one way to do that.
>
>> But I assume that I still have to put in lists in org-mode like this:
>> 1.,2.,... or 1),2),... and can't put them in like this (1),(2),...?
>
> Correct: that would require changes to org-list.el I think - but Nicolas
> will have to say the final word on this. All the solutions so far work
> by modifying the latex output only, not the way you enter the list into
> the org file.

- On the Org part:

  I have nothing against (1) as item bullets, as it doesn't interfere
  with any existing Org syntax. I just think it shouldn't be available
  by default (much like alphabetical ordered lists).

  The implementation isn't hard /per se/ (at least less changes are
  required than implementing, for example, roman numbered lists), but
  I also think there should be some cleanup with regards to item
  bullets. So far, there is `org-plain-list-ordered-item-terminator' and
  `org-alphabetical-lists' to tweak them. We should avoid adding a third
  one.

  What about letting go those two variables and create
  `org-list-bullet-types', which would be a list of strings like:

   '("-" "+" "*" "1." "1)" "(1)" "a." "a)" "A)" "A.")

  It would be hard-coded but every bullet type could be opt-in or
  opt-out via customize. The default value should be as short as
  possible like '("-" "+" "*" "1." "a.").

  I can work it out in a few days if we agree.

- On the LaTeX part:

  Most of the time, it's better to let LaTeX choose its bullets than
  enforcing code produced to mimic Org buffer. In other words, a "(1)"
  bullet should only mean "enumerate item" instead of "enumerate item
  like (1)".

  Though, in the past months, I have been working on a overhaul of the
  whole export system (as a part of a bigger project). If I ever finish
  it, and if it ever hits Org core, the LaTeX back-end should make it
  easier to use "inparaenum" and "paraitem" packages directly from Org
  syntax (via #+attr_latex header).

  For now, I think solutions offered in this thread are sufficient, if
  not practical.


Regards,

-- 
Nicolas Goaziou



Re: [O] property values and timestamps

2011-10-14 Thread Giovanni Ridolfi
Nick Dokos  writes:

> Skip Collins  wrote:
>
>> I store a timestamp in a property. 

You can  use a capture template:

(setq org-capture-templates (quote (("a" "vArious" entry (file+headline
"c:/myfile.org" "Appt") ":PROPERTIES:
:Birthday:  %^u
:END:

hth
Giovanni



Re: [O] [patch] Add source subtree which will be refiled

2011-10-14 Thread Carsten Dominik
Applied, thanks.

Please, provide a ChangeLog-like entry next time.

- Carsten

On 14.10.2011, at 10:25, Sebastien Vauban wrote:

> Hi Carsten,
> 
>> "Sebastien Vauban" wrote:
>>> Carsten Dominik wrote:
> I found it difficult, sometimes, to remember which subtree we're gonna
> refile. When TAB'ing for multiple targets, you loose your source buffer,
> and can easily forget which exact subtree you had selected.
> 
> Here a patch to add the name of the subtree we're operating on.
 
 can you please resubmit a modified patch using either (org-get-heading t t)
 or (nth 4 (org-heading-components))
>>> 
>>> Thanks for looking at it.
>>> 
>>> I'll do!
>> 
>> Here it is: a modified version which only uses the text of the entry when
>> asking where to refile some headline.
> 
> Please disregard http://patchwork.newartisans.com/patch/987/ as it contained 2
> typos.
> 
> This one is correct and can be applied straight away.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> <0001-Use-the-text-of-the-heading-when-refiling.patch>




Re: [O] Ways to make org feasible for huge files

2011-10-14 Thread Jude DaShiell
Why not working-file and archive-file?  Archive-file would be the big 
file and working-file would be the small file in that scheme.

On Wed, 12 Oct 2011, brian powell wrote:

> * Maybe EMACS  "narrowing" could be used:
> http://www.gnu.org/s/libtool/manual/emacs/Narrowing.html
> ...
> Narrowing can make it easier to concentrate on a single subroutine or
> paragraph by eliminating clutter. It can also be used to limit the
> range of operation of a replace command or repeating keyboard macro.
> ...
> C-x n n
> Narrow down to between point and mark (narrow-to-region).
> C-x n w
> Widen to make the entire buffer accessible again (widen).
> C-x n p
> Narrow down to the current page (narrow-to-page).
> C-x n d
> Narrow down to the current defun (narrow-to-defun).
> 
> ** I mean: Maybe an OrgMode user could do narrow-to-region (and then
> just "render" on the new smaller region) and/or an implementation
> something like "org-narrow-to-region" could be coded.
> 
> *** Just an idea--your mileage may vary--it may not work at all--I
> hope you try it out and tell how it works for you.
> 
> * I ran into similar problems: I made the file into 2 separate
> files--one very large and the other very small that I render a
> lot--when it gets big, I just prune out older and less important now
> (backburner) subjects, paste them at the bottom of the small file and
> then cut and paste the less important "*" sections into the big file.
> ** Works great, its really the best way to do it--for backing up and
> encrypting reasons and hard drive space reasons etc.
> ** Could call them blahfile_now.org and blahfile_later.org (for the
> small and large files respectively).
> *** Since OrgMode files are plain text files, this works great.
> 
> On Wed, Oct 12, 2011 at 8:54 PM, Marcelo de Moraes Serpa
>  wrote:
> > Hi list,
> >
> > I love org and I think there's nothing like it out there, but I'm
> > considering using Evernote for reference notes, because my reference.org
> > file has grown too big (4234k + lines). This makes the rendering of the file
> > way too slow, and 2 times out of 10 emacs crashes because of that.
> 
> 

Jude 
If I got a nickel for every message I've already sent supporting Microsoft
Windows and its applications I'd have enough to retire on comfortably no
matter what the stock market did.




Re: [O] Ways to make org feasible for huge files

2011-10-14 Thread Jude DaShiell
If org-mode runs into that kind of problem one way might be when a new 
.org file is made it has a chained from [main.org] statement in the top. 
 If the file remains small enough that's all it would get.  If the file 
is going to go beyond x lines in length, then a chained to [file.org] 
would end that first file and file.org would then open up if a user went 
beyond the chained to statement in the first file.  The file file.org 
would have a chained from [firstfile.org] somewhere in the top of the 
file and names for files ought to be selectable by the users.  This will 
only work where good garbage collection happens, and something like it 
was used on CP/M systems with t-maker back before I.B.M. made its first 
PC.

On Fri, 14 Oct 2011, Scott Jaderholm wrote:

> Btw I get that behavior in emacs 23.1 too
> Scott
> 
> 
> On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn wrote:
> 
> > Marcelo de Moraes Serpa  writes:
> >
> > Hi Marcelo,
> >
> > > 4328, exactly the same amount of lines I have in the file.
> >
> > Didn't you say that you have 4000 *k* lines?
> >
> > Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be
> > more clever and only creates overlays for the visible area of a buffer.
> > For example, when opening a file with 1000 lines and enabling
> > linum-mode, I only have 35 overlays, because only 35 lines are visible
> > at a time.
> >
> > Bye,
> > Tassilo
> >
> > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn  > >wrote:
> > >
> > >> Marcelo de Moraes Serpa  writes:
> > >>
> > >> > Wow.. this worked Torsten. Thank you. I wonder why this happens...
> > >>
> > >> linum-mode works with overlays to embed the numbers at the beginnig of
> > >> lines.  Overlays are very flexible but not too efficient, you don't want
> > >> to have too many of them.  Looking at linum.el, it seems it already does
> > >> pooling of overlays in order not to create one overlay for any line, but
> > >> I'm not sure.  Could you please do
> > >>
> > >>  M-: (length linum-overlays) RET
> > >>
> > >> in that large org file with linum-mode enabled and say what it returns
> > >> to satisfy my curiosity?
> > >>
> > >> Bye,
> > >> Tassilo
> > >>
> > >>
> > >>
> >
> >
> 

Jude 
If I got a nickel for every message I've already sent supporting Microsoft
Windows and its applications I'd have enough to retire on comfortably no
matter what the stock market did.




[O] LaTeX export crashes

2011-10-14 Thread Ken Williams
Hi, the following document makes a LaTeX export (C-c C-e d) crash with "Args 
out of range: "", -1, 0".  After that,

--
#+TITLE: Test doc
#+AUTHOR: Ken Williams

Some stuff.

#+begin_src R
5+5
#+end_src
--

Is this a known problem?

If I either omit the R source block, or add a top-level outline element to the 
document, then the export succeeds.  For now as a workaround I guess I'll add a 
header.

Thanks,

 -Ken

CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended 
recipient(s) and may contain confidential and privileged information. Any 
unauthorized review, use, disclosure or distribution of any kind is strictly 
prohibited. If you are not the intended recipient, please contact the sender 
via reply e-mail and destroy all copies of the original message. Thank you.



[O] LaTeX export crashes

2011-10-14 Thread Ken Williams
Hi, the following document makes a LaTeX export (C-c C-e d) crash with
"Args out of range: "", -1, 0".  After that, exporting (to any format)
dies with the same error.

--
#+TITLE: Test doc
#+AUTHOR: Ken Williams

Some stuff.

#+begin_src R
5+5
#+end_src
--

Is this a known problem?

If I either omit the R source block, or add a top-level outline
element to the document, then the export succeeds.  For now as a
workaround I guess I'll add a header.

Thanks,

 -Ken



Emacs  : GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600)
 of 2011-03-10 on 3249CTO
Package: Org-mode version 7.7

current state:
==
(setq
 org-log-done 'time
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-babel-load-languages '((emacs-lisp) (R . t))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-alphabetical-lists t
 org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
 org-export-html-style "\n
\n"
 org-export-latex-format-toc-function 'org-export-latex-format-toc-default
 org-export-preprocess-hook '((lambda nil
   (org-set-local (quote
 org-complex-heading-regexp)
"^\\(\\*+\\)[
 ]+\\(?:\\(TODO\\|DONE\\)\\>\\)?\\(?:[  ]*\\(\\[#.\\]\\)\\)?[
 ]*\\(.*?\\)\\(?:[  ]+\\(:[[:alnum:]_@#%:]+:\\)\\)?[]*$")
   )
  )
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-shell-link-function 'yes-or-no-p
 org-export-first-hook '(org-beamer-initialize-open-trackers)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
 org-cycle-hide-drawers org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-export-preprocess-before-normalizing-links-hook
'(org-remove-file-link-modifiers)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook
 change-major-mode-hook org-show-block-all append local]
   5]
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook
 org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src
org-babel-exp-inline-src-blocks))
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-occur-hook '(org-first-headline-recenter)
 org-from-is-user-regexp nil
 org-export-babel-evaluate nil
 org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
 org-confirm-babel-evaluate nil
 org-export-latex-final-hook '(org-beamer-amend-header
 org-beamer-fix-toc org-beamer-auto-fragile-frames
   org-beamer-place-default-actions-for-lists)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-blocks '((src org-babel-exp-src-block nil) (comment
 org-export-blocks-format-comment t)
 (ditaa org-export-blocks-format-ditaa nil) (dot
org-export-blocks-format-dot nil))
 )



Re: [O] [patch] Add source subtree which will be refiled

2011-10-14 Thread Sebastien Vauban
Hi Carsten,

> "Sebastien Vauban" wrote:
>> Carsten Dominik wrote:
 I found it difficult, sometimes, to remember which subtree we're gonna
 refile. When TAB'ing for multiple targets, you loose your source buffer,
 and can easily forget which exact subtree you had selected.

 Here a patch to add the name of the subtree we're operating on.
>>>
>>> can you please resubmit a modified patch using either (org-get-heading t t)
>>> or (nth 4 (org-heading-components))
>>
>> Thanks for looking at it.
>>
>> I'll do!
>
> Here it is: a modified version which only uses the text of the entry when
> asking where to refile some headline.

Please disregard http://patchwork.newartisans.com/patch/987/ as it contained 2
typos.

This one is correct and can be applied straight away.

Best regards,
  Seb

-- 
Sebastien Vauban
>From e86292614425dd385af7857384853e8e6245462f Mon Sep 17 00:00:00 2001
From: Sebastien Vauban 
Date: Fri, 14 Oct 2011 09:18:55 +0200
Subject: [PATCH] Use the text of the heading when refiling.

---
 lisp/org.el |   22 ++
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b26e1a3..66c2507 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10481,14 +10481,20 @@ prefix argument (`C-u C-u C-u C-c C-w')."
    (marker-position org-clock-hd-marker)))
 		  (setq goto nil)))
 	   (setq it (or rfloc
-			(save-excursion
-			  (unless goto (org-back-to-heading t))
-			  (org-refile-get-location
-			   (cond (goto "Goto")
- (regionp "Refile region to")
- (t "Refile subtree to")) default-buffer
-			   org-refile-allow-creating-parent-nodes
-			   goto)
+			(let (heading-text)
+			  (save-excursion
+(unless goto
+  (org-back-to-heading t)
+  (setq heading-text
+	(nth 4 (org-heading-components
+(org-refile-get-location
+ (cond (goto "Goto")
+   (regionp "Refile region to")
+   (t (concat "Refile subtree \""
+		  heading-text "\" to")))
+ default-buffer
+ org-refile-allow-creating-parent-nodes
+ goto))
 	  (setq file (nth 1 it)
 		re (nth 2 it)
 		pos (nth 3 it))
-- 
1.7.5.1



[O] No updates on git server?

2011-10-14 Thread Rainer M Krug
Hi

I am updating from git daily (from git://repo.or.cz/org-mode.git) , but
haven't received any updates during the last two days - is there a problem
or has org reached a stable state?

Rainer


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug


Re: [O] Ways to make org feasible for huge files

2011-10-14 Thread Scott Jaderholm
Btw I get that behavior in emacs 23.1 too
Scott


On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn wrote:

> Marcelo de Moraes Serpa  writes:
>
> Hi Marcelo,
>
> > 4328, exactly the same amount of lines I have in the file.
>
> Didn't you say that you have 4000 *k* lines?
>
> Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be
> more clever and only creates overlays for the visible area of a buffer.
> For example, when opening a file with 1000 lines and enabling
> linum-mode, I only have 35 overlays, because only 35 lines are visible
> at a time.
>
> Bye,
> Tassilo
>
> > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn  >wrote:
> >
> >> Marcelo de Moraes Serpa  writes:
> >>
> >> > Wow.. this worked Torsten. Thank you. I wonder why this happens...
> >>
> >> linum-mode works with overlays to embed the numbers at the beginnig of
> >> lines.  Overlays are very flexible but not too efficient, you don't want
> >> to have too many of them.  Looking at linum.el, it seems it already does
> >> pooling of overlays in order not to create one overlay for any line, but
> >> I'm not sure.  Could you please do
> >>
> >>  M-: (length linum-overlays) RET
> >>
> >> in that large org file with linum-mode enabled and say what it returns
> >> to satisfy my curiosity?
> >>
> >> Bye,
> >> Tassilo
> >>
> >>
> >>
>
>


Re: [O] Ways to make org feasible for huge files

2011-10-14 Thread Tassilo Horn
Marcelo de Moraes Serpa  writes:

Hi Marcelo,

> 4328, exactly the same amount of lines I have in the file.

Didn't you say that you have 4000 *k* lines?

Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be
more clever and only creates overlays for the visible area of a buffer.
For example, when opening a file with 1000 lines and enabling
linum-mode, I only have 35 overlays, because only 35 lines are visible
at a time.

Bye,
Tassilo

> On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn wrote:
>
>> Marcelo de Moraes Serpa  writes:
>>
>> > Wow.. this worked Torsten. Thank you. I wonder why this happens...
>>
>> linum-mode works with overlays to embed the numbers at the beginnig of
>> lines.  Overlays are very flexible but not too efficient, you don't want
>> to have too many of them.  Looking at linum.el, it seems it already does
>> pooling of overlays in order not to create one overlay for any line, but
>> I'm not sure.  Could you please do
>>
>>  M-: (length linum-overlays) RET
>>
>> in that large org file with linum-mode enabled and say what it returns
>> to satisfy my curiosity?
>>
>> Bye,
>> Tassilo
>>
>>
>>