Drawers are a standard feature of org mode described in the manual https://orgmode.org/manual/Drawers.html They look like:
** This is a headline Still outside the drawer :DRAWERNAME: This is inside the drawer. :END: After the drawer.
They can be folded or unfolded with the usual visibility cycling.
On Android orgzly they are supported, and I use them there to hide code that is emacs dependent.
Presently beorg simply ignore them.
Drawers are also used for PROPERTIES, which are also ignored by beorg.
It would be nice to add them at least in visibility cycling to ensure compatibility with beorg and orgzly.
I do plan on recognising and supporting drawers in a future release. I’ll take a look at how Orgzly presents these to the user as part of planning how I intend this to work. Support the PROPERTIES drawer will enable a number of additional features so I am keen to do this relatively soon.
I was only targeting folding/unfolding i.e. visibility cycling. If you support PROPERTIES you have to deal with visibility cycling; and it should not be difficult to include all drawers, and not only PROPERTIES.
My main concern was with compatibility with emacs and orgzly. You can have big drawers in file that are folded in emacs and orgzly, and appear as garbage in beorg.
I hope you can consider it while implementing PROPERTIES.
As someone that has a PROPERTIES drawer added to every item, I can’t wait to see this implemented!
I was looking for drawer open/close cycling too. I use drawers to stash stuff so it doesn’t interrupt the flow of the document. Beorg just dumps all that as text right where it is. That’s better than losing it but not an elegant solution.
Thanks for the clarification on this request. I guess there are a number of things to implement:
Getting beorg to parse drawers and then update/read the property drawer programatically
In the outliner there should be a way of expanding/collapsing drawers
When HTML is rendered (for use when showing notes in the item editor and for document export) drawers should be hidden as it doesn’t make sense to show them here
I believe that there are many people really need this feature just like me !
I would definitely like to support drawers in general and PROPERTIES specifcally… I’d love to be able to write scheme filters against things like “style: habit” or “effort: 0:05” or other common uses of properties.
I’m going to try toying around with scheme to see if I can come up with a way of capturing just the properties drawer, but it’s a bit clunky to play in that sandbox now without even a console.log equivalent.
It would also probably be best if drawers were ignored when showing push notificatons of scheduled items
I often have todo items that are like…
* headline that i'd like to see
SCHEDULED: <2019-07-11 Thu>
:PROPERTIES:
stuff_i_care_about: 0
...
:END:
body text that would be better to show than the properties drawer
I have started work on support for drawers, including special recognition of PROPERTIES and LOGBOOK drawers. Such drawers will be hidden by default when exporting files/items and in notifications. You’ll certainly be able to search for items with specific properties - for example “t shopping r shop supermarket” will find times tagged with “Shopping” and where a property “SHOP” is set to “Supermarket” (note search will be case insensitive).
This is likely to be released at the end of July/beginning of August.
One feature for drawers that would be particularly nice for me would be logging repeated tasks into the :LOGGING: drawer as right now I do have the option logdrawer set in my orgmode files but when I mark repeating tasks off as done in beorg, it puts it outside of the logging drawer which also seems to lead to all sorts of other problems when working directly with orgmode. That said, this is less of a needed feature as a simple fix would just be to not log it into a drawer - but I do find this feature quite useful especially with tasks that use the “habit” style.
I’ll look at including this in the next release which has some support for drawers.
Last update enables search in drawers. Ares drawers supported? How to use them? Thanks!
beorg understands and parses drawers internally. This enables searching of properties and is used by the new task timers (clocking) feature. However for the moment that it is the limit of the support for drawers. Eventually I want to enable easy editing of drawer contents (particular properties drawers) and folding of drawers when displayed in the outline.
Many thanks! Looking forward to full drawers support and much more! Thanks and good luck!
Looking forward to folding drawer support.
I’d like to add in to this about drawers if I may. When marking repeating tasks as done, could we specify a drawer to contain these completions? Emacs has log-to-drawer that I use on my computer and it works very well for all the habits I keep track of, but I always end up manually shuffling the text around after a completion ticked in beorg.
In beorg this is called org-log-into-drawer - setting that to something other than #f will log state changes and clock/timer entries. Note that clock/timer entries default to LOGBOOK so even if #f they get put into a drawer.
Matthew, I’m a little confused about your reply to Stephen Walsh. To me it suggests that we can log state changes into a drawer by setting org-log-into-drawer to #t. I also use org-mode to track habits, and I log todo state changes into LOGBOOK. I’d like to replicate this functionality in Beorg. In my init.org file, I have (defvar org-log-into-drawer #t), but this doesn’t alter the way Beorg logs todo state changes. Am I missing something here? I’m not too technically proficient, but I believe I can follow instructions relatively well. If it’s relevant, I’ve purchased all extensions except the ones for Encryption and Properties. Any help would be greatly appreciated.
Matthew, I’m a little confused about your reply your response to Stephen Walsh. To me it suggests that we can log state changes into a drawer by setting org-log-into-drawer to #t. I also use org-modes to track habits, and I log todo state changes into LOGBOOK. I’d like to replicate this functionality in Beorg. In my init.org file, I have (defvar org-log-into-drawer #t), but this doesn’t alter the way Beorg logs todo state changes. Am I missing something here? I’m not too technically proficient, but I believe I can follow instructions relatively well. If it’s relevant, I’ve purchased all extensions except the ones for Encryption and Properties. Any help would be greatly appreciated.
Currently beorg only logs state changes for repeating entries. I hope to look at adding support for logging all state changes at some point in the near future.
Thank you for your reply, Matthew. I was imprecise in my original post. My aim is to log repeating tasks in Beorg into the same LOGBOOK drawer Emacs uses. TODO state changes logged in Beorg are currently logged directly beneath TODO headings. I assumed I could use (defvar org-log-into-drawer #t)–similar to the way I use ’log-to-drawer’ in Emacs– but that doesn’t achieve the desired functionality. I find myself in the same position as Stephen Walsh; I have to move ’text around after a completion ticked in Beorg.’ If the functionality I’m seeking isn’t available in Beorg, that’s okay, but if it is, could you point me in the direction of a solution? And sorry for hijacking this thread.
In your init.org you should be able to do (for example):
(set! org-log-into-drawer “LOGBOOK”)
or similar. The default for this is #f which tells beorg not to log entries into a drawer.
Check out https://www.beorg.app/manual/library-org/ for the default org file beorg loads which sets up the variables you can modify.
I just tried to create an init.org file and just added the following content:
* Drawer
#+begin_src scheme
(toast "init loaded" "logbook")
(set! org-log-into-drawer "LOGBOOK")
#+end_src
I don’t see the toast at the startup of beorg (even if I close it and reopen it).
And apparently the option to log into the drawer does not appear to work.
I am missing something?
The init.org file is read before the UI is fully up and running - so a toast in the init.org won’t do anything at that point.
The org-log-into-drawer variable in beorg only works with state changes for repeating items and clock/timer entries in. For which events are you not seeing it work for? Hopefully at some point in the future I will extend support to all state changes.
Matthew, I haven’t touched this in awhile, but I’m still having trouble with logging to the LOGBOOK based on the recommendation above. I’m not sure what I’m missing. In my init.org file (which lives in the root of my Dropbox sync directory I have the below:
#+begin_src scheme
(set! org-log-into-drawer "LOGBOOK")
(set! org-clock-into-drawer "LOGBOOK")
#+end_src
For the below task, you can see that marking as done, logs NOT to the LOGBOOK, but between PROPERTIES and LOGBOOK. As far as I can tell this is a repeating task as you have stated needs to be the case.
What should be different in my setup here?
** TODO Evening brush :HEALTH:
SCHEDULED: <2021-01-14 Thu 19:00 ++1d>
:PROPERTIES:
:STYLE: habit
:END:
:LOGBOOK:
State “DONE” from “NEXT” [2021-01-12 Tue 10:49]
State “DONE” from “NEXT” [2021-01-10 Sun 08:37]
State “DONE” from “NEXT” [2021-01-09 Sat 08:37]
State “DONE” from “NEXT” [2021-01-06 Wed 20:26]
:END:
I thought I had replied earlier today, so forgive me if this shows up as a duplicate. I have the below in my init.org
#+begin_src scheme
(set! org-log-into-drawer "LOGBOOK")
(set! org-clock-into-drawer "LOGBOOK")
#+end_src
When I mark this item as done in beorg, this is what happens.
** NEXT Evening brush :HEALTH:
SCHEDULED: <2021-01-12 Tue 19:00 ++1d>
:PROPERTIES:
:STYLE: habit
:REPEAT_TO_STATE: NEXT
:END:
- State "DONE" from "NEXT" [2021-01-11 Mon 18:53]
:LOGBOOK:
- State "DONE" from "NEXT" [2021-01-10 Sun 08:37]
- State "DONE" from "NEXT" [2021-01-09 Sat 08:37]
- State "DONE" from "NEXT" [2021-01-06 Wed 20:26]
:END:
As far as I can tell, this is a repeating item, but it’s not logging to the LOGBOOK as expected.
What should change here to make this work?
Thank you posting this information. I will try and look at this over the next few days and get back to you with either finding a bug or the correct configuration.
Earlier in this thread you said:
Currently beorg only logs state changes for repeating entries. I hope to look at adding support for logging all state changes at some point in the near future.
Is this still true? I have been trying to get my ‘DONE’ state changes to go into the LOGBOOK drawer for non-repeating entries but it doesn’t seem to be working. My init.org is:
This file is loaded by beorg (the iOS org-mode app)
#+begin_src scheme
(set! org-log-into-drawer "LOGBOOK")
(set! org-log-done #t)
#+end_src
I’ve confirmed that org-log-into-drawer is indeed set to “LOGBOOK”. It doesn’t seem to matter whether org-log-done is set to #t or #f.
For reference, my emacs config has these settings:
(setq org-todo-keywords
'((sequence "TODO(t)" "BLOCKED(b!/!)" "|" "CANCELED(c!/!)" "DONE(d!/!)")))
(setq org-log-reschedule 'time)
(setq org-log-redeadline 'time)
(setq org-log-into-drawer t)
(setq org-log-done nil) ; don't add CLOSED line because we're logging in the logbook
Thank you for the reminder about this feature request - “near future” has long gone! I will look to include some functionality similar to this in the next update (I’ve just added the code for this so this is much more definite than last time!)
Fantastic, thanks for being so responsive!
It’s been a minute since revisiting this issue. I’m happy to help out if I can, but even with the latest app version, I’m still not seeing repeated events log into the LOGBOOK.
I probably should have documented this better. I did make a change back in August 2022 to add a new org-log-done-transition variable. If this is set to #t then all done state changes will be logged. If org-log-into-drawer is set to, for example, LOGBOOK then that state change will be added to the logbook.
If this isn’t working please send me your init.org and I will take a look at this in early September.
What is the status of drawer visibility cycling? I still see property drawers, and there’s no obvious way to hide them.
This is something I need to revisit at some point. So unfortunately no progress on this.
