Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago Original comment by inxi-...@techpatterns.com on 7 Mar 2014 at 7:43
GoogleCodeExporter
commented
9 years ago 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
Original issue reported on code.google.com by
svsam...@gmail.comon 21 Aug 2012 at 5:17