[Top][All Lists]

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

Re: [STUMP] key press detection lag?

From: David Bjergaard
Subject: Re: [STUMP] key press detection lag?
Date: Sat, 15 Feb 2014 12:52:36 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Eric,

It sounds like the problem is "fixing itself." If you suspect that it
really is the version of sbcl, could you please post the version you
were using?  I'm running with, and don't have any
issues.  I see that you are now running the bleeding edge of sbcl. 

Another step would be rolling back to the version before you started
noticing the lag, and seeing if that fixes the issue.  If it does we can
document this as a known issue on the wiki.  

Thanks for investigating/reporting this, I suspect as this buggy sbcl
version propagates through various repos we may see more reports similar
to yours.



Eric Abrahamsen <address@hidden> writes:

> 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
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden

reply via email to

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