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 E57B43858006
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=SystematicSw.ab.ca
Authentication-Results:	sourceware.org;
	spf=none smtp.mailfrom=brian DOT inglis AT systematicsw DOT ab DOT ca
X-Authority-Analysis:	v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=5fddab13
	a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17
	a=IkcTkHD0fZMA:10 a=HiWkEfo4AAAA:8 a=DvA01hF-NZNkeKJxArgA:9
	a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=QEXdDO2ut3YA:10 a=OHHzynkM2j8A:10
	a=_QplDg0m8TGAdENQf2wZ:22
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>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Organization:	Systematic Software
Subject:	Re: Cygwin 3.1.7 - xterm v360.1 - columns pasted from Excel no longer
	separated by tab
Message-ID:	<1b66e0d4-5901-9145-52db-302cb0437236@SystematicSw.ab.ca>
Date:	Sat, 19 Dec 2020 00:26:10 -0700
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:	<CY4PR13MB15275B2A68BD9F9036B193CFD8C30@CY4PR13MB1527.namprd13.prod.outlook.com>
X-CMAE-Envelope:	MS4xfGVRi6IqaCr4m/qyxrWxB7tzB2pmpWXa9oqDVOrjSkmRWIwqvMctQQ9wrc70dwS07SxlpJpdYPNeDkL/hqKKzn8xuZpoGoXn87m/wcIL8c1SQV9QREwt
	qMIYx35oWbx4bkdP9OHhrlVMuhO+d/q6rwPrrcT8PBSwyRjKAMOCuq3lncIuCpLfhBkIcQ8YLHRBCDQyoRsmUXCgY+v8TjVAzWw=
X-Spam-Status:	No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
	TXREP autolearn=no autolearn_force=no version=3.4.2
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>
Reply-To:	cygwin AT cygwin DOT com
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

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.
> 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 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

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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 -