From: Carsten Dominik <carsten.dominik@gmail.com>
To: Bernt Hansen <bernt@norang.ca>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: How to define TODOs within continuous text the best way?
Date: Mon, 30 Mar 2009 22:53:38 +0200 [thread overview]
Message-ID: <05D242D7-8AAF-4CF1-B91E-F621B31129F1@gmail.com> (raw)
In-Reply-To: <87r60edati.fsf@gollum.intra.norang.ca>
Fixed, thanks.
- Carsten
On Mar 30, 2009, at 10:18 PM, Bernt Hansen wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Sometimes, miracles do happen.
>
> :)
>
> <snip>
>> Fool the user, not Org!
>>
>> We will make them just normal outline nodes with stars,
>> metadata and all the rest. Full citizens. But then we treat
>> them specially in just two situations:
>>
>> 1. For visibility cycling: We disqualify these tasks from being
>> recognized during visibility cycling. Simply by setting a
>> limit for the outline depth to be seen by cycling, treating
>> any deeper levels as normal text. So if the parent opens, all
>> these "disqualified" nodes are treated as text and open as
>> well.
>>
>> 2. During export: We treat the node and its meta data as special
>> and export it as some inline construct, and we do this in the
>> export *preprocessor* already, so that the backends never know
>> there was an outline node at all. This fixes any issues with
>> section numbering, text and list continuation etc.
>>
>> 3. As icing on the cake we introduce special fontification which
>> make inline tasks look deeply indented.
>>
>> I have put these features into a new add-on, org-inlinetask.el.
>> Just (require 'org-inlinetask) should turn it on for you, and
>> any headline with a level 15 or deeper (30 if you use odd levels
>> only) will then be subject to the special treatment.
>>
>> I just pushed this file into the git repository. Read the file
>> commentary for explanations and try it out - I think the
>> mechanism work surprisingly well.
>>
>> I simply cannot believe that after all those years, we might be
>> able to close this task.
>
> I think there's a bug here. I have started using
> (setq org-odd-levels-only t)
>
> again and org-cycle() complains about 'limit' not having a value.
>
> ,----[ org.el line 4533 ]
> | (and limit-level (1- (* limit 2)))
> `---- ^^^^^
>
> All I did was update to the latest version in git and did not make any
> other changes to my setup (ie. I'm not using the
> (require 'org-inlinetask)
> stuff)
>
> I'm not sure what this is supposed to be..
>
> Here's the backtrace.
>
> -Bernt
>
>
> Debugger entered--Lisp error: (void-variable limit)
> (* limit 2)
> (1- (* limit 2))
> (and limit-level (1- (* limit 2)))
> (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
> (and limit-level (if org-odd-levels-only (and limit-level ...)
> limit-level))
> (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-
> only ...) (...) (...) (... ...) (... ...) (t ...)))
> org-cycle(nil)
> call-interactively(org-cycle)
> recursive-edit()
> byte-code("Æ\x10 @Ç=!ÈÉÊ\"ËÉ!\x1aA@)¢Ì=!ÈÍÊ\"Î\v!Ï Ð !\fcÑed\"
> VWebÒ
> ¥y`\x1e^[dbÒ
> ¥
> Zy\x0e^[`|)ÓcebÔÕÖ \"× ÔØ!ÙÊ\x1e\x1c\x1e\x1dÔØ!Ú +Ù" [unread-command-char
> debugger-args x debugger-buffer noninteractive debugger-batch-max-
> lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-
> buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"
> message "%s" buffer-string kill-emacs "" nil recursive-edit
> middlestart buffer-read-only standard-output] 4)
> debug(error (void-variable limit))
> (* limit 2)
> (1- (* limit 2))
> (and limit-level (1- (* limit 2)))
> (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
> (and limit-level (if org-odd-levels-only (and limit-level ...)
> limit-level))
> (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-
> only ...) (...) (...) (... ...) (... ...) (t ...)))
> org-cycle(nil)
> call-interactively(org-cycle)
> recursive-edit()
> byte-code("Æ\x10 @Ç=!ÈÉÊ\"ËÉ!\x1aA@)¢Ì=!ÈÍÊ\"Î\v!Ï Ð !\fcÑed\"
> VWebÒ
> ¥y`\x1e^[dbÒ
> ¥
> Zy\x0e^[`|)ÓcebÔÕÖ \"× ÔØ!ÙÊ\x1e\x1c\x1e\x1dÔØ!Ú +Ù" [unread-command-char
> debugger-args x debugger-buffer noninteractive debugger-batch-max-
> lines -1 debug backtrace-debug 4 t backtrace-frame lambda 5 pop-to-
> buffer debugger-mode debugger-setup-buffer count-lines 2 "...\n"
> message "%s" buffer-string kill-emacs "" nil recursive-edit
> middlestart buffer-read-only standard-output] 4)
> debug(error (void-variable limit))
> (* limit 2)
> (1- (* limit 2))
> (and limit-level (1- (* limit 2)))
> (if org-odd-levels-only (and limit-level (1- ...)) limit-level)
> (and limit-level (if org-odd-levels-only (and limit-level ...)
> limit-level))
> (let* ((limit-level ...) (nstars ...) (outline-regexp ...) (bob-
> special ...) (org-cycle-hook ...) (pos ...)) (if (or bob-
> special ...) (setq arg t)) (cond (... ... ...) (... ... ...)
> (... ...) (... ...) (... ...) (... ...) (... ... ...) (buffer-read-
> only ...) (...) (...) (... ...) (... ...) (t ...)))
> org-cycle(nil)
> call-interactively(org-cycle)
> yas/expand()
> call-interactively(yas/expand)
next prev parent reply other threads:[~2009-03-30 20:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-28 14:23 How to define TODOs within continuous text the best way? Karl Maihofer
2009-03-28 17:16 ` Sebastian Rose
2009-03-28 18:26 ` Karl Maihofer
2009-03-28 19:16 ` Karl Maihofer
2009-03-29 1:06 ` Sebastian Rose
2009-03-28 17:42 ` Sebastian Rose
2009-03-30 11:47 ` Carsten Dominik
2009-03-30 20:18 ` Bernt Hansen
2009-03-30 20:53 ` Carsten Dominik [this message]
2009-03-30 21:20 ` Bernt Hansen
2009-03-31 15:23 ` Karl Maihofer
2009-03-31 18:14 ` Carsten Dominik
2009-03-31 19:53 ` Daniel Clemente
2009-04-01 10:05 ` Carsten Dominik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05D242D7-8AAF-4CF1-B91E-F621B31129F1@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=bernt@norang.ca \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).