| 1 |
On 6/22/19 2:13 AM, Mick wrote: |
| 2 |
> These USE flags are the same like mine. |
| 3 |
|
| 4 |
ACK |
| 5 |
|
| 6 |
> I don't think it is a shell related problem (but may be wrong). |
| 7 |
|
| 8 |
I think we need to be very careful and specific what part we think is |
| 9 |
shell (thus possibly readline) related vs terminal emulator related vs |
| 10 |
something else. (See my recent reply discussing an old school TTY |
| 11 |
terminal.) |
| 12 |
|
| 13 |
> After all changing the shell option in .bashrc does not affect the |
| 14 |
> display within the xterm window. |
| 15 |
|
| 16 |
"shell option in .bashrc"??? |
| 17 |
|
| 18 |
Are you launching a different shell from Bash? (.bashrc is inherently |
| 19 |
Bash.) |
| 20 |
|
| 21 |
Or are you using Bash as your interactive shell and using a different |
| 22 |
shell for sub-commands / forks / etc.? |
| 23 |
|
| 24 |
> This is the problem I was describing as 'annoying'. Xterm draws the |
| 25 |
> output once to fill in the real estate of the current xterm window, |
| 26 |
> but changing the window width does not redraw each line to reflow it |
| 27 |
> across the new window width. |
| 28 |
|
| 29 |
Agreed. This is the behavior I've seen (and expected) from XTerm for 20 |
| 30 |
years. |
| 31 |
|
| 32 |
> Apologies for my confusing description - I'll have another go below. |
| 33 |
|
| 34 |
;-) |
| 35 |
|
| 36 |
Confusion is okay as long as we work to clarify things. That's part of |
| 37 |
communicating effectively. |
| 38 |
|
| 39 |
> I ran ldd and as is logical I can see there are some differences in |
| 40 |
> the libs used by both programs. Neither of them use libterm. |
| 41 |
|
| 42 |
I was fairly certain that XTerm did not use libterm. I didn't know |
| 43 |
about (u)rxvt. I think some other—possibly more common—terminal |
| 44 |
emulators do use it. |
| 45 |
|
| 46 |
Aside: I consider urxvt to be a Unicode varient of rxvt. Much like |
| 47 |
uxterm is a Unicode varient (mode)of xterm. To me, both of these pairs |
| 48 |
are largely interchangeable for the conversation that we're having. |
| 49 |
Please correct me if you think I'm wrong on this point. |
| 50 |
|
| 51 |
> In my systems urxvt will wrap lines when shrinking the width of |
| 52 |
> the window AND unwrap them when increasing the width of the window. |
| 53 |
> This is happening in real time as the window expands/contracts. |
| 54 |
|
| 55 |
This is the behavior that I'm seeing with urxvt as well. |
| 56 |
|
| 57 |
I have never seen XTerm exhibit this behavior. (At least not without |
| 58 |
something else inside of XTerm that does it, e.g. screen or tmux.) |
| 59 |
|
| 60 |
> Again in my systems xterm will truncate lines when shrinking the width |
| 61 |
> of the window. This truncated output is now lost. Increasing the |
| 62 |
> width of the window will not restore the truncated lines. Scrolling up |
| 63 |
> will now draw lines in the new full width of the xterm window, but |
| 64 |
> the truncated lines remain truncated and their information is lost. |
| 65 |
|
| 66 |
Agreed. This is what I've seen and come to expect from XTerm after |
| 67 |
using it for 20 years. |
Archives