WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: overeager line wrapping in rxvt  (Read 8749 times)

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
overeager line wrapping in rxvt
« on: September 17, 2019, 10:51:38 PM »
I'm on TC64 10.1 with default shell (BusyBox ash) and rxvt terminal emulator (for Unicode support).

When I use my default larger font, line wrap happens when text gets to edge of window as expected--then again (unexpectedly) once exactly 80 characters are reached. It looks awful and makes it difficult to edit the command.

Decreasing font size causes premature line wrap at 80 characters before edge of window is reached.

A picture is worth a thousand words:


So it seems there are two line wrap algorithms working simultaneously: A well-behaved one that wraps the line when text reaches edge of window, and a dimwitted one that wraps at exactly 80 characters. How do I keep the former and disable the latter? (Most of the information I'm finding pertains to bash shell and/or a more fancy terminal emulator, which is making it difficult to find relevant information.)

This is my ~/.Xdefaults when using my default (larger) font:
Code: [Select]
URxvt*scrollBar: true
URxvt*transparent: false
URxvt*title: Terminal
URxvt*foreground: white
URxvt*background: #300A24
URxvt*font: xft:Luxi Mono:pixelsize=14
URxvt*cursorColor: green
URxvt*fading: 30
URxvt*shading: 50
URxvt*color12: DodgerBlue1
URxvt*saveLines: 1000
fltk*scheme: gtk+
Xft.dpi: 96.0
« Last Edit: September 17, 2019, 10:59:16 PM by GNUser »

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: overeager line wrapping in rxvt
« Reply #1 on: September 17, 2019, 11:24:03 PM »
What desktop and video graphics are you using? What is your locale setting? There are a lot of variables here. I've seen a few glitches with rxvt regarding wrapping but not this one.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Re: overeager line wrapping in rxvt
« Reply #2 on: September 18, 2019, 01:37:32 AM »
Hi, guys!
I'm having the same trick at TC10.0 x86. I use Xfbdev. The same extra line feed occures in aterm exactly in the same manner, so definitely it is ash issue.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Re: overeager line wrapping in rxvt
« Reply #3 on: September 18, 2019, 01:42:55 AM »
For example such overfeed can occur if ash is not informed well about the actual screen width. So the first line feed is performed by terminal emulator, and the second by ash.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Re: overeager line wrapping in rxvt
« Reply #4 on: September 18, 2019, 01:57:34 AM »
I've made some experiments and can conclude, that ash requests screen dimensions only at start. Working with initial --geometry XxY is ok. Narrowing causes double feeding, widening causes line feed not reaching screen border.
Code: [Select]
tc@box:~$ clearforces ash to acquire the screen dimensions.
« Last Edit: September 18, 2019, 02:02:57 AM by jazzbiker »

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Re: overeager line wrapping in rxvt
« Reply #5 on: September 18, 2019, 02:36:33 AM »
Sorry for overposting, but i was wrong about ash, it reads screen dimensions after every command line execution. Even Ctrl-C put elephants on their places.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: overeager line wrapping in rxvt
« Reply #6 on: September 18, 2019, 08:36:54 AM »
@andyj: Fluxbox, Xorg and xf86-video-intel, en_US.UTF-8

FWIW my guess is that the two things butting heads in the top terminal in screenshot (with larger font I normally use) are:
linewrapper #1: readline (responsible for the first--appropriate--line wrap)
linewrapper #2: rxvt or possibly ash (responsible for the inappropriate line wrap after "-10.")

Interestingly, I cannot reproduce the problem in that top terminal 100% of the time. Most of the time it happens but sometimes it doesn't. Tab completion seems to make it happen more reliably but is not a guarantee.

From the bottom terminal you can see that if window is wide enough to fit 80 characters or more for your font size, only linewrapper #2 is in play. With only one linewrapper at play, there's no butting heads. It takes two to tango.

Therefore my workaround was to make the terminal at least 80 characters wide for my font size, then tell fluxbox to remember the window dimensions for rxvt.

If someone finds a proper solution rather than a workaround like mine--or if you know for sure who the two linewrappers are--please do share! :)
« Last Edit: September 18, 2019, 08:41:47 AM by GNUser »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: overeager line wrapping in rxvt
« Reply #7 on: February 13, 2020, 10:55:23 AM »
Just a quick follow-up: As jazzbiker pointed out,  ash  calculates terminal width when it draws the command prompt.

I did not fully appreciate the practical consequence of that until just now:
If you drag the corner of a terminal emulator (e.g., aterm or rxvt) to make it wider, you have to run a command--or simply press Enter to get a new command prompt--for  ash  to become aware of the extra width.

« Last Edit: February 13, 2020, 11:07:40 AM by GNUser »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: overeager line wrapping in rxvt
« Reply #8 on: February 13, 2020, 12:29:36 PM »
Working with initial --geometry XxY is ok.

Sorry for overposting. I just wanted to say that the above tidbit clued me in to a solution--creating a wrapper script for  urxvt  that specifies initial geometry, like this:
Code: [Select]
exec /usr/local/bin/urxvt -geometry 80x20 "$@"
After that, the only little glitch that remains is that if I manually make the terminal wider, I have to press Enter for  ash
 to recalculate line wrapping (see Reply #7 above). Manually making the terminal narrower, on the other hand, causes line wrapping to immediately adjust appropriately.

SOLVED (at long last) :)

P.S. I'm using a fixed-width font (I have this line in ~/.Xdefaults: URxvt*font: xft:Luxi Mono:pixelsize=14), which may or may not be contributing to things working well now.
« Last Edit: February 13, 2020, 12:59:43 PM by GNUser »