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

[David Bjergaard]

Git logs for now. I'm going to compile a change list from the logs and release 
a new version in a few weeks. 

    David

> On Aug 18, 2017, at 9:09 PM, Tim Cross <address@hidden> wrote:
> 
> 
> 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