Option to have header based on cursor (point)

[mankoff]

org-sticky-header seems to show the header that is at the top of the buffer but off-frame, not the header under the point. For example

• Foo lorem ipsum ----------------- begin frame lorem ipsum
• Bar lorem ipsum
• Baz lorem ipsum ---------------- end frame
• qux lorem ipsum

In this case, org-sticky-header displays foo. It would be nice if it could (optionally) display bar instead. I can provide a screenshot if needed.

[alphapapa]

The purpose of this package is to display the heading which has scrolled off the screen so it's clear which heading text belongs to.

Headings that are visible on the screen are visible, so what would be the purpose of displaying them additionally in the header? That would also be visually confusing, as the text at the top of the buffer would appear to be under the wrong heading.

[mankoff]

The purpose for displaying visible headings at the top is, for me clarity. If I have an Org doc with many sub (and sub-sub) headings each with a small amount of content, varying color content (a line of text, a babel header and footer, and a line of code), small font and a big monitor, then the headings get lost among all the other text. Glancing at the top to see what section I'm in is faster than scanning the doc (same reason the global menubar is a better UI feature than window-level menu bars).

But the easy solution is to change the theme so that sections stand out more strongly. I'll do that.

Thanks for another nice package!

[alphapapa]

Thanks for the explanation. I've seen quite a few Org screenshots in which headings tend to blend in to the rest of the document.

In my config, I use heading faces that stand out, and I keep blank lines between headings and other content, which helps a lot.

I think this raises the need for a new package that highlights the current heading in the buffer directly. It should be simple, probably using an idle timer on a short delay that moves an overlay on top of the heading that the point belongs to, making it more visible.

Anyway, having read your explanation, I agree that such a feature in this package could be helpful, and it ought to be easy to implement, so why not? :) I don't know when I'll work on it, but I'll put it on the to-do list.

[yalfg]

Thanks for the package! I agree with @mankoff, I also prefer to see the current entry. With a full path display, which is what I use, the last element may be visible and redundant as you says but the rest of the path is still useful. And in practice on a high display with many small entries the top of the window may be simply not relevant to what I'm doing right now. Still, it's a matter of taste so why not make it configurable?

To show the current location, for now I just commented out the (goto-char (window-start)) at the start of org-sticky-header--fetch-stickyline, and it seems to work fine. So why not something like:

(defcustom org-sticky-header-at-point nil
   "When set, show the header where the point is. When nil, show the header at the top of the window."
  :type 'boolean)

Then in org-sticky-header--fetch-stickyline:

(unless org-sticky-header-at-point
  (goto-char (window-start)))

Thanks!

[TeMPOraL]

Seconding this request. I've been using this package for years (many thanks for creating it!), and found wishing for the behavior described in this issue. Most of my Org files have hierarchies that span more than one screen, and usually the most important information I need is the full path to the place where point is.

Note this would be similar to how similar header-line paths are shown in programming contexts (e.g. in lsp-mode) - they show you the path in the structure to the symbol/structure you're currently editing (i.e. where the point is).

[Ypot]

The purpose of this package is to display the heading which has scrolled off the screen so it's clear which heading text belongs to.

Headings that are visible on the screen are visible, so what would be the purpose of displaying them additionally in the header? That would also be visually confusing, as the text at the top of the buffer would appear to be under the wrong heading.

Hi! As the text, where the cursor is at, doesn't necessarily belong to the headline that's top of the screen, I second the suggestion.

Maybe this function would help? org-display-outline-path Best regards, and thanks for this nice package.