Re: [code] ctrl-c frequently doesn't work on Windows.

From: <foicica.att.nekulturny.org>
Date: Sun, 22 Oct 2017 08:20:18 -0600

On 2017-10-22 06:27, Mitchell wrote:
>
> On Sat, 21 Oct 2017, foicica.att.nekulturny.org wrote:
>
>> On 2017-10-21 08:57, Mitchell wrote:
>>>
>>> Did you install any custom modules that may override the default
>>> Ctrl+C key binding? Try opening the Command Entry (Tools -> Command
>>> Entry), enter "keys.cc = buffer.copy" (no quotes), press enter, and
>>> then try Ctrl+C actions. If that ends up working, something other
>>> than
>>> Textadept is altering Ctrl+C behavior.
>>
>> I cleared out my init.lua. The thing that's happening is that I can
>> copy
>> and paste inside textadept just fine. But when I try to copy from
>> textadept and paste into another app, it frequently (30%-ish of
>> textadept launches) doesn't work. If it works once, it seems that it
>> will keep working for the rest of that textadept session. If it
>> doesn't
>> work, I don't think it has ever worked again in the same textadept
>> session -- I have to restart. Textadept is the only app I seem to have
>> this issue with.
>
> The only thing I can think of is that Windows is causing trouble for
> GTK (the UI toolkit Textadept uses) clipboard operations. If possible,
> you might want to see if you get the same behavior from another
> GTK-based editor on Windows like Geany (https://geany.org/). If so,
> then there's really nothing to be done from the Textadept side.

Thanks for the tip. The issue is in geany also. I also found this issue
for zim that seems the same.

https://github.com/jaap-karssenberg/zim-desktop-wiki/issues/29

That issue talks about OpenClipboard failed: access denied errors. That
rings a bell for me in that I think previous versions of textadept
printed that same error if I ran it from the command prompt.
Unfortunately for me, the conclusion of that issue is that they gave up
on fixing it because it seems to be a GTK2 issue which I guess isn't
being maintained anymore.

>>> My guess is that something in your ~/.textadept/ is altering the
>>> default Ctrl+C behavior.
>>
>> Even if I remove ~/.textadept/ completely the behaviour is the same.
>> ctrl-c just doesn't work in textadept-curses in WSL. It works fine in
>> Linux.
>>
>> If I run these commands in the command window I can copy and paste
>> with
>> ctrl-b and ctrl-n (not that I want to do that but I did it as a test):
>>
>> keys.cb = buffer.copy
>> keys.cn = buffer.paste
>>
>> In fact I just figured out that if I bind ctrl-n to paste, I can copy
>> with ctrl-c and paste with ctrl-n. So it's the ctrl-v shortcut that's
>> the problem, not ctrl-c.
>>
>> I know ctrl-v is not being filtered out by the Windows terminal,
>> because
>> at a bash prompt if I hit ctrl-v followed by "enter", it prints "^M".
>
> In Textadept's *core/keys.lua* file around line 215 there is a line
> commented out that starts with `if CURSES then ...`. Uncomment that
> line, restart or reset textadept-curses, and then press Ctrl+V. See if
> the key sequence printed in the statusbar is recognized properly as
> `cv`. If not, then this is likely a WSL issue and I would not know
> what to do about it.

I uncommented the line. The status bar changes when I hit other keys. It
doesn't change when I hit ctrl-v. So I guess I'm out of luck.

Thanks,

-- 
Dan
-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Sun 22 Oct 2017 - 10:20:18 EDT

This archive was generated by hypermail 2.2.0 : Mon 23 Oct 2017 - 06:41:57 EDT