GNU bug report logs -
#78474
31.0.50; Wrong char insertion in rxvt
Previous Next
Full log
Message #227 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:20:24 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> 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, because it is not known what the terminal will store? And
that Emacs should only use SPCes for that reason? Or what am I
missing?
> And thus why I mentioned looking for an actual document that explictly
> says that \t is supposed to produce spaces, because for now the vte
> maintainer is saying that there is no text there and thus it should not
> be exposed to the accessibility layer, but then the cursor is getting
> wrong, making emacs essentially unusable as it is now. If I had a text
> that explicitly says that \t produces content, it would be way easier
> to fix this on the vte side. For now, we have been stuck for a *decade*
> there.
I think I understand, but the refusal of the vte developers to provide
some solution doesn't mean it becomes the responsibility of Emacs to
solve that, does it?
Also, what about the "stty -tabs" workaround -- does it work with vte
and rxvt?
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.