inxi output hard to read on 80 character wide terminal

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start a terminal that's 80 chars wide
2. run inxi -F
3.

What is the expected output? What do you see instead?

expected nicely lined up output, easy to read.

Instead, the first line wraps around and part of the text is under the 'System' 
column

What version of the product are you using? On what operating system?


Please paste your inxi output below.

Please paste your 'cat /proc/cpuinfo' output below.

please paste your 'cat /proc/meminfo' output below.

please paste your 'sensors' output below.

Original issue reported on code.google.com by svsam...@gmail.com on 21 Aug 2012 at 5:17

[GoogleCodeExporter]

inxi -h suffers from the same problem; too wide text on the default width of 
80.  The help output is a little cluttered, some whitespace could help too.  A 
well-chosen example would be good too - took me a while to figure out that -F 
was what I need to get 'lots of info' 

Original comment by svsam...@gmail.com on 21 Aug 2012 at 5:18

[GoogleCodeExporter]

This is 2012, 80 character line limits are something from the ancient past, 
which for some reason persist in certain scenarios, no idea why, I don't see 
them much anymore on any web server I use for example.

However, because I realize that some people like to use these short lines, inxi 
comes with the ability to change the default line lengths:
http://code.google.com/p/inxi/wiki/script_configuration_files

For both terminal and irc. 

Be warned however, since implementing that per line is kind of tricky, not all 
the lines do it quite right, or at all, but if there is a line that isn't 
right, and if the patch matches the built in line length functions and methods, 
I'll happily add such a patch to inxi, as long as it makes sense. But 
somethings are hard to wrap, like super long distro names, long hardware names, 
and so on, not predictable.

Inxi -h won't be changed, I'm sorry, but really, where in the world are you 
actually limited to such a tiny screen in the real world as a normal scenario? 
ssh is the width of my terminal, which is the width I set it to be, out of x 
console is much more than 100 characters wide. I'm sure there are some legacy 
areas left in the world where super narrow console output is still a standard, 
of course, I just don't see them myself.

I do try to keep the lines somewhat short on the output end, about 115 
characters I think it is. 

And of course, the inxi man page fits the size of the view screen, ie, it 
autowraps, so that's standard for man pages.

Original comment by inxi-...@techpatterns.com on 24 Aug 2012 at 7:25

• Changed state: Invalid

[GoogleCodeExporter]

First of all, let me say that I would have liked 80 chars wide not be the 
standard too.

But wishing and reality are different things.  If you say 'no idea why' it's 
because You Want To Believe.

I just started gnome-terminal and xterm, both default to 80 chars wide.  For 
every program you can give me whose -h is not formatted to fit 80 chars, I can 
give you at least 5 that do.

I'm happy for you that you have freed yourself from the shackles of 80 
characters.  Everyone else, because of the lack of a new convention that seems 
to stick with everyone, just decides to be practical and stick to the previous 
convention of 80 characters.

It doesn't sound like you have much of a convention either (about 115 
characters I think it is doesn't sound like a convention).

It's your prerogative though to make non-standard software; I just don't think 
a lot of people will resize their terminals to 'about 115 characters' just to 
make your software's output look readable.

Original comment by svsam...@gmail.com on 26 Aug 2012 at 9:24

[GoogleCodeExporter]

I've moved this from a defect, because the line length can be customized.  This 
is neither a defect or an enhancement request, since the functionality already 
exists.

I moved the priority to low because no bug was indicated with a line length 
adjustment to 80 characters in a custom configuration file.

Original comment by Trash80.v2.0@gmail.com on 26 Aug 2012 at 5:16

• Added labels: Priority-Low, Type-Other
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Might as well close it completely then.  If not adhering to a common standard 
of 80 characters by default and in help output is a bug, no point in keeping an 
issue around just to spare my feelings.

Original comment by svsam...@gmail.com on 28 Aug 2012 at 7:57

[GoogleCodeExporter]

You just reminded me of another reason to not use gnome, I forgot about that 
tiny default size gterm has, and which can't easily be changed. I have always 
been astounded to see that gterm, gnome after gnome, fails to be able to 
remember its last closed size, a feature windows 95 had mastered, and probably 
various apple os stuff before even that.

The length of 115 was picked because it is roughly what the human brain is 
trained to easily read per line, ie, a book line, something that goes WAY 
further back than a legacy 80 character convention. Ie, the most information 
that can easily be absorbed per line.

However, I do agree that, given the idiotic gterm default, and the extreme 
difficulty, of resizing gterm permanently, at least that used to be the case 
(required actually setting geometry in the opening icon or command, if I 
remember right), the 80 character limit is being kept alive, but, thank god, 
recent developments in gnome make it look increasingly like there will be no 
real gnome as a serious desktop in the future (one gtk full time maintainer, 
and I believe,  only one or two full time gnome maintainers, if I remember the 
recent story right).

However, because this is an issue being kept alive by absurd legacy practices, 
as the issue poster notes are real, I think I'll keep this as an open issue, 
which can be fixed by anyone who wants to submit a patch for the help menu. The 
drag is, it's nto possible to detect terminal width if I remember right, so it 
hardly seems fair to people with reasonably sized terminals and consoles to 
have to suffer just because of a few legacy tools being kept in limbo by their 
decisions.

Now that i think of it, I think xterm also opens very small by default, but 
since I ALWAYS resize to a normal width, or taller/wider, first thing when I 
open a terminal, it's not something I really think about as a rule.

The only solution I can think of is to send the lines of help to a function 
that decides whether to print them at x characters wide or y.

So I'm going to mark this issue as extremely low, but existent, priority.

A dynamic -h menu resizing request, using either the built in line length 
function, or an updated version, or a new one, with full patch, will jump this 
to something that will be done eventually in the near future. No patch, and it 
will stay pretty low priority, given that after what, 4 years of inxi, this is 
literally the FIRST time anyone has had this issue or thought it worth 
mentioning, so obviously we're  not talking about a huge number of people who 
have issues with the sizes.

It's too bad terminals don't have the equivalent of html content container 
divs, where you can set the width, and allow wrapping to occur naturally, as 
with man for example, at least re the wrapping. But the man for inxi does wrap 
to terminal window size with flowing lines.

Original comment by inxi-...@techpatterns.com on 28 Aug 2012 at 10:04

• Changed state: Accepted

[GoogleCodeExporter]

With some time added, I'm going to change one thing in the last comment, this 
isn't going to happen in the near future, if it ever happens, it will be in the 
distant future, unless a properly done patch is supplied. Since that will never 
happen, by my guess, I'm going to guess this issue will stay unresolved for a 
long, long, long time.

Realistically, however, I don't see this ever happening, because I get more 
complaints about the help menu being far too long than I get about it not being 
80 cols wide, and decreasing the width will obviously increase the length, 
which is in my opinion much worse in terms of user experiences.

I do not understand why anyone uses gnome today to be honest, at least why 
anyone who actually runs a modern desktop and wants a usable computer uses 
gnome, but that's another issue, for some other time. Every other desktop is 
trivial, you resize your terminal, close it, and it remembers, like it's 
supposed to. To me any desktop that can't do something that simple is either 
badly broken or is a basic thing like fluxbox, but even fluxbox allows for easy 
resizing of default per app opening sizes for windows.

However, well done patches for this issue won't be rejected, and if they make 
sense, they will be used, as long as it doesn't break the ability to have the 
help menu as wide as it is now, roughly.

Original comment by inxi-...@techpatterns.com on 4 Oct 2013 at 11:57

[GoogleCodeExporter]

The terminals I've tried set $COLUMNS and $LINES environment variables. I've 
checked this with gnome-terminal, eterm and konsole running on Ubuntu 13.10 
amd64.

These terminals all produce the same results:

john@minime:~$ echo $COLUMNS
127
john@minime:~$ echo $LINES
34

Resizing the terminal windows gracefully updates the $COLUMNS and $LINES 
variables accordingly.



I also checked the base terminal by pressing CTRL+ALT+F1 and logged in there:

john@minime:~$ echo $COLUMNS
80
john@minime:~$ echo $LINES
25



Hope this helps a little.

Original comment by jpy...@gmail.com on 7 Mar 2014 at 7:01

[GoogleCodeExporter]

jpyper, outstanding. It helps a lot more than a little. I had no idea those 
existed.

Keep in mind however that inxi line output is VERY hard to modify, it can't do 
simply word wrapping at character counts because the item: value sets have to 
stay together to be coherent.

I've always sorely missed the basic box dimensions we have in html/css in bash, 
though I did get color styling to work reasonably well.

Oddly, I was actually thinking idly about the help menu issue the other day, 
trying to invent a print tool that might handle wrapping lines and then 
applying the proper indentation to them automatically based on a variable.

That's for help, which does not rely so much on actually constructing the 
item:value sets of output like the regular lines do in inxi.

However, with this, I can at least partially visualize a way to get the output 
to fit into its container column size better, with min/max values as in css 
width property. Much harder to do in a sense, but it's possible.

help also doesn't have to support irc output since it won't show in irc, and 
that makes it a lot more simple to handle since it also does not have to 
support item:value sets being on the same line.

The dynamic sizing of bash lines however is FAR harder than it would be in 
html, and takes a lot of work because bash isn't really designed that way in 
terms of preserving margin spacing then letting line wrap work within defined 
box widths.

But I can see a possible way that is not super impossible, it's hazy but I can 
see it, with this extra data.

Original comment by inxi-...@techpatterns.com on 7 Mar 2014 at 7:43

[GoogleCodeExporter]

Original comment by inxi-...@techpatterns.com on 7 Mar 2014 at 7:43

• Added labels: Type-Enhancement
• Removed labels: Type-Other

[GoogleCodeExporter]

inxi 2.1.0 now features dynamically sizing help/version output. Default size is 
120 columns in terminal, but it sizes down to fit the terminal / console width. 
I couldn't use $COLUMNS directly, but "tput cols" gets that data in the script.

Seems to work fine, tested on freebsd, various linuxes, all work as expected.

Please note, this slows down help menu display a bit, quite a bit on slower 
hardware, but overall it's acceptable with the speed optimizations I did.

Because this method is very stable and seems solid cross platform, I'm going to 
use it on all my bash menus I think. 

That way everyone can be happy, including svsamoht. I get my default wide 
menus, and everyone gets a menu that will never be wider than the columns of 
the terminal/console, there is about a 3x slower showing of the help menu, but 
I think that's acceptable.

I believe that I will be able to use this same method to print the lines as 
well by the way, with some modifications. Not on IRC, but in terminals. We'll 
see.

Original comment by inxi-...@techpatterns.com on 14 Mar 2014 at 3:03

• Changed state: Fixed