Re: Cygwin 3.1.7 - xterm v360.1 - columns pasted from Excel no longer separated by tab

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2020-12-19 02:35, Thomas Wolff wrote:
> Am 19.12.2020 um 08:26 schrieb Brian Inglis:
>> On 2020-12-18 11:22, Bill shaffer wrote:
>>> On Thursday, December 17, 2020 11:22 PM, Brian Inglis wrote:
>>>> On 2020-12-17 16:03, Bill Shaffer 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?

I don't believe so, but it may be useful to ask TED about reasons for related 
resource defaults changing behaviour.
As mintty and xterm maintainer, if you are in touch over terminal issues, could 
you ask, and request followup here, as I thought he might be subscribed or 
checking from other comments?

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