X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org AF7643854801
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=towo.net
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=towo AT towo DOT net
Subject:	Re: Cygwin 3.1.7 - xterm v360.1 - columns pasted from Excel no longer
	separated by tab
To:	cygwin AT cygwin DOT com
References:	<be725ca1-ed04-95fb-fa68-d40e3b0db443 AT comcast DOT net>
	<e41908d7-2e93-2890-ad9e-7227713b39cb AT SystematicSw DOT ab DOT ca>
	<CY4PR13MB15275B2A68BD9F9036B193CFD8C30 AT CY4PR13MB1527 DOT namprd13 DOT prod DOT outlook DOT com>
	<1b66e0d4-5901-9145-52db-302cb0437236 AT SystematicSw DOT ab DOT ca>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<f5f8a32e-3f25-9ed5-75da-1dce30787c46@towo.net>
Date:	Sat, 19 Dec 2020 10:35:09 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
	Thunderbird/78.6.0
MIME-Version:	1.0
In-Reply-To:	<1b66e0d4-5901-9145-52db-302cb0437236@SystematicSw.ab.ca>
X-Provags-ID:	V03:K1:fNNRd2oet+uGfgTUrW7Sxjo1gy+qFQhbJXGVQkHuVY7tLKOs6c5
	Kr5GTZVfDA9rk+4WhFGxLLjndQWe3fVeGBl8Nh26YcHPF/aLUkhYwYtO63W4Tjaj8+HQdsU
	N3AlfxbD7p2KwuLtG7emEcd3oBfO37hJYcIn95T2DB97HmGoQ3CnVaHOpeCK7cHAg+Vj45Q
	6iPLz3U7r8I2fOot6Xl6w==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:zNliRnCWB58=:GgMPk7oRaZ/Aau03YNTv5t
	AM8+OvBNhnhMth+aSrFRWmOv206EDVgXCNYTUxArx4FAF5T6vLeI0XYvN0c7A/zn5eOrLlmWZ
	OFksR94/CqVaK+2tbor2GOXkLWyZ2BRXM9qSm8d5mB2LVFrpxFTW3/QDFQc19EHIZsVoTkYt2
	XrfEBS+xrwqkKXacQt378SW+X5Zt+Y0YG+M1BB7roBkE+4ouD4WmsCc8qmz0UhTll0gR/QEQZ
	IeSAI9wTr0/wazlpIdR7KpMikf/q2fg9TwHhIKCyioY9fCMf5aIQ8ESyb6rEaPG+TmX1x22VG
	itRbY+tJ0YiAEH6KDXIxHGKHuaZJcUAxdbdnaieM6TtRpKf1DSfL53t3Wlm+vw6i89INUk26w
	pKSFbPr+4+tKszrGvAR4l9VPOeFfP6MpbzPPDjKJUTfG0BOslX60eHUdz+iH7
X-Spam-Status:	No, score=3.4 required=5.0 tests=BAYES_00, BODY_8BITS,
	KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A,
	RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,
	SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Level:	***
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 0BJ9Zl3K004506

Am 19.12.2020 um 08:26 schrieb Brian Inglis:
> On 2020-12-18 11:22, Bill shaffer via Cygwin wrote:
>> On Thursday, December 17, 2020 11:22 PM, Brian Inglis wrote:
>>> On 2020-12-17 16:03, Bill Shaffer via Cygwin wrote:
>>>> I am using Cygwin 3.1.7 and xterm 360.1 on Windows 10.  I run the X 
>>>> server and
>>>> work in xterm windows.  When I copy a selection from an Excel 
>>>> spreadsheet and
>>>> paste it into a vi session in an xterm window, the spreadsheet 
>>>> columns are
>>>> separated by spaces.  If I paste into a vi session in a cygwin 
>>>> 3.1.7 console, I
>>>> get tabs as separators.  If I run xterm on another host and send 
>>>> the display to
>>>> my X Server, I get tabs.
>>>> In my previous version of Cygwin - which was probably about 2-3 
>>>> years old - when
>>>> I did this the columns were separated by tabs.  I still see tab 
>>>> separators in
>>>> Cygwin 1.7.31 (Windows 8.1).  I can type tabs just fine in the 
>>>> 3.1.7 xterm.  It
>>>> seems to be something in the local xterm that is converting the 
>>>> pasted tabs to
>>>> spaces.  I don't think it's the copy portion of the operation, or I 
>>>> wouldn't get
>>>> tabs in the console.
>>>> Did something change at some point that would explain this 
>>>> behavior?  Is there a
>>>> way to get back to having the columns separated by tabs?
>>>> I understand that usually copying and pasting implies visible 
>>>> characters and
>>>> that tabs are usually only visible as spaces, and this is the 
>>>> result I would
>>>> expect when copying visible text separated by tabs. However, when 
>>>> pasting from
>>>> Excel, the columns have always come across separated by tabs - and 
>>>> still do,
>>>> except for in xterm.
>>>> My TERM is xterm - I've tried vt100 and vt220 as well.  My TERM is 
>>>> also xterm in
>>>> the working examples above.
>
>>> The consensus on X is that the characters copied are determined by 
>>> the source,
>>> and Windows apps often offer their clipboard info in multiple 
>>> formats, if you
>>> check using an app that allows you to choose the format pasted e.g 
>>> LibreOffice.
>>> Having said that, editors also have settings that determine how 
>>> pasted tabs are
>>> treated, and that may depend on the target window settings for the 
>>> file type
>>> when pasted.
>>> On Cygwin and Linux that probably depends on the vim compatibility 
>>> settings, and
>>> settings in:
>>>          $ strings -n5 /bin/vi | egrep '^[.~$/].*(ex|vim?)rc' | sort -u
>>>          $HOME/.exrc
>>>          $HOME/.virc
>>>          .exrc
>>>          .virc
>>>          /etc/virc
>>>          ~/.vim/vimrc
>>> whereas BSD systems may still provide original n/vi.
>
>> Thank you for the response!  This got me looking in the right 
>> direction.  I agree with what you say that the clipboard contents are 
>> determined by the source. Given that I could paste (from the same 
>> buffer) into the console window and get tabs, I had to assume that 
>> the copy process was grabbing the
>> tabs as expected. > So looking for editor and window settings, and 
>> looking in the xterm(1) man
>> page, I found disallowedPasteControls, which says the default 
>> includes ASCII
>> tabs: ... > The default is
> > BS,HT,DEL,ESC
> > BS - ASCII backspace
> > HT - ASCII tab
> > DEL - ASCII delete
> > ESC - ASCII escape
> > ...
> > I put the following line in my .Xdefaults, removing HT:
> > xterm*disallowedPasteControls: BS,DEL,ESC
> > and restarted Xwin server, and now my tabs paste as expected.
xrdb .Xdefaults and restart xterm would be sufficient
>> That entry doesn't even exist in my older installation's man page. I 
>> found a post indicating that it was added in xterm patch 333 in 2018, 
>> which would be newer than my previous install.
> I am surprised that any terminal would remap normal input characters 
> without an explicit non-default setting, and would expect all 
> characters to be allowed unless there is some exceptional 
> (compatibility/security) reason for blocking or remapping, so it never 
> occurred to me to suggest that layer!
>
> I notice that on the xterm(/vttest/ncurses/lynx/etc.) maintainer's web 
> man page links:
>
> https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:disallowedPasteControls 
>
This resource was introduced in xterm 333 (2018). Should the cygwin 
xterm package change the default?

>
> this resource converts the listed characters to a space, whereas 
> another positive resource:
>
> https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:allowPasteControls 
>
>
> allows control characters to be pasted, and yet another allows high 
> ASCII characters:
>
> https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:allowC1Printable 
>
>

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -