Hi,
while refactoring `org-columns-store-format', I noticed one behavior
that may be worth clarifying.
When there is no existing COLUMNS property and no existing #+COLUMNS
keyword, Org inserts a new #+COLUMNS keyword before the first headline,
not necessarily at the beginning of the buffer.
One way to reproduce this as a user is:
1. Start with a buffer like this, with no COLUMNS property and no
#+COLUMNS keyword:
Intro
* H
2. Enable column view, e.g. with `M-x org-columns'.
3. Change the current columns format from the column view, for example
by moving point to one of the columns and pressing `S-M-<left>',
which is bound to `org-columns-delete'.
4. When Org stores the updated format, it inserts a new #+COLUMNS keyword.
The resulting buffer is currently:
Intro
#+COLUMNS: %TODO
* H
rather than:
#+COLUMNS: %TODO
Intro
* H
This behavior follows directly from this part of
`org-columns-store-format':
(goto-char (point-min))
(unless (org-at-heading-p) (outline-next-heading))
(let ((inhibit-read-only t))
(insert-before-markers "#+COLUMNS: " fmt "\n"))
A minimal behavior change would be to remove the call to
`outline-next-heading' and insert the keyword at the beginning of the
buffer instead:
(goto-char (point-min))
(let ((inhibit-read-only t))
(insert-before-markers "#+COLUMNS: " fmt "\n"))
Both placements appear to work for lookup, since `org-collect-keywords'
collects COLUMNS keywords from the buffer, not only from the very
beginning. Still, since #+COLUMNS is a file-level setting, inserting it
before plain introductory text might be more natural.
Another possible policy would be to insert it after an initial block of
file-level keywords, i.e. after consecutive keyword lines near
`point-min' before the first non-keyword, non-blank line:
#+TITLE: Notes
#+AUTHOR: Me
#+COLUMNS: %TODO
Intro
* H
This would keep COLUMNS with other file-level settings without moving it
past ordinary introductory text. It is a bit more complex than simply
inserting at `point-min', though, and I am not aware of an existing Org
helper that implements exactly this insertion policy.
My current refactoring keeps the existing behavior unchanged and adds a
test for it. Before relying on that test, I would like to confirm whether
the current insertion point is intentional and should be preserved, or
whether new #+COLUMNS keywords should instead be inserted at the
beginning of the buffer, or after an initial file keyword block.
Best,
--
Slawomir Grochowski
