[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] key press detection lag?

From: Eric Abrahamsen
Subject: Re: [STUMP] key press detection lag?
Date: Sat, 15 Feb 2014 23:33:24 +0800
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux)

Ruthard Baudach <address@hidden> writes:

>>== Ausz├╝ge aus der Nachricht von  Eric Abrahamsen vom 2014-02-10 08:09:
>> This could totally be my imagination, but since there have been so many
>> updates recently, I thought I'd check in and see what other people
>> think...
>> I'm running stump on archlinux, with no desktop manager. My subjective
>> feeling is that I'm getting a lot of tardy prefix keypress detection
>> from stumpwm: I hit "C-t c", which should run-or-raise my terminal, and
>> instead a "c" gets sent to the focused window, and then stump picks up the
>> "C-t" and waits for further input. This can be pretty annoying, for
>> instance when emacs/gnus is focused and the unintentional "c" marks the
>> group under point as completely read.
>> Has this gotten worse recently, or am I dreaming? If I am dreaming, is
>> there any way to block key input so that, even if stump is slow, it
>> still consumes further keypresses?
> I do not have this issue, but had it using C-t as prefix key -- it's too
> uncomfortable for me to use it all the time.
> I'm using the Windows key as prefix key:
> .stumpwmrc:
> ---------------------->%-------------------
> (run-shell-command "xmodmap -e \"keycode 133 = F20\"")
> (run-shell-command "xmodmap -e \"clear Mod4\"")
> (set-prefix-key (kbd "F20"))
> ---------------------->%-------------------

Thanks! But the fact remains that you're still using an escape key:
a single keypress that has to be caught by Stumpwm before it will read
what follows. It doesn't seems like which particular escape key you're
using should matter.

Arch just updated SBCL to 1.1.15, and the problem seems significantly
better, though I'll want to give it a few days to see. I swear it wasn't
my imagination!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]