[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash doesn't display user-typed characters; can interfere with COPY/

From: L A Walsh
Subject: Re: bash doesn't display user-typed characters; can interfere with COPY/PASTE
Date: Wed, 09 Dec 2020 12:53:31 -0800
User-agent: Thunderbird

On 2020/12/08 06:07, Chet Ramey wrote:
On 12/7/20 8:02 PM, L A Walsh wrote:

The problem is that bash isn't displaying a 'tab' character where
one was typed.

It's readline and redisplay. Readline expands tabs to spaces using an
internal tab stop of 8. This allows it to be sure of the physical cursor
location, especially when you're doing things like wrapping lines, and
insulates it from varying terminal behavior.
*snark* That's nice, why not just display 'X' instead of spaces?  Wouldn't
that also insulate readline from varying terminal behavior? *not really, but...*

I'm not sure it is the place of a an in-line-editor to override terminal features.

However, as readline is an editor and most editors allow setting the tabs (as well as whether or not to use hard-tabs or expand them). If readline has to "insulate",
just like vi/vim -- have the tabstop and whether to expand be in a startup
file like .inputrc. Right now, .inputrc has the facility to define how characters are to be interpreted. Why not put the option to expand w/spaces in there, as well as what a tab character expands (or maps to). Bash also overrides existing standards with regards to tabs wrapping. It seems that many or most terminals (xterm compat, linux console-compat, etc) don't wrap to the next line when a tab is pressed. The reasoning for that was that tab was supposed to skip to the next field in the same line. Wrapping is beyond the scope of function
for tabbing.
With many (most?) terminal windows these days, especially
Unicode-enabled ones, the terminal has to read what is on the screen to
be able to read the binary code of whatever is displayed on the screen,
Otherwise, it wouldn't be able to read typed unicode.

This is not relevant to the issue.
---- It was meant to illustrate that terminals are using the binary representation of the characters typed -- and that arbitrarily changing the binary representation
(like tabs->spaces) will mess up / corrupt the user's output stream.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]