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

grep with hierarchical context #21

Open
cben opened this issue Dec 16, 2017 · 7 comments
Open

grep with hierarchical context #21

cben opened this issue Dec 16, 2017 · 7 comments

Comments

@cben
Copy link
Owner

cben commented Dec 16, 2017

Various unix tools treating input files as flat and could use some understanding of their actual hierarchical structure. There have been a few attempts, mostly specializing on xml.
But, for many purposes, there is much simpler yet almost universal indicator structure – indentation!

Specifically I'd most like it in grep or ag / rg.
There should be an option to include not just the matching line(s) but also the chain of "parent" lines with lesser indentation.

  • https://github.com/mbrubeck/outline-grep implements this, but is an independent implementation, gives up much of the power.
  • contribute such an option to ag / rg?
  • a post-processor, which given /file/names:linenum:text format input, finds the input file and adds missing context?!
    • benefit is it combines with almost any grep/ag uses (as well as other tools like lint warnings...).
    • drawback is it must be existing files, pipeline | grep ... | tool-to-add-context won't work.
@cben
Copy link
Owner Author

cben commented Dec 24, 2020

I really want a terminal pager (like less) with folding and incremental search!

It's useful to see both parents and descentant context, and to fold/unfold dynamically, which are better as view filtering rather than re-running a pipe with new command-line flags.

  • Keeping parent lines in view is useful even with regular scrolling of the whole text, without any search.
    This is validated by the very useful https://github.com/python/cpython/blob/master/Lib/idlelib/codecontext.py, invented by Noam Raphael:

    CodeContext3

  • Combine that with search and next/prev buttons already gives a not-bad view with both parents and some descentant context.

  • Once I have infrastructure to show non-contiguous subset of lines (necessary anyway for CodeContext),
    it's becomes possible and handy for search to show less context around each match, fitting more matches into the view.

  • Could also use it for viewing unified diffs with variable context but that's getting too far ahead...

    • Evidence that collapsing is useful: GitHub/GitLab code reviews basically show diff -u --context but you can dynamically reveal more context — which I do, every day!
      Same way, grep --context would be better as a pager where you can collapse/reveal more context...

@cben
Copy link
Owner Author

cben commented Mar 14, 2022

JSON/YAML-specific stuff

  • https://github.com/tomnomnom/gron — maps hierarchy <-> flat key/value lines.
    Allows omitting boring parts of subtrees using pipelines like gron | grep --context=2 'inKey|in.a.path|inValue' | gron -u.

  • https://github.com/antonmedv/fx — interactive viewer with whole-subtree collapsing, search

    Written in JS, slow, looks like naive full terminal repaint? But might be easy for POC?

  • https://jless.io/user-guide.html — interactive viewer with whole-subtree collapsing, whole-subtree-as-a-string search, and some intelligent sibling-navigation.

    Written in Rust, looks best-in-class, would love to extend it a bit.

  • Display arrays horizontally?!

    A major use case of JSON is an array-of-structs, and a 2D table-like view for them is desirable. kubectl get ... and many other tools transform them into vertically aligned table-of-lines ⩸ but that's too limiting. It was natural fit for ⭭ teletype order of stdout — but given interactivity, I'd rather keep structs vertical {⢽🠃} to let many key names fit, and let arrays scroll horizontally [🠒,⢽,⢽,🠒] so I can see structs side-by-side, aligned on matching keys.

@cben
Copy link
Owner Author

cben commented Apr 18, 2022

https://github.com/Canop/broot implements this paradigm excellently for file hierarchies.
It fills one screen intelligently and, keeps hierarchy visible while filtering 🥇

@cben
Copy link
Owner Author

cben commented Oct 11, 2022

VSCode implemented "StickyScroll" option 🎉
https://code.visualstudio.com/updates/v1_70#_editor-sticky-scroll
Based on language server outline info, apparently with fallback to indentation/folding info (?): microsoft/vscode#157165

@ligvigfui
Copy link

Hi @cben, can we have an option to use the indentation as default instead of the language server outline info.
Thanks in advance

@cben
Copy link
Owner Author

cben commented Nov 19, 2022

I was not involved in any way with the VSCode implementation. I'm just happy it exists (and probably won't work on similar support anywhere else in the near future).

@cben
Copy link
Owner Author

cben commented Sep 27, 2024

In Emacs there are 2 obvious approaches to implementing something like this:

  1. A window may have (just one) "header line". Some packages like https://github.com/kuanyui/cakecrumbs.el or https://github.com/alphapapa/topsy.el use this to show context. topsy even syntax highlights the line, but still it's not 100% a real line - you can't click it and edit, search matches don't highlight there etc.

  2. Hide intervening line by marking them invisible.
    This sounds better but I'm not sure at all it can be window-local —for case of multiple windows showing different views of same buffer(?)

  3. Fake (1) it by separate buffer shown above current window? I think that'd suffer from same "not real lines" limitations as (1) — except being able to show multiple context lines. (It's also hard in practice to maintain constrained window formations in emacs)

Anyway, I'm starting to use topsy, strictly better than nothing. It's not indentation-based though. (Focusing on current function is not bad signal-to-noise choice given 1 line constraint)

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

No branches or pull requests

2 participants