stumpwm-devel
[Top][All Lists]
Advanced

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

Re: [STUMP] key binding missing in git version?


From: Tim Cross
Subject: Re: [STUMP] key binding missing in git version?
Date: Sat, 19 Aug 2017 11:09:26 +1000
User-agent: mu4e 0.9.18; emacs 25.2.1

thanks David. Yes, so far, enjoying the experience.

Thanks for the answers.

With respect to the second one, if I understand correctly, what your
saying is that for whatever prefix key you use, the unmodified version
of that key becomes the escape sequence to send the modified version to
the underlying application - I should have realised that and now I
notice that "s-s s" is in fact defined as the escape key in the key
binding list.

Is there any way to get an overview of what has changed since the last
released version and the current dev version, like a changelog or do we
need to just extract git logs?

Tim


David Bjergaard writes:

> Hi Tim!
>
> Welcome to the club!  I hope that you are finding the transition easy.  I'm
> guessing that:
>
> 1. The answer is a window stating: "rc file loaded successfully." which 
> happens
>    when the RC file is loaded. I haven't dug into the code deeply enough to 
> see
>    if that also gets printed when StumpWM loads or not.
>
> 2. Sounds like a legitimate issue.  If you are setting this with
>    (define-prefix-key (kbd "s-s")), you are overriding the 's' keybinding so
>    that "s-s s" sends a "Super+s" signal to the underlying application.  This
>    clobbers the "C-t s" behavior that splits vertically.  You need to move the
>    vertical split to something else (maybe "s-s v"? since that defaults to
>    version and you can always get the version from the colon command).  If 
> this
>    still doesn't work, please open an issue with us on github.
>    
> David
>
>
> Tim Cross <address@hidden> writes:
>
>> Hi All,
>>
>> Warning - new stumpwm user!
>>
>> I've just started using stumpwm (actually, I used it a long time ago for
>> a short period and am now returning to it).
>>
>> I've noticed a minor issue, but not sure if it is something I've got
>> wrong or just something wrong in stumpwm and wanted to check if it is a
>> known issue or not. 
>>
>> I started initially with the stumpwm package from Ubuntu 16.04 and
>> managed to get a pretty workable setup quite quickly. Initially I was
>> using the supplied cl-* packages which are available with Ubuntu.
>>
>> I got my stumpwmrc file setup such that I have a workable environment -
>> keeping things pretty simple until I have a deeper understanding of
>> stumpwm and can then start tweaking to suit my requirements. All good.
>>
>> I then thought I'd try the git version as it seems it has been a while
>> since the last 'official' release. To also ensure related packages were
>> a later version, I also installed quicklisp and moved from the Ubuntu
>> cl-* packages to ones installed by quicklisp.
>>
>> All has gone well except for two minor issues.
>>
>> 1. When I first run stumpwm, I get the standard welcome message window,
>> but hidden just under that window is another message window, but I don't
>> know what is in it or how to find out. I know it is there because it is
>> slightly larger than the message window, so you can see the border and
>> part of what looks like a 'r' character. How can I find out what this
>> is?
>>
>> 2. I seem to be having a problem with one of the 'standard' key
>> bindings. The binding for vsplit does not seem to do anything. I can
>> issue the command directly using the colon prompt and it works fine and
>> hsplit works fine, but not the vsplit binding. I have changed my prefix
>> key from C-t (control+t) to s-s (super+s), which may be relevant, though
>> everything worked when I was using 0.99 - this only seems to have become
>> an issue since moving to the git head.
>>
>> I'm not asking for anyone to solve this - just wanted to know if there
>> may be a known issue which could be relevant and hoping for some
>> pointers which may help in the diagnosis.
>>
>> Finally, just wondering what the preferred approach is for supplying
>> fixes/updates. In particular, I see much of the information in the wiki
>> is out of date or scant on detail. Is the preferred approach to just do
>> a fork and then send pull requests?
>>
>> thanks,
>>
>> Tim


-- 
Tim Cross



reply via email to

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