Subject: Re: bug#78474: 31.0.50; Wrong char insertion in rxvt

From: Samuel Thibault <[email-masked]>
Date: Tue, 22 Jul 2025 20:27:17 +0200

Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > Eli Zaretskii, le mar. 22 juil. 2025 15:15:28 +0300, a ecrit:
> > > What you copy/paste and what is written to the screen are not
> > > necessarily the same thing.  The effect of TAB on the screen is to
> > > move the cursor (or the rest of the line's text) to the right by a
> > > suitably-computed number of columns, which depends on the column where
> > > you do that.  What is copy/paste'd depends on the program which
> > > serves the copy: some give you TAB, others give you spaces.
> > > 
> > > > Also, if you run:
> > > > 
> > > > echo -e 'a\t'
> > > > 
> > > > is there actually supposed to be some content to copy/paste on the right
> > > > of a?
> > > 
> > > IME, also depends on the program which serves the copy/paste.
> > > 
> > > (I think these aspects are tangents, not an integral part of this
> > > discussion.)
> > 
> > They are fully part of the discussion, because that changes what is
> > actually supposed to be stored in the terminal, and thus what the
> > accessibility feature is supposed to expose to the user: should it
> > expose a tab, or spaces. But if a tab, then how can the cursor be inside
> > the tab when emitting \t\b. That's the *whole* problem at stake.
> 
> So you are saying that even using cursor movement commands could cause
> problems,

The problem is that some people consider \t as not being only a cursor
movement. That's the whole point of the question raised above.

> because it is not known what the terminal will store?  And
> that Emacs should only use SPCes for that reason?

\t alone seems to be not posing problems, and is fine to keep to
optimize some cursor movements. It's \t\b which gets wrong.

Samuel