Org <8.3.5 unsupported
angrybacon opened this issue · 17 comments
Here is the file I tested it with.
https://raw.githubusercontent.com/angrybacon/dotemacs/master/dotemacs.org
(use-package org
:init
(add-hook 'org-mode-hook 'org-sticky-header-mode))
(use-package org-sticky-header
:config
(setq-default org-sticky-header-full-path t))
Thanks, I'll look into this soon.
Looks like when the top-most line in the window is a org-heading (any level), the header line empties out.
This seems to work fine for me:
(defun org-sticky-header--fetch-stickyline ()
"Make the heading at the top of the current window sticky.
Capture its heading line, and place it in the header line.
If there is no heading, disable the header line."
(save-excursion
(goto-char (window-start))
(when (or org-sticky-header-full-path ; FIX
(not (org-at-heading-p))) ; FIX
(org-back-to-heading)
;; TODO: 3 spaces seems to be almost right, but it's still not
;; perfect, and it's probably not universally right. Something
;; related to org-indent might be good.
(if org-sticky-header-full-path
(org-format-outline-path (org-get-outline-path t) nil " ")
(concat " " (buffer-substring (line-beginning-position) (line-end-position)))))))
Looks like when the top-most line in the window is a org-heading (any level), the header line empties out.
@kaushalmodi Yes, this is intentional, to avoid having the heading displayed on two consecutive lines, once in the buffer and once in the header. Would you actually prefer that to be the case? It could be made optional.
@angrybacon I just pushed some updates, and as far as I know, this is working correctly. Please let me know if not.
Thanks for your feedback.
this is intentional, to avoid having the heading displayed on two consecutive lines, once in the buffer and once in the header. Would you actually prefer that to be the case? It could be made optional.
It would be great to have this as an option.
It makes sense to me to always show the headings in the header line if the option to show the full path is set, because while the heading can be 2017-04-18
, the header can still show the full path 2017 > 04 > 2017-04-17
. Well that's not the best example, but it shows that for the full path case, the header line and the actual heading can show different information.
Great point, I didn't think of that. Let me add that...
Thanks for your feedback!
Thanks for the package and quick updates!
@alphapapa Sorry I couldn't get to test things until now.
It's still not functionnal for me. I'm using org-sticky-header-20170420.2114
. with the following setups:
emacs
(use-package org
:defer t
:init
(add-hook 'org-mode-hook 'org-sticky-header-mode))
(use-package org-sticky-header
:defer t
:config
(setq-default org-sticky-header-full-path t))
emacs -q
(require 'org-sticky-header)
(org-sticky-header-mode)
(setq org-sticky-header-full-path t)
- Header shown at all times until I set
org-sticky-header-full-path
tot
(that's good) - Once I set it to
t
, nothing is shown in the header-line
Am I missing something?
You now need to set
(setq org-sticky-header-full-path 'full)
as there's another full path option too:
(setq org-sticky-header-full-path 'reverse)
@alphapapa @kaushalmodi Thought I had something funky going on because of desktop.el
, restarted to make sure. With emacs -q
and without setting any variables:
- Evaluate
org-stick-header.el
(require 'org-sticky-header)
M-x org-sticky-header-mode
The header-line stays empty.
@angrybacon Thank you, I forgot to require cl-lib
for the typecase
call. I would not have noticed this without your help! :)
@alphapapa The default works now thanks. 👌
However (setq-default org-sticky-header-full-path 'full)
still makes the header-line empty. Same thing for 'reverse
. I get this in *Messages*:
Error during redisplay: (eval (list (propertize " " (quote display) (quote ((space :align-to 0)))) (org-sticky-header--fetch-stickyline))) signaled (wrong-type-argument number-or-marker-p nil)
It looks like org-get-outline-path
changed its arguments in February of 2016, and that appears to have been released in Org 8.3.5. Are you using a version older than that? I recently upgraded from 8.2.4 to 9.0.5, so I'm sympathetic, but I'm not sure I want to try to support versions older than that by working around this change. If you can't upgrade for some reason, I'll consider trying to work around it. In the meantime, I'm setting the minimum Org dependency to 8.3.5, so that should at least prevent users on older versions from hitting the bug.
Let me know what you think. Thanks for reporting, I wouldn't have noticed this otherwise.
@alphapapa Will look at it this weekend. It's actually not straightforward to load latest Org with a somewhat exotic babel-based configuration.
@alphapapa Got it work with Org 9.0. Thanks for your dedication. 👍
Edit: I don't think it is absolutely needed to support Org < 8.3.5. It's about time I got around upgrading anyway. I did close the issue without thinking, feel free to reopen it to increase visibility.
Great! I hesitated for a long time to upgrade to Org 9, because 8.2.4 was doing everything I needed, and I didn't want to invest the time to fix all the little things that changed and broke. But I'm glad I finally did. Thanks for your help.