On Wed, Jan 11, 2012 at 07:00:52PM +0100, Axel Beckert wrote:
> tag 652990 + confirmed upstream
> retitle 652990 screen: Binding a key to a different action sometimes still
> yields the default binding
> forwarded 652990 https://savannah.gnu.org/bugs/index.php?35287
> kthxbye
>
> Hi Bruce,
>
> thanks for the reminder.
>
> Bruce Momjian wrote:
> > > > I just found the cause of my odd "Enter" behavior and was about to email
> > > > an update. It turns out if you press ^A, and then space quickly, you
> > > > get the (wrong) 'next' behavior, but if press ^A then and then wait for
> > > > a second and then press space, you get the (right) configured info
> > > > behavior. [...] Is that reproducible for you?
> > >
> > > Indeed it is -- despite it happened in only about 10% of my tries to
> > > type ^A Space quickly. (Maybe I'm still not typing fast enough all the
> > > time. ;-)
> > >
> > > I'll check later if this still happens with the version of screen in
> > > Debian experimental.
> >
> > Any update on this?
>
> Yes, and I'm sorry to say that it still happens with the newest
> upstream version and does not only happen with space. I could also
> reproduce it with the key "c" instead.
>
> I reported it to the GNU Screen developers at
> https://savannah.gnu.org/bugs/index.php?35287
Having seen no activity on this, I decided to dig into the code in a
serious way. I added some debug statements and put screen in debug mode
and found that the read() call in disp_readev_fn() was returning ^@ (the
null byte) for space when typed quickly. Here is my debug output:
> + hit ev fd 4 type 1!
> size = 4096
> char = ^Z len = 1
> disp_readev_fn 2
> ProcessInput: 1 bytes
> cmp2 ^Z
> cmp ^Z ESC[3]
> complete miss
> ProcessInput2: 1 bytes
> - ilen now 1 bytes
> + hit ev fd 0 type 3!
> serv_select_fn called
> waiting for events:
> - fd 4 type 1 pri 0
> - fd 4 type 2 pri 0
> - fd 8 type 1 pri 0
> - fd 8 type 2 pri 0
> - fd 5 type 1 pri 0
> - fd 0 type 3 pri -10
> - cond ev fd 4 type 2 failed
> - cond ev fd 8 type 2 failed
> readfds: 4 5 8
> writefds:
> + hit ev fd 4 type 1!
> size = 4096
--> > char = ^@ len = 1
> disp_readev_fn 2
> ProcessInput: 1 bytes
> cmp2 ^@
> cmp ^@ ESC[3]
> complete miss
> ProcessInput2: 1 bytes
> - ilen now 1 bytes
> AclCheckPermCmd(root 0 next) = 0
Now, read() returning a null byte for space is really odd, and I have no
idea what would cause that. With that information, I decided to add
this to my screenrc:
# fix screen bug caused by typing fast, 'space' becomes null byte,
2012-01-16
bind ^@ other
This does fix my immediate problem of meta-space not working. I suspect
that other cases also might return a null byte, but I am not sure that
is a problem for me.
I am not clear now if the problem is that type fast causes the default
action, or type fast causes 'next' because next is bound to the null
byte.
Let me know if you want my debug diff but I basically just output the
byte the read() returned (assuming size > 0). Hopefully this will give
someone a place to continue debugging this.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
