Re: [STUMP] key press detection lag?

[Eric Abrahamsen]

David Bjergaard <address@hidden> writes:

> 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 1.1.1.0.debian, 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.

Yeah, I have no idea at this point. The arch sbcl package had been at
1.1.14 previously. I downgraded back to 1.1.14, and then to 1.1.12, and
my highly-unscientific testing methods showed no particular slowdown. I
never succeeded compiling with clisp, despite following several recipes
mentioned on the wiki and other places.

The problem is I saw the slowdown after a _stumpwm_ upgrade, not an sbcl
upgrade. Perhaps I didn't do a "make clean" when I rebuilt and was
somehow running uncompiled files, or else it was smurfs. Sorry for the
noise!

> Cheers,
>
>     Dave
>
> 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
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel