Page break (^L) doesn't clear terminal

[Slider-Whistle]

When the page break character is sent to the terminal, the normal functionality is to push it all up past the top row. Linux's native console does this, if you want to test.
With yaft though, at least for me, it only goes up by a single row, like a few naive terminal emulators. Are there any plans to fix this?

[Slider-Whistle]

Oh, I should clarify, I'm using version 0.2.9. Should I just use the latest git version?

[uobikiemukot]

Hi,

yaft normally erases display when receives Ctrl-L. Maybe some settings are incorrect.

Please check:

• install yaft's terminfo before use: $ tic info/yaft.src
• use correct TERM environment variable: $ export TERM=yaft-256color

You should use TERM=yaft-256color inside of terminal multiplexer (tmux or screen).

[Slider-Whistle]

Tried installing the terminfo, it didn't seem to make a difference after restarting the program.
The TERM variable's correct, too. Is there anything else it could be?

[uobikiemukot]

Some questions:

• $ tput reset works correctly? (it behaves like Ctrl-L)
• What kind of shell are you using?
• Are you using terminal multiplier (tmux or screen or something) with yaft?

Please paste debug log here for more investigation.
It's very helpful.

1. set VERBOSE = true in conf.h
2. re-compile yaft
3. run $ yaft > dump 2> log
4. send Ctrl-L and exit
5. paste log here

[Slider-Whistle]

1. tput reset does work
2. Nothing unusual, just using bash (version 4.3.048, seems to be a little outdated)
3. Nope

dump:
[mark@home-base ~]$
[mark@home-base ~]$ exit

log:

DEBUG<< framebuffer info:
DEBUG<< red(off:0 len:8) green(off:0 len:8) blue(off:0 len:8)
DEBUG<< resolution 1920x1080
DEBUG<< screen size:2076672 line length:1920
DEBUG<< bits_per_pixel:8 bytes_per_pixel:1
DEBUG<< type:YAFT_FB_TYPE_PACKED_PIXELS
DEBUG<< visual:YAFT_FB_VISUAL_PSEUDOCOLOR
DEBUG<< colors:256 max_length:8
DEBUG<< terminal cols:240 lines:67
DEBUG<< esc reset
DEBUG<< addch: U+005B
DEBUG<< addch: U+006D
DEBUG<< addch: U+0061
DEBUG<< addch: U+0072
DEBUG<< addch: U+006B
DEBUG<< addch: U+0040
DEBUG<< addch: U+0068
DEBUG<< addch: U+006F
DEBUG<< addch: U+006D
DEBUG<< addch: U+0065
DEBUG<< addch: U+002D
DEBUG<< addch: U+0062
DEBUG<< addch: U+0061
DEBUG<< addch: U+0073
DEBUG<< addch: U+0065
DEBUG<< addch: U+0020
DEBUG<< addch: U+007E
DEBUG<< addch: U+005D
DEBUG<< addch: U+0024
DEBUG<< addch: U+0020
DEBUG<< ctl: CR
DEBUG<< ctl: LF
DEBUG<< addch: U+005B
DEBUG<< addch: U+006D
DEBUG<< addch: U+0061
DEBUG<< addch: U+0072
DEBUG<< addch: U+006B
DEBUG<< addch: U+0040
DEBUG<< addch: U+0068
DEBUG<< addch: U+006F
DEBUG<< addch: U+006D
DEBUG<< addch: U+0065
DEBUG<< addch: U+002D
DEBUG<< addch: U+0062
DEBUG<< addch: U+0061
DEBUG<< addch: U+0073
DEBUG<< addch: U+0065
DEBUG<< addch: U+0020
DEBUG<< addch: U+007E
DEBUG<< addch: U+005D
DEBUG<< addch: U+0024
DEBUG<< addch: U+0020
DEBUG<< addch: U+0065
DEBUG<< addch: U+0078
DEBUG<< addch: U+0069
DEBUG<< addch: U+0074
DEBUG<< ctl: CR
DEBUG<< ctl: LF
DEBUG<< caught signal! no:17

Looks like it's interpreting ^L as "Enter" for some reason. Should I post my config? I don't think I changed much.

[uobikiemukot]

Thank you for the information.

It seems that GNU Readline (line edit library used by bash) doesn't send correct terminal escape sequences. Normally it sends CSI H CSI J if receives Ctrl-L. This is clear sequences defined in yaft's terminfo. (and sorry, Ctrl-L equals $ tput clear not $ tput reset...)

process flow is like this:

1. user input Ctrl-L
2. readline check current key bindings for Ctrl-L
3. readline search terminfo and send clear sequences (CSI H CSI J)
4. yaft parse CSI H CSI J and erase display

Maybe 2 or 3 is something wrong.

[Slider-Whistle]

I was using Readline version 6.3, while the latest is version 8. I upgraded to the latest version, but I'm still not getting any difference. I've confirmed that `tput clear` works, so I guess it's either something wrong with yaft's terminfo (unlikely, but maybe I should upgrade to the latest git version just in case?), or something wrong with Readline.

[hackerb9]

Since tput clear didn't say "unknown terminal", yaft's terminfo file is installed and is being used. The problem is with how your system is handling ^L.

Do you have a file called ~/.inputrc? That file lets you change how keys are interpreted by Readline, including clear-screen. Try running the command bind -p to see which key is bound to clear-screen.

$ bind -p | grep clear
"\C-l": clear-screen

The only other alternative I can think of that might be wrong would be if you somehow got your tty into raw mode, which shouldn't be a problem with bash. Try stty sane and see if it helps.

[hackerb9]

By the way, you don't happen to be using a remapped keyboard, do you? For example, Dvorak or some internationalization? And you've tried yaft without modifying the config file, right?

[Slider-Whistle]

bind -p|grep clear

Returns ""\C-l": clear-screen". When I look at both /etc/inputrc or ~/.input rc, I don't see any mappings for \C-l, though, so I don't know what's going on there.

raw mode

The home, end, delete and arrow keys seem to work, so I don't know if that could be it. I tried stty sane and opened another shell within bash to see whether that'd help, but didn't get any changes. I would've changed the shell yaft starts with, but I don't know whether there's any way to do that without changing my settings.

remapped keyboard

I'm pretty sure I'm using a standard US keyboard mapping.

config file

Tried a fresh configuration file, no dice.

If nobody else ever encounters this, I'd be alright with just closing the issue and living with it. For probably future reference, I'm using the 64-bit version of Slackware 14.2.

[hackerb9]

You're probably right, it's just something to live with for now. It's downright weird, though. What if you bind a different key to clear? Perhaps ^O? Try running this command:

bind "\C-o":clear-screen

[Slider-Whistle]

I tried that just now, it still just inserts a newline. There's an error on the actual terminal I saw after closing the program I might've not noticed earlier though, it says this: ">>ERROR<< put_cmap failed" Sounds pretty important, right?

[uobikiemukot]

">>ERROR<< put_cmap failed"

I think this message is not related to erasing display.

put_cmap is called, If need to update hardware color palette at startup/terminate/vt-switch. If this error can be re-produced, it's an another bug 😢