search

vn971 / rua

Build tool for Arch Linux providing control, review and jailed build options
GNU General Public License v3.0
427 stars 41 forks source link

Full package names on search #97

Closed kaphula closed 4 years ago

kaphula commented 4 years ago

When search is used to display a list of available packages, there's a chance that the search will find a package with so long name that it won't fit in the search results. Is there any easy way for the user to find out what is the full name of the package that gets hidden so he/she can install the package using rua?

For reference, searching for packages with: rua search timer gives couple results with too long package names.

vn971 commented 4 years ago

@kaphula with the current code it's not possible to configure. I did stumble across a similar thing recently, and changed the constant: https://github.com/vn971/rua/commit/77f427f1403ac0352cc81b58457ff98b85ec96c6 There weren't any releases with this commit yet, but should happen soon.

If you want to work on making it configurable, and also have ideas on how to do that (there are many ways possible), please write.

vn971 commented 4 years ago

Would you be willing to work on such a feature?

P.S. I've made a new release.

kaphula commented 4 years ago

I could dive in to this once I get a chance with some free time. This would be a good chance to learn some Rust I guess.

I think there are few ways to approach this. I assume the trunc constant is needed in order to keep the lines aligned with the following version and description.

You could just loop through the searched packages once and see which one of them is longest and use that length as the trunc constant. It seems that if the description of a package reaches the right edge of terminal the description will break to the next line. Since this how the program behaves currently, adding a longer trunc constant would just cause the description to extend on the next line more often. This should be the easiest fix to implement for now.

Another way could be just using the package name's length as the trunc constant when the length is larger than the preset constant value. Since the searched packages are not sorted by name (it seems), the breaking of the alignment could be alleviated by listing the long package names in the very end of the list.

vn971 commented 4 years ago

@kaphula one thing you can easily do as well is just not use the trunc function at all. This might lead to some weird results for super-long package names, but maybe it's all right.

see which one of them is longest adding a longer trunc constant would just cause the description to extend on the next line more often

Taking the longest value is already the table printing library behavior actually. trunc was only used to limit it. You can test with some short-named packages to see that it trunc only sets the upper limit, not the lower, e.g. rua search aur rua or rua search monitor calibration.

Packages are currently listed by their popularity.

vn971 commented 4 years ago

So as far as I see, the alternatives are:

I think I'll be fine with the first approach. But if you want to try yourself out on e.g. the third, that's certainly an option as well.:)

kaphula commented 4 years ago

What do you think about this approach:

terminal_width is supposed to represent one full row of characters before line break occurs on a generic terminal widow. I am not sure what the global terminal width standard is, 72 or 80 maybe? The formula is used to calculate maximum trunc value for description so that the line break will not trigger.

The condition (if) exists simply to allow a way to view the full description somehow. Searching the desired package with its full name returns a package listing containing only 1 package, and this is when the package description will be shown in its entirety.

EDIT: Actually it seems that information about the table structure as characters is needed in order to calculate the correct number of characters for the description.

EDIT 2:

I made some quick tests and here are the results for a terminal window with a width of 80 characters:

a

  1. Here's a test where package name is displayed fully, version is truncated to 14 characters and the remaining space on the row is left for the description.

e

  1. Here the package name and description are being displayed fully. I am thinking it might be best if this was the default behaviour since having full description is very useful when you are exploring for potential applications to solve some problem.

It would be nice to have an option to display the packages as seen in the first image using extra parameters. It's up to you how and what the extra parameters would be in the search command. I'd need to study more about the command line arguments and how to use their values inside print_package_table function if I were to implement them, though.

vn971 commented 4 years ago

Sorry for the late response, I was quite busy in the last days. I'm certainly fine with the first two steps (no limit at all for name, limit for version).

On the last proposal of limiting description, I'm not sure. Maybe we should instead look into something like this?: https://github.com/vn971/rua/pull/36 This is an already merged branch, so we actually have the code already in place. We can maybe adapt it to work with more than 2 columns? I'm not sure, needs actual checking of how the code works. Do you find the formatted result in this PR nice BTW (I really do, but curious on your input as well)?

It would be ideal to make it somehow configurable, e.g. rua show --format="FORMAT_STRING", but even some hardcoded alternatives might be worth it for a start.

Also, optionally, such a table printing code might be moved to a separate crate. Currently, we use prettytable crate. It has a lot of limitations, though. Maybe we can do better? With all the benefits of a separate crate, like re-usability across other Rust projects. What do you think?

vn971 commented 4 years ago

@kaphula Or to clarify, if you'd be willing to work on the "column approach" as in that other PR, it can be merged as-is I think, without a separate CLI flag. For the more advanced approaches, some CLI configuration would be nice of course.

kaphula commented 4 years ago

I think the column approach looks good seen in https://github.com/vn971/rua/pull/36, especially in the first screenshot. I also agree with you that the pacman's search results are unreadable.

So should the search output look something like this where description gets its own cell with unlimited height:

| name         | version... | description |
                              description
                              description
                              description
| longer__name | version... | description |
                              description
...

For the time being, I am not the right person to implement these features and changes, because my Rust knowledge is very lackluster. My changes seen in the screenshots were only quick hacks inside the print_package_table function. The results seen in the 2nd image should be achievable simply by removing the truncating of name, so that's a quick fix and can be implemented by anyone. That being said, I can take part in the discussion and join the development once I get some deeper understanding of things work in the source code.

vn971 commented 4 years ago

The results seen in the 2nd image should be achievable simply by removing the truncating of name, so that's a quick fix and can be implemented by anyone.

Yeah that's true. On the other hand, it's just sometimes fun to collaborate.:) Will probably do it after 4hours from now, if you won't.

A separate library to print tables would possibly be nice for the Rust ecosystem. Some day in future...

vn971 commented 4 years ago

closing as the biggest issue (truncated package names) is now fixed. Would still be nice to have the "column" approach in future though...