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

[Thomas Wolff <towo@towo.net>]

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