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