[O] Hiding "future" tasks in tags-todo agenda view
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
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
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
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
> 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
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
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
> 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
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?
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
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
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), … ?
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), … ?
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), … ?
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), … ?
> 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), … ?
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
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
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
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
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
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
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
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?
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
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
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 >> >> >>
