[RFE] Truncating / aligning long descriptions

[t184256]

Currently descriptions wrap to the next line,
wasting almost half the lines on description endings
that also make it harder to visually scan the left column for results.

Actual results:

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for Moonligh
t
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's Game
Stream
moonlight           1.3.9            Discord client modification, focused on enh
ancing user and developer experience

Expected results with column wrapping (which also makes the wasted space more obvious):

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for Moonligh
                                     t
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's Game
                                     Stream
moonlight           1.3.9            Discord client modification, focused on enh
                                     ancing user and developer experience

Expected results with truncating (which I'd like to see by default):

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for Moonlig…
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's Gam…
moonlight           1.3.9            Discord client modification, focused on en…

[OleMussmann]

Thanks for the idea @t184256 . It's an interesting one and I'm not sure yet what the best path forward is. Some thoughts from the top of my head:

• You can omit the description column altogether with -C=version without reducing listed packages
• Your column wrapping idea looks better than the current output
• Truncating looks neatest, but hides information
  • Maybe even better with breaking on existing whitespace, instead of chopping words in half?
• nix-env -qaP --description PACKAGE_NAME opens a pager if the line is too long
  • Benefit: horizontal scrolling reveals hidden information
  • Drawback: needs an extra keypress to exit, even if you don't scroll; color will probably get lost

[t184256]

You can omit the description column altogether with -C=version without reducing listed packages

Yeah, that's what I'm currently doing (with an envvar). But the screen space is there, unused.

Your column wrapping idea looks better than the current output

Is it possible that column wrapping will eat into a third line? If the answer is "no", or "that'd happen virtually never", the only downside I can think of is copy-pasting descriptions would become harder. Which doesn't sound that bad to me.

Maybe even better with breaking on existing whitespace, instead of chopping words in half?

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for
                                     Moonlight
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's
                                     GameStream
moonlight           1.3.9            Discord client modification, focused on
                                     enhancing user and developer experience

Why not.

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for…
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's…
moonlight           1.3.9            Discord client modification, focused on…

IMO, this one was better with ellipsizing mid-word.

nix-env -qaP --description PACKAGE_NAME opens a pager if the line is too long

Unpredictably? Sounds horrible.
Not knowing in advance whether one needs to q or not breaks the flow.

Here's another brainstorming-grade idea:
if reading descriptions is not the goal of the project,
then they can be aggressively truncated to the terminal width.
But if you don't want to reject that as a goal
in case someone actually will be using nps to read descriptions
(because, let's admit, it's a quick and ergonomic way to),
maybe just the one for exact match can be printed in full:

$ nix run github:OleMussmann/nps -- -edd -s=false moonlight
sunshine            2025.122.141614  Sunshine is a Game stream host for Moonlig…
moonlight-qt        6.1.0            Play your PC games on almost any device
moonlight-embedded  2.7.0            Open source implementation of NVIDIA's Gam…
moonlight           1.3.9            Discord client modification, focused on
                                     enhancing user and developer experience

[OleMussmann]

Thanks for the brainstorming, I really appreciate it.

Is it possible that column wrapping will eat into a third line?

Absolutely. Your terminal size might even be smaller than "package_name" + "version". So column wrapping would only reliably work for "medium" terminal sizes. Bummer.

IMO, this one was better with ellipsizing mid-word.

Agreed.

Unpredictably? Sounds horrible.

Yes and yes. I mean, it is visually obvious when that happens. But it's still not a great user experience.

maybe just the one for exact match can be printed in full

I like the idea to have full information for the match that matters the most, but the general limitations of column wrapping, as described above, count here as well.

I'm warming up to your idea of optionally ellipsizing. Maybe even anything (not just the description) that is longer than the terminal width. Settings could look like this:

# short help

-q, --quiet[=<QUIET>]    Truncate long lines to terminal width [env: NIX_PACKAGE_SEARCH_TRUNCATE=] [default: false] [possible values: true, false]

# long help

-t, --truncate[=<TRUNCATE>]
          Truncate long lines to terminal width
          [env: NIX_PACKAGE_SEARCH_TRUNCATE=]
          [default: false]
          [possible values: true, false]

# env settings

NIX_PACKAGE_SEARCH_TRUNCATE
    Truncate long lines to terminal width?
    [default: false]
    [possible values: true, false]

This crate seems mature enough and has the needed platform support: https://github.com/eminence/terminal-size It fails on some Windows terminals, but it's detectable when that happens and we can then disable truncating in the worst case.

[t184256]

Your terminal size might even be smaller than "package_name" + "version". So column wrapping would only reliably work for "medium" terminal sizes. Bummer.

Right, guess there's not much point bothering with column wrapping unless it's at least (arbitrary number around 40)?

> Unpredictably? Sounds horrible. Yes and yes. I mean, it is visually obvious when that happens. But it's still not a great user experience.

Plus, with the most relevant information gravitating to the bottom, triggering pagers will become extra awkward. Let's maybe drop autopaging from considerations.

> maybe just the one for exact match can be printed in full I like the idea to have full information for the match that matters the most, but the general limitations of column wrapping, as described above, count here as well.

Agreed.

I'm warming up to your idea of optionally ellipsizing. Maybe even _anything_ (not just the description) that is longer than the terminal width.

To some sane limit, yes. Maybe if the term is too narrow even for the names column, then the entire idea of columns is unsalvageable anyway => turn truncating/wrapping off? And, I guess, users of very narrow terminals can pipe into a pager and scroll in 2D?

[specific implementation details, libraries suggestions etc]

I trust you with specifics. To sum up the distinct-yet-intertwined 2.5 ideas in this thread: 1. Truncating and ellipsizing: at terminal width mid-word, configurable orthogonally in addition to NIX_PACKAGE_SEARCH_COLUMNS because you want it to cover version as well. Eating into names is, IMO, counterproductive. Piping output into pagers should disable it. 2. Column wrapping of descriptions: only makes sense when there's space for it, which is an underdefined condition at this point. Theoretically can be an extra value for NIX_PACKAGE_SEARCH_COLUMNS (=description-unwrapped?). Hinders copy-pasting descriptions. Helps scan the names column, but so does ellipsizing, so maybe it's not that important if ellipsizing is implemented? 3. Not truncating but wrapping the exact match description: sounds like a good idea, but depends on wrapping being implemented. Maybe it should've been two tickets. =)

[OleMussmann]

Since those ideas are closely related and aim to solve the same problem, I'm happy to have the brainstorming in one place.

I'm on board with 1. as you stated. I will park it until there's clarity about other approaches to prevent unnecessary refactoring.

For the column wrapping I'm still doubting. The boundary conditions of triggering it are still somewhat murky. I'm not sure if the benefits outweigh the complexity added to the code. Copying lines becomes more difficult. I have not seen it implemented in other applications, so there's little precedence for it. Actually, dnf seems to do that:

I would need to spin up a VM and play with it to see how it behaves and how that feels. [Edit: Can't reproduce. Maybe it does not exist anymore? Or it's a special setting? Out-of-the-box it seems to just "normally" wrap long lines.]

---

To throw yet another idea into the ring, apt search has two+ (or rather three+, including separator) lines per package:

This almost triples the amount of vertical space needed, but does leave more room for descriptions. Truncating can be combined with this. I would not want it to trigger automatically (least surprises), but maybe as an optional setting.

Similar with pacman, but then without the empty line in between:

---

Just for completeness' sake, zypper truncates:

Most other package managers I have checked just have long lines that wrap at the terminal boundary.

[OleMussmann]

Sorry @t184256 , it took me a while. The development branch now has -t | --truncate and -m | --multi-line flags. If you have the time, could you test those a bit?

Some remarks:

• Contrary to the discussions above, I implemented the truncation over the whole line: no preservation of package names or version numbers. The reason for this is to keep it "simple".
• I forgot how involved it is to work with non-ascii text in Rust. Package descriptions have all kinds of special characters, like Japanese or emojis. These can consist of a various number of bytes and occupy a various number of spaces on the terminal screen. Getting this right is harder than I thought.
• The naive implementation that catches all the edge cases (like not going up in flames when trying to cut an emoji in half, etc.) is horrible for performance. There are currently many unnecessary loops. It is, however, not noticeable in real-world applications, so I might leave it for now and open an issue to improve that at some point in the future.

[t184256]

$ result/bin/nps mangas -m
manga-cli  2022-04-11
    Bash script for reading mangas via the terminal by scrap
ing manganato

komga  1.20.0
    Free and open source comics/mangas server

I don't get that -m, it goes against everything I'm after: wastes a lot of vertical space and doesn't make the result more column-scannable. I'd at least indent the entire description. But maybe I'm just not the target audience.

$ result/bin/nps mangas -t
manga-cli  2022-04-11  Bash script for reading man…
komga      1.20.0      Free and open source comics…

$ result/bin/nps treesitter-parser-cpp -t
luajitPackages.luarocks-build-treesitter-parser-cpp  2.0.4-1  A luarocks build …
luaPackages.luarocks-build-treesitter-parser-cpp     2.0.4-1  A luarocks build …
lua54Packages.luarocks-build-treesitter-parser-cpp   2.0.4-1  A luarocks build …
lua53Packages.luarocks-build-treesitter-parser-cpp   2.0.4-1  A luarocks build …
lua52Packages.luarocks-build-treesitter-parser-cpp   2.0.4-1  A luarocks build …
lua51Packages.luarocks-build-treesitter-parser-cpp   2.0.4-1  A luarocks build …

Now that -t is very much what I've asked for, I can easily see it becoming my default! Surprisingly usable even on narrow terminals or with ridiculously long package names, and I think it's fine without the name/version preservation. Emoji seem to be truncated correctly in my testing.

Maybe the one extra thing I'd wish for would be highlighting truncated matches. Basically, in the mangas example above, I'd like to see man… highlighted, the ellipsis included, for mango-cli, and maybe just the ellipsis alone for komga if the match got truncated in its entirety.