Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

only search subheaders if a header is focused #517

Merged
merged 4 commits into from
Oct 19, 2020

Conversation

tarnung
Copy link
Collaborator

@tarnung tarnung commented Oct 18, 2020

Issue #246

When a header is focused, should there be an indication in the search modal that search is limited?
I think it's ok as a standard behaviour without notification but not everyone might agree.

@munen
Copy link
Collaborator

munen commented Oct 19, 2020

@tarnung Yet another great feature contribution 🙏

When a header is focused, should there be an indication in the search modal that search is limited?
I think it's ok as a standard behaviour without notification but not everyone might agree.

I also think it's the appropriate behavior. In Emacs, when you narrow a buffer (that's not even Org specific functionality), then what you see is what search and edit operates on whilst the remainder of the buffer is 'out of sight, out of mind. As for an indication, imo none is needed. Sane defaults with good docs should suffice.

I've added an integration test, updated the documentation and added your contribution to the changelog.

Great work 🙏 🙇

@schoettl
Copy link
Collaborator

Nice feature! For me "header is focused" sounds like the header is selected (i.e. toolbar and details are visible). But it actually means header is in "focus mode" or "sub-tree mode". So IMO the documentation is not perfectly accurate. But sorry that I'm not providing a better alternative / PR right now..

@munen
Copy link
Collaborator

munen commented Oct 20, 2020

@schoettl Very good point, thank you for bringing it up! We could adopt the Emacs nomenclature of 'narrow' and 'widen': https://www.gnu.org/software/emacs/manual/html_node/emacs/Narrowing.html

Thb, I'd rephrase to we 'should' adopt. There's no reason to diverge on the naming from Emacs if we're duplicating an exact feature - unless there is a reason, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants