This is on my list of things to improve. I think there is another forum topic about this. Currently beorg does remove leading and trailing blank lines from what it thinks are the 'notes' sections which is causing your blank lines to disappear. Ideally I want to allow users to specify that they like a certain number of blank lines to delineate headlines so that when you add new items in beorg it will format it for you automatically.
Cool, I will look forward to that feature.
How are we doing on this? I use one main org document and use spaces to make things clearer. It's really frustrating that Beorg deletes them all.
You can add the following to your init.org to have beorg add newlines between headlines:
(set! beorg-add-newline-between-headlines #t)
Let me know how you get on with that and if it improves things for you.
Thank Matthew, but that doesn't seem to make any difference?
Ok my bad! I forgot to wrap it in src!
It does work, thank you.
Is there a possibility to change the blank line at different level headers or have it only create a blank line at certain level headers?
That sounds like it would be a good enhancement. This isn't currently possible, but I'll consider this in the future.
Dear Matthew, is there a way to disable this auto formatting? I like to edit my file manually on my computer and may add a newline or not on a specific header. I sometimes prefer different number of newlines so I do it manually, but now when I sync with Beorg and edit the file in it, it removes those newlines, so is there a way to simply disable this feature? Thanks!
Currently there isn't a way to do this unfortunately. When beorg reads a file it converts it into a representation of what was in the file and then when you make an edit it converts that representation back into text and saves to the same file - so there will always be some level of auto formatting. If you can provide some examples of different ways in which you prefer headlines to be spaced out I can have a think whether that detail could be captured in the representation and then replicated when saved.
Dear Matthew,
First of all, thanks a lot for such an amazing app! Can I offer any help to address this issue free of charge? I was struggling with it too recently. I was researching some workarounds, but didn't find any good ones. I am a software engineer at Microsoft with 20 years of experience (https://www.linkedin.com/in/anton-dergunov/). I would be happy to try to fix this issue (potentially some other issues) completely free of charge!
> "If you can provide some examples of different ways in which you prefer headlines to be spaced out..."
I have 2 ideas.
1) I see that the following mode was recently added:
(set! beorg-add-newline-between-headlines #t)
I have tested that, but it inserts a newline for every headline. In the original ticket they were asking about the following representation instead:
* Level 1
** Level 2
** Level 2
< empty space
* Level 1
** Level 2
** Level 2
So one option could be adding something like:
(set! beorg-add-newline-between-level0-headlines #t)
That option would actually satisty my use case perfectly, because I structure my files like this:
* Project 1
** TODO Task 1
** TODO Task 2
* Project 2
** TODO Task 3
** TODO Task 4
2) Another idea is a more general implementation. I would guess you store the data as some form of a tree for intermediate representation. I think it could be possible just to introduce there a node to store any newlines explicitly. I know you also consider edits to the internal representation, and that may include movement of nodes. But I think that having these newlines as nodes in the tree would work reasonably well even in this case.
I am happy to help with the implementation of any of these approaches if that's useful. Or also happy to chat about this topic. Thanks again for your amazing app!
Thanks Anton for some ideas!
Matthew, on my side, I think I would prefer a more general implementation of dealing with this.
Maybe having a way to "auto format" or not would be useful? Like adding a file property per file and having a default global value from the ini.org file. Or when the `beorg-add-newline-between-headlines` is set to nil, then Beorg wouldn't change the amount of newline that are inserted manually
To give you some example of how I write my file:
I'm working with some clients, so I could put my todos like:
* Client 1 ** TODO do that ** TODO do that ** TODO do that * Client 2 ** TODO do that ** TODO do that
Or, sometimes I have project or different categories that I would put before my client headers or a feature I'm developing would be a with multiple actions that I need to do to make this feature work, like:
* Project 1 ** Feature 1 *** TODO do that *** TODO do that ** Feature 2 *** TODO do that *** TODO do that * Project 2 ** Feature 1 *** TODO do that *** TODO do that ** Feature 2 *** TODO do that *** TODO do that
And has you can see from this last one, I added some more spaces before the "Project 2" header to make some emphases and better see it coming when scrolling inside the text file
Thank you, Guillaume! As an engineer, I understand the challenge of supporting all the various types of formatting in the app (how many newlines, where to insert them). This becomes a bit more complicated when you add new tasks or projects. Say, for your example, my second implementation idea would work (which is storing these newlines explicitly in the internal representation). It becomes a bit more complex when you change the order of these projects/features in the application or add new projects/features/tasks. How many spaces should the app add in this case, and how can it guess?
I think that this request could potentially be solved with 2 ideas that I have described above. Let me elaborate them a bit more:
1) Simply specify the number of newlines to use per level. Right now you can specify
(set! beorg-add-newline-between-headlines #t)
It makes sense to add the following:
(set! beorg-add-newline-between-level0-headlines #t)
Maybe even (set! beorg-add-newline-between-level1-headlines #t)
...
That would actually satisfy my use case perfectly, I would not need anything else.
2) The second approach is more general. Matthew is saying "beorg reads a file it converts it into a representation of what was in the file". I think the newlines are simply dropped in this internal representation. I think it could be possible to keep them. Either like that:
* Node "Project 1"
** Subnode "1 newline"
** Subnode "Feature 1"
*** Subsubnode "TODO 1"
*** Subsubnode "TODO 2"
** Subnode "1 newline"
** Subnode "Feature 2"
...
(Alternatively it may be possible to simply store the number of preceding empty lines per every node.)
And when you save that to a file, you can access these newline subnodes and write them back. But this opens the following questions:
A. What if you swap Feature 1 and Feature 2?
I think in this case you could just drag the preceding newlines, so it becomes:
* Node "Project 1"
** Subnode "1 newline"
** Subnode "Feature 2"
*** Subsubnode "TODO 1"
*** Subsubnode "TODO 2"
** Subnode "1 newline"
** Subnode "Feature 1"
...
B. What if you create a new item? Should it have preceding newlines.
I think the solution could be to simply insert as if there were no newlines.
While this may sound complicated, I think that it's all doable, and I would be happy to contribute if I could.
Otherwise, I was thinking to just ditch the newlines from my org files entirely. My goal is to be able to edit these org files effectively in Emacs, so I need to have some structure. I was also thinking about making the top headlines more visible somehow. I know I can assign bigger font for them, but it still does not look nice. I was looking for a way to insert some extra vertical space for them, but could not find a way yet. I have also created a quick Emacs script to recover the newlines after I saved them in Beorg, but that's of course not the ideal solution.
Currently my workaround is the function in Emacs below to recover the newlines before level-1 headlines after I have edited any files in Beorg. It reads all org files and recovers them. Not an ideal solution, but hopefully there could be some support in Beorg... :-)
** F7 to Reinsert Empty Lines #+begin_src emacs-lisp (defun reinsert-empty-lines-in-org-files () "Reinsert empty lines before first-level headers in all files listed in `org-agenda-files`." (interactive) (let ((org-files org-agenda-files) (modified-files '()) (total-changes 0)) ;; Track total lines changed across all files (dolist (file org-files) (with-temp-buffer (insert-file-contents file) (goto-char (point-min)) (let ((changes 0)) ;; Counter for the current file ;; Insert two newlines before each level-1 header (while (re-search-forward "^\\* " nil t) (unless (save-excursion (forward-line -1) (looking-at-p "^\\s-*$")) ;; Check if the previous line is empty (save-excursion ;; Move point two characters back, to insert before the "* " header (goto-char (- (point) 2)) (insert "\n")) (setq changes (1+ changes)))) ;; Increment change counter ;; If changes were made, write the file and record it (when (> changes 0) (write-region (point-min) (point-max) file) (push (cons (file-name-nondirectory file) changes) modified-files) (setq total-changes (+ total-changes changes)))))) ;; Show results in a new buffer (let ((output-buffer (get-buffer-create "*Org File Changes*"))) (with-current-buffer output-buffer (erase-buffer) (insert (format "Modified files and line changes:\n\n")) (dolist (file-change modified-files) (insert (format "File: %s, Lines changed: %d\n" (car file-change) (cdr file-change)))) (insert (format "\nTotal lines changed: %d" total-changes))) (display-buffer output-buffer)))) (global-set-key [f7] 'reinsert-empty-lines-in-org-files) #+end_src
Andy
From what I understand Beorg should not remove the empty lines between subtrees i.e.
* Level 1
** Level 2
** Level 2
< empty space
* Level 1
** Level 2
** Level 2
but when I update an item from the agenda screen, sync via dropbox, and revert the buffer in Emacs the space between my headings is removed:
* Level 1
** Level 2
** Level 2
* Level 1
** Level 2
** Level 2
This makes it more difficult to read my file as I prefer some empty space to delineate the subtrees.
4 people have this problem