-
-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI enhancement suggestion #103
Comments
That would make sense in this case. When the command is an interpreter (like 'pyhon' or 'java') the parameters are actually useful. Perhaps we'd want to allow scrolling like in htop? Anyway, contributions improving in this area certainly welcome! |
I had not thought of that case.
I don't feel like it's worth (my work) adding scrolling(, but I'd be happy if someone else did it). I've been thinking of doing this work (as I've described it, favoring option 3). We'll see. I won't clone the repository until I can get to free Inet this weekend. I live in the fringe with limited service. |
Actually arguments aren't usually shown (though that is a wish, see #23) - chromium does something special there that makes the parameters show up. I'm OK with truncating from the right instead of from the left - indeed introducing more subtle logic seems confusing and error-prone. |
On my system, Ubuntu Studio, 16.04, Chromium Browser runs with the command line:
which the UI shortens from the left, which makes sense when the command line has no arguments and the most relevant portion is on the right, but in this case, in an 80 column terminal window, the most relevant portion is eliminated.
So I suggest that when the command line won't fit on a line in the UI and there are options and/or arguments, as in this case, it makes more sense to shorten the line from the right., and then, if all the command line arguments/options are eliminated, shorten from the left.
The text was updated successfully, but these errors were encountered: