I must say I find the new "port search" output format that's in trunk very hard to read. Before, we had roughly a table, and I could scan down the left column to read the port names. Now the description is in roughly the same place -- albeit indented by a couple spaces but it still interferes with my ability to scan the left column, which is no longer a column.
Ryan Schmidt wrote:
I must say I find the new "port search" output format that's in trunk very hard to read. Before, we had roughly a table, and I could scan down the left column to read the port names. Now the description is in roughly the same place -- albeit indented by a couple spaces but it still interferes with my ability to scan the left column, which is no longer a column.
I found it unreadable before. The old format used a scheme which did not work with any terminal size. If your window was smaller than the description, it was wrapped to the next line. So there wasn't a clear first column before either, because the descriptions were 'too long'. So I decided to use an output format which will work on any terminal size with at least 80 columns (the often used standard). And with a break at 80 chars also longer descriptions are nice to read. Maybe we could also put the version and categories in a new line, so there will be always the first line of a output block with the port's name and nothing else? Rainer
It should be customizable, using some sort of format string. - Jordan On Mar 20, 2008, at 4:01 PM, Rainer Müller wrote:
Maybe we could also put the version and categories in a new line, so there will be always the first line of a output block with the port's name and nothing else?
Maybe something along the lines of the "w" option to ps? Or a verbose flag that turns on/off the descriptions? -Bill On Mar 20, 2008, at 4:01 PM, Rainer Müller wrote:
Ryan Schmidt wrote:
I must say I find the new "port search" output format that's in trunk very hard to read. Before, we had roughly a table, and I could scan down the left column to read the port names. Now the description is in roughly the same place -- albeit indented by a couple spaces but it still interferes with my ability to scan the left column, which is no longer a column.
I found it unreadable before. The old format used a scheme which did not work with any terminal size. If your window was smaller than the description, it was wrapped to the next line. So there wasn't a clear first column before either, because the descriptions were 'too long'.
So I decided to use an output format which will work on any terminal size with at least 80 columns (the often used standard). And with a break at 80 chars also longer descriptions are nice to read.
Maybe we could also put the version and categories in a new line, so there will be always the first line of a output block with the port's name and nothing else?
Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337
William Siegrist wrote:
Maybe something along the lines of the "w" option to ps? Or a verbose flag that turns on/off the descriptions?
Hm, we could remove the descriptions by default and only show it in verbose mode. Although, then users might miss the descriptions at all? If you only want the port names without version information or descriptions, you can already use `port -q search`. Rainer
On Mar 20, 2008, at 20:23, Rainer Müller wrote:
William Siegrist wrote:
Maybe something along the lines of the "w" option to ps? Or a verbose flag that turns on/off the descriptions?
Hm, we could remove the descriptions by default and only show it in verbose mode. Although, then users might miss the descriptions at all?
If you only want the port names without version information or descriptions, you can already use `port -q search`.
No, I don't want any of that, I just want what we had before. :) I agree it got to be a mess when descriptions were longer than the terminal window, which is why I have a shortcut to maximize a window, and use it often in the terminal. A better solution would be intelligent word wrapping in the software, so thank you for implementing that. But it would be better if we could keep the 3- column format we had before, and just wrap the description within that third column if necessary.
Rainer Müller wrote:
Ryan Schmidt wrote:
I must say I find the new "port search" output format that's in trunk very hard to read. Before, we had roughly a table, and I could scan down the left column to read the port names. Now the description is in roughly the same place -- albeit indented by a couple spaces but it still interferes with my ability to scan the left column, which is no longer a column.
I found it unreadable before. The old format used a scheme which did not work with any terminal size. If your window was smaller than the description, it was wrapped to the next line. So there wasn't a clear first column before either, because the descriptions were 'too long'.
Work out the width of the terminal `tput cols', default to 80 if you can't figure it out, and work from there (test first if it is a tty, of course, if not output can be as verbose as you like, it's either going to a file or a pipe). Peter -- Peter O'Gorman http://pogma.com
Ryan Schmidt wrote:
No, I don't want any of that, I just want what we had before. :)
You really just want to revert back to the old messy format?
I agree it got to be a mess when descriptions were longer than the terminal window, which is why I have a shortcut to maximize a window, and use it often in the terminal. A better solution would be intelligent word wrapping in the software, so thank you for implementing that. But it would be better if we could keep the 3- column format we had before, and just wrap the description within that third column if necessary.
So you use a workaround with maximizing the window for you personally. Why use a workaround instead of fixing it by using a new output format? Should we add a line like "Please maximize your terminal window if you want readable output" to the guide? Please not! New word wrapping wouldn't help in the old format. The third column would not become more readable in a 80 columns terminal. There is not even a 'third column' in the old output, the description just starts anywhere. Also the path to the Portfile is totally unnecessary, categories are a much more important information. Developers can use `port dir` to find the path. And in general the path is always $category/$name. For example the old output: $ port search python dbus-python24 devel/dbus-python24 0.82.2 Python bindings for the dbus message bus system. dbus-python25 devel/dbus-python25 0.82.4 Python bindings for the dbus message bus system. gnome-bindings-python devel/gnome-bindings-python 2.12 The GNOME bindings for Python ice-python devel/ice-python 3.2.1 Fast, object-oriented RPC for C++, Java, Python, Ruby, PHP subversion-python24bindings devel/subversion-python24bindings 1.4.6 Python bindings for the subversion version control system. ... And now the new output: $ port search python dbus-python24 @0.82.2 (devel) Python bindings for the dbus message bus system. dbus-python25 @0.82.4 (devel) Python bindings for the dbus message bus system. gnome-bindings-python @2.12 (devel, gnome) The GNOME bindings for Python ice-python @3.2.1 (devel, python) Fast, object-oriented RPC for C++, Java, Python, Ruby, PHP subversion-python24bindings @1.4.6 (devel, python) Python bindings for the subversion version control system. ... And you really want that old mess back? I am open for improvement to the new format, but I am clearly against reverting back to the old format. I changed the format because it was so unreadable and annoyed me that much. Rainer
participants (5)
-
Jordan K. Hubbard
-
Peter O'Gorman
-
Rainer Müller
-
Ryan Schmidt
-
William Siegrist