[testing patch] inline-special-block with full implementation for LaTeX backend

[Juan Manuel Macías]

This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.

The basic syntax of the new element is:

&foo{lorem ipsum dolor}

=> LaTeX: \foo{lorem ipsum dolor}

Nested elements are possible, as well as the inclusion of other elements
such as macros, links or emphasis marks.

The element also supports a list of optional arguments. For the LaTeX
backend there are two specific arguments: :prelatex and :postlatex.
Example:

&foo[:prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}

=> LaTeX: \foo[bar]{lorem ipsum dolor}{baz}

Additionally, there are a number of universal arguments that should be
equivalent between backends where it makes sense to use them (LaTeX,
HTML, odt...). At the moment you can use: :color, :lang and :smallcaps.
Example:

&foo[:color red :smallcaps t :lang french :prelatex [bar] :postlatex 
{baz}]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{red}\foreignlanguage{french}{\foo[bar]{lorem ipsum 
dolor}{baz}}}

The element also has an anonymous variant that only accepts universal
arguments. If set without arguments it simply returns the content
string. Example:

&_[:color blue :lang italian]{lorem ipsum dolor}

=> LaTeX: {\color{blue}\foreignlanguage{italian}{lorem ipsum dolor}}

We can define in the document a list of aliases that group several arguments:

#+options: inline-special-block-aliases:(("myalias" :color "magenta" :lang 
"klingon") ("myalias2" :smallcaps t :color "blue" :prelatex "{2345}")) 

&_[:alias myalias :smallcaps t]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{magenta}\foreignlanguage{klingon}{lorem ipsum 
dolor}}

&foo[:alias myalias2]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{blue}\foo{2345}{lorem ipsum dolor}}

There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style" attribute.

Best regards,

Juan Manuel
>From d211bf601db0dd5c01a3edda74cd1b37f1f9448c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block.

* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
* lisp/ox.el (org-export-read-inline-special-block-attributes): read
optional attributes.
* lisp/ox.el (org-export-inline-special-block-aliases): aliases for grouped attributes.
---
 lisp/org-element.el | 55 -
 lisp/ox-latex.el| 36 +
 lisp/ox.el  | 30 +
 3 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..c430d934b 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
 			   "\\|"))
 		  ;; Objects starting with "@": export snippets.
 		  "@@"
+  ;; Objects starting with "&": inline-special-blocks.
+  "&"
 		  ;; Objects starting with "{": macro.
 		  "{{{"
 		  ;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
   "List of recursive element types aka Greater Elements.")
 
 (defconst org-element-all-objects
-  '(bold citation citation-reference code entity export-snippet
+  '(bold citation citation-reference code entity export-snippet inline-special-block
 	 footnote-reference inline-babel-call inline-src-block italic line-break
 	 latex-fragment link macro radio-target statistics-cookie strike-through
 	 subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
   ;; Ignore inline babel call and inline source block as formulas
   ;; are possible.  Also ignore line breaks and statistics
   ;; cookies.
+  (inline-special-block ,@standard-set)
   (table-cell citation export-snippet footnote-reference link macro
   radio-target target timestamp ,@minimal-set)
   (table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
 	  (org-element-property :name entity)
 	  (when (org-element-property :use-brackets-p entity) "{}")))
 
+ inline special block
+
+(defun org-element-inline-special-block-parser ()
+  "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties.  Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+  (save-excursion
+(when (looking-at "&\\([_A-Za-z]+\\)[{[]")
+  (goto-char (- (match-end 0) 1))
+  (let* ((begin (match-beginning 0))
+ (parameters
+  (

Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

[Ihor Radchenko]

Björn Bidar  writes:

> The problem is that org-mode leaves the agenda command selection frame around
> after selecting the specific agenda to be displayed

I cannot reproduce on the latest main using the latest Emacs master.
May you please provide a reproducer starting from emacs -Q?
See https://orgmode.org/manual/Feedback.html#Feedback

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

[Björn Bidar]

Ihor Radchenko  writes:

> Björn Bidar  writes:
>> I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
>> is set to other-frame since
>> 78dc58508ddbf97b6f44c0a6dd222eab3d13b50a. 
>
> May you please explain more what the problem is?

The problem is that org-mode leaves the agenda command selection frame around
after selecting the specific agenda to be displayed

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>>> May you please provide more details?
>> 
> This is different of what I saw before:
>
> When splitting python blocks in an org file I got a long list of 
> warnings:
> Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org 
> buffer # (python-mode)
> until it stopped by itself.
>
> I traced this to user-errors in my own `org-babel-edit-prep:python' 
> which I
> use to let eglot handle python source blocks.
>
> I rewrote my `org-babel-edit-prep:python' to get rid of user-errors but
> then I bumped on the user-error coming from 
> `org-src--make-source-overlay'.

This is strange. `org-src--make-source-overlay' does not use
`org-element' API. I cannot see how you are getting such warnings from there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Feature request: exclude sub-trees by backend

[Ihor Radchenko]

Edgar Lux  writes:

> I am trying to exclude different sub-trees (a.k.a. headings or sections), 
> depending on the exporter backend. I am familiar with =:noexport:= to exclude 
> selected sections (disregarding the backend). I found a solution, but it is 
> only intended for a specific backend:
>
> https://emacs.stackexchange.com/a/76454

For arbitrary backend, you can try

(defun exclude-from-latex-export-hook (backend)
  (setq org-export-exclude-tags (cons (format "noexport_%s" backend) 
org-export-exclude-tags)))

> I would like to recommend that such a thing is implemented for any backend. 
> So that :noexport_X: (where X is a backend) is excluded. Something like:
>
> * Not for html   :noexport_html:
>
> * For HTML   :noexport_latex:

This is not a feature request I see often in the forums.
It is also easy to implement.
I think that it would be ok to add such feature if multiple users are 
interested.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Bruno Barbier]

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> Note that only the first 5 patchs are real patchs.  The remaining things
>> are just a demo how it could be used.  The current async (ob-comint)
>> depends on writing UUIDs in org files, and, that's why I couldn't use it
>> as a demo.  I'm thinking about dropping the patch:
>>
>>'ob-core async: Add org-babel--async tools [2/5]'
>>
>> and just provide an other new keyword (feedbacks-with) so that anybody
>> may plug its own feedback process.
>
> May you please clarify if adding the new code block parameter that
> defines custom execute function is something you want to add to Org mode
> or just a helper code to demo you main patch?

Yes. (I thought about adding it in a separate request;  but that would be
simpler to include it.)


>>> Or consider user running an src block, quickly editing it, and then
>>> running again. What should we do then? Should we stop the first running
>>> process?
>>
>> To keep things simple and generic, I would just forbid the user to
>> reschedule the task until the previous outcome is available.
>
> This may not be as trivial as one might think.
> Consider
>
> #+name: foo
> #+begin_src bash :async yes
> ...
> #+end_src
>
> #+results: foo
> 
>
> Another code block with the same name will write results under
> #+results: foo
> #+name: foo
> #+begin_src bash :async yes
> ...
> #+end_src

> We can currently have multiple code blocks writing to the same place.
> And async execution should not only check is the current src block is
> scheduled, but also whether we are attempting to write to a place where
> no other running block is scheduled to write.

Today, the asynchronous execution is attached to the result; the source
code itself is not locked and stays editable.

With the current implementation, trying your example, the second execution 
fails with:
Error running timer: (user-error "Cannot modify an area being
updated")

So, it's already OK I guess.

I should improve the behavior (to fail before launching the second
execution).  But, the current design should work in that case.


>
>>> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How 
>>> will it interact with asynchronous evaluation? What if we have multiple 
>>> simultaneously arriving error notifications?
>>
>> In the asynchronous case, I've decided to leave the overlay in place
>> in case of errors, with the error description.  Clicking on that error
>> pops up the same kind of popups as in the synchronous case.
>
> Error buffer does not necessarily appear on failure. When the code leads
> to process writing to stderr, we also display error buffer. Even if the
> process exits with 0 code.

Got it.  The current design adds the popup on failure; I should make it
more flexible to allow to configure a popup on success too.


> Also, your code currently creates overlays unconditionally.
> However, when we have :results silent or :results none, Org babel must
> not modify buffer.

Yes. I'll fix it (and that one was in my TODO list :-))

But if the execution fails, I guess I'll need to provide some feedbacks
anyway, but I don't know yet how (asynchronous popups are not an option,
modifying the file neither).

Thanks for your review and questions,

Bruno


>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

[Ihor Radchenko]

Björn Bidar  writes:
> I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
> is set to other-frame since
> 78dc58508ddbf97b6f44c0a6dd222eab3d13b50a. 

May you please explain more what the problem is?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: User set org-hide-block-startup value overwritten by defvaralias

[Ihor Radchenko]

Ruiyang Wu  writes:

> I recently started to get the following warning from emacs when loading org 
> mode:
> Warning (defvaralias): Overwriting value of ‘org-hide-block-startup’ by 
> aliasing to ‘org-cycle-hide-block-startup’
>
> I have this in my init file:
> (setq org-hide-block-startup t)
>
> I believe the value t is not preserved because in org.el, it first loads 
> org-cycle.el which assigns nil to org-cycle-hide-block-startup, and then 
> executes (defvaralias 'org-hide-block-startup 'org-cycle-hide-block-startup) 
> so the value of org-hide-block-startup is overwritten to nil.
>
> Some quick search on the internet seems to suggest that defvaralias should be 
> called first before giving org-cycle-hide-block-startup its default value. 
> (Cf. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5950)

Thanks for reporting and for hunting down the cause!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfe253f7e

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Handle block-type when checking `org-src-fontify-natively'

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> I think I found a bug where the condition for `org-src-fontify-natively`
> in `org-src-fontify-meta-lines-and-blocks-1` wasn't handling the block
> type.  `org-src-fontify-natively` says it should fontify src blocks
> only, but the condition didn't have that constraint.  Attached is a
> patch that adds in the constraint.

It turned out, that some people relied on the undocumented behavior that
Org mode fontifies example blocks as well.
https://orgmode.org/list/cae9z9a3ko27nen0oyfs_abwv_cubnm5yqtlrrux16dhsixs...@mail.gmail.com

Nathaniel, is there any particular problem you encountered that your
patch was aiming to solve? If no, we should probably re-add fontifying
example blocks as undocumented feature people rely on in practice.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Change in Org Capture target parsing

[Ihor Radchenko]

Derek Chen-Becker  writes:

> I started getting an error after updating to the latest commit on main:
>
> Invalid capture target specification: (file+headline org-default-notes-file
> "Tasks")
>
> I bisected it down to 0a58a53edac955381266e49bd68d1140fbece33e, but I can't
> tell from the commit what's wrong with my definition or how to fix it. I
> found this thread in the mailing list, but it doesn't help me shed light on
> what I'm doing wrong:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00153.html
>
> Is it because I'm using the variable "org-default-notes-file" and not a
> string? If that's the case then it's probably easy for me to fix in my
> config, but I wanted to check first.

Thanks for the heads up!
Your config is right, and the bisected commit is too limiting.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24ce9abce

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Ihor Radchenko]

Max Nikulin  writes:

> On 19/02/2024 02:36, Martin Edström wrote:
>> +Since this is a shell-command, remember to use single-quotes
>> +around \\='%i\\=', not double-quotes!  Else a math fragment such
>> +as \"$y = 200$\" gets butchered into only \" = 200\"."
>
> I am afraid, the code, not the docstring must be fixed. I have not tried 
> it, but I expect an issue with
>
>  Test \(f' = df/dx\)
>
> So `shell-quote-argument' is necessary and quotes around %i must be 
> stripped similar to %s in mailcap entries in `org-open-file'.

That would be backwards-incompatible.
What about introducing %e replacement that will be shell-escaped?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Ihor Radchenko]

Bruno Barbier  writes:

> Note that only the first 5 patchs are real patchs.  The remaining things
> are just a demo how it could be used.  The current async (ob-comint)
> depends on writing UUIDs in org files, and, that's why I couldn't use it
> as a demo.  I'm thinking about dropping the patch:
>
>'ob-core async: Add org-babel--async tools [2/5]'
>
> and just provide an other new keyword (feedbacks-with) so that anybody
> may plug its own feedback process.

May you please clarify if adding the new code block parameter that
defines custom execute function is something you want to add to Org mode
or just a helper code to demo you main patch?

>> Or consider user running an src block, quickly editing it, and then
>> running again. What should we do then? Should we stop the first running
>> process?
>
> To keep things simple and generic, I would just forbid the user to
> reschedule the task until the previous outcome is available.

This may not be as trivial as one might think.
Consider

#+name: foo
#+begin_src bash :async yes
...
#+end_src

#+results: foo


Another code block with the same name will write results under
#+results: foo
#+name: foo
#+begin_src bash :async yes
...
#+end_src

We can currently have multiple code blocks writing to the same place.
And async execution should not only check is the current src block is
scheduled, but also whether we are attempting to write to a place where
no other running block is scheduled to write.

>> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How 
>> will it interact with asynchronous evaluation? What if we have multiple 
>> simultaneously arriving error notifications?
>
> In the asynchronous case, I've decided to leave the overlay in place
> in case of errors, with the error description.  Clicking on that error
> pops up the same kind of popups as in the synchronous case.

Error buffer does not necessarily appear on failure. When the code leads
to process writing to stderr, we also display error buffer. Even if the
process exits with 0 code.


Also, your code currently creates overlays unconditionally.
However, when we have :results silent or :results none, Org babel must
not modify buffer.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-mode: example blocks are no longer syntax highlighted in emacs

[Bruno Barbier]

Hi Rudy,

Note that I am not an org maintainer; just trying to help :-)

Rudi C  writes:

>> Why is `:eval never` not as good ?  You don't have to write it on each
>> code block; you may set it globally, per file, per headline, etc.
>
> The main reason is that I also use source blocks for babel blocks that are
> runnable. So I cannot use per headline etc. solutions. I can use snippets
> to automatically insert `:eval never`, but it's not as good a UX.

You could customize `org-insert-structure-template' like this:

(add-to-list 'org-structure-template-alist
  (cons "p"  "src python :eval never"))

Then:

C-c C-, p

should insert your code example:

   #+begin_src python :eval never
   #+end_src


> I also already have lots of org-mode notes written using `example lang`
> blocks. Rewriting all of these will be a PITA.

You could teach Emacs to fix/rewrite those for you.  Ask here if you
need help.  You're probably not the only one that will need to fix
them.


> NickD has identified the commit that introduced this breaking change:
>
> ...
> https://github.com/bzg/org-mode/commit/616e80a9f10c4bd085d7b5ac96fd6ea23e9c9191
> I wrote this patch which can be put in one's config to make this behavior
> configurable.

Thanks for the link.

(your code layout was broken, it's more reliable to attach these kinds
of documents)


> Can you merge this upstream? emacs is all about user customizability, and
> in general, breaking backward compatibility without giving a way out is bad.

According to the email thread, the change was made only to match the
documentation (see
https://list.orgmode.org/87zg7lghzz@gmail.com/).

So, maybe a new option, like you suggested will be accepted, something like:

   (defvar org-fontify-block-types '("src")
  "Which block types to fontify.
  Prior versions of Org may fontify other blocks than src.  That
  invalid behavior is now fixed.  If you have documents relying on
  this invalid behavior, and, you cannot fix them, add the block
  types to this list.")
  
But:
   -  Fontification must be fast. The more options, the harder to
  optimize.

   -  It might just be opening a can of worms: Why is editing not
  working too then ? Why is the indentation incorrect? Why are
  they not exported correctly ? Why is pandoc not able to handle
  them correctly ?  etc.

Let see what other people think.

Bruno

[BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

[Björn Bidar]

I noticed thatOrg-agenda leaves frame around if org-agenda-window-setup
is set to other-frame since
78dc58508ddbf97b6f44c0a6dd222eab3d13b50a. 

Reverting the commit/loading the file before the change fixes the issue.

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-suse-linux-gnu, GTK+ Version 
3.24.39, cairo version 1.18.0)
Package: Org mode version 9.7-pre (release_9.6.8-785-g72bbf8.dirty @ 
/home/bidar/.local/private/etc/emacs/lib/org/lisp/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-directory '("/home/bidar/Dokumente/org"
 "/home/bidar/Dokumente/org/sailfishos"
 "/home/bidar/Dokumente/org/personal"
 "/home/bidar/Dokumente/org/jolla"
 "/home/bidar/Dokumente/org/data"
 "/home/bidar/Dokumente/org/_minted-gemeinsam" 
"/home/bidar/Dokumente/org/data/f0" "/home/bidar/Dokumente/org/data/5c" 
"/home/bidar/Dokumente/org/data/5c/b2a2e6-09d2-4225-b0de-ccd2ab4d9428" 
"/home/bidar/Dokumente/org/data/f0/cbc911-0ffc-41e3-b19a-1c26a43e1676" 
"/home/bidar/Dokumente/org/personal/data" 
"/home/bidar/Dokumente/org/personal/data/bf" 
"/home/bidar/Dokumente/org/personal/data/bf/f21ab1-25c3-49fc-93e2-fb8dda05")
 org-global-properties '(("Effort_ALL" .
  "0:15 0:30 0:45 1:00 2:00 3:00 4:00 5:00 6:00 0:00")
 ("STYLE_ALL" . "habit"))
 org-after-todo-state-change-hook '(org-expiry-insert-created)
 org-caldav-backup-file "/home/bidar/.local/etc/emacs/var/org/caldav/backup.org"
 org-indirect-buffer-display 'current-window
 org-hide-emphasis-markers t
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-export-with-sub-superscripts nil
 org-insert-heading-hook '(org-expiry-insert-created)
 org-yank-adjusted-subtrees t
 org-log-done 'note
 org-capture-bookmark nil
 org-pomodoro-long-break-sound 
"/home/bidar/.local/private/etc/emacs/lib/org-pomodoro/resources/bell_multiple.wav"
 org-agenda-custom-commands '(("A" "Agenda and all TODOs"
   ((agenda "") (alltodo "")))
  (" "
   "Current Project Agenda and TODOs"
   ((tags "REFILE")

   (agenda "")

   (alltodo "")

   )
   ((org-agenda-files
 '("/home/bidar/Dokumente/org/inbox.org" 
"/home/bidar/Dokumente/org/caldav-inbox-arbeit.org" 
"/home/bidar/Dokumente/org/refile.org" "/home/bidar/Dokumente/org/jolla.org")
 )
)
   )
  ("j" "Jolla Agenda and TODOs"
   ((tags "REFILE") (agenda "")
(alltodo ""))
   ((org-agenda-files
 '("/home/bidar/Dokumente/org/inbox.org" 
"/home/bidar/Dokumente/org/caldav-inbox-arbeit.org" 
"/home/bidar/Dokumente/org/refile.org" "/home/bidar/Dokumente/org/jolla.org")
 )
)
   )
  ("d"
   "Daimler Agenda and TODOs"
   ((tags "REFILE") (agenda "")
(alltodo ""))
   ((org-agenda-files
 '("/home/bidar/Dokumente/org/inbox.org" 
"/home/bidar/Dokumente/org/caldav-inbox-arbeit.org" 
"/home/bidar/Dokumente/org/refile.org" "/home/bidar/Dokumente/org/daimler.org")
 )
)
   )
  ("p"
   "Personal Agenda and TODOs"
   ((tags "REFILE") (agenda "")
(alltodo ""))
   ((org-agenda-files
 '("/home/bidar/Dokumente/org/inbox.org" 
"/home/bidar/Dokumente/org/caldav-inbox-personal.org" 
"/home/bidar/Dokumente/org/gemeinsam-inbox.org" 
"/home/bidar/Dokumente/org/gemeinsam.org" 
"/home/bidar/Dokumente/org/refile.org" "/home/bidar/Dokumente/org/personal.org")
 )
)
   )
  ("W" "Weekly Review"
   ((agenda ""
 ((org-agenda-span 7)))
(stuck "") (todo "PROJECT")
(todo "MAYBE")
(todo "WAITING"))