Re: [STUMP] key press detection lag?

[Eric Abrahamsen]

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!

E