Re: [STUMP] key press detection lag?

[Eric Abrahamsen]

"J. David Smith" <address@hidden> writes:

> 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.

Yeah, I got so many "XXXX was compiled with a previous version of SBCL"
errors that I got into the habit of recompiling every time. I don't
think stump itself ever produced those errors, but cl-ppcre or other
commonly-used packages.

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