stumpwm-devel
[Top][All Lists]
Advanced

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

Re: [STUMP] key press detection lag?


From: J. David Smith
Subject: Re: [STUMP] key press detection lag?
Date: Tue, 18 Feb 2014 01:29:03 -0500

I've actually had issues in Arch where, after an SBCL upgrade, I was forced to recompile before it'd load my stump config. Dunno if the core problem was the upgrade or something else entirely, but recompiling fixed it.


On Tue, Feb 18, 2014 at 12:25 AM, Sam Kleinman <address@hidden> wrote:

Just to clarify how compiling stump works (on arch):

You can upgrade SBCL and unless you recompile/upgrade stump with the new
version of SBCL you won't get the benefit of any changes to SBCL. At the
same time, you don't *need* to recompile stump when you upgrade SBCL: it
will continue to run without issue, but it's usually a good idea to
recompile.

Cheers,
sam


On Saturday, February 15 2014, 11:41:28, Eric Abrahamsen wrote:

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


--
Sam Kleinman (tychoish):
 - address@hidden
 - tychoish <http://tychoish.com/>
 "don't get it right, get it written" -- james thurber

_______________________________________________
Stumpwm-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel


reply via email to

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