Stefan Reichör <ste...@xsteve.at> writes: > Hi Wojciech! > > I really love these kind of ideas. > > As a heavy emacs user I know the power of these concepts. > > At least I can offer to test these features. >
Hi Stefan, Thank your interest and positive feedback! I'm on the same side - heavy Emacs user, and see started to see StumpWM from completely different perspective, I've been using Stump for quite few years now (AFAIS as you, I originate from Ion3:)), and see that it has strong fundamentals and implements quite powerful paradigm. One of the things I like it's scripted (and written) in Common Lisp what makes it very good for customisations. Emacs has it's own Lisp implementation with it's strengths and some of the drawbacks of using custom lisp implementation (It's been improved a lot, things like lexically scoped variables for instance in Emacs 24), also it has not got that choice of libraries, and most of the time we would spawn an inferior process. I have quite few ideas to implement in Stump (one of them are modes, which are obvious ones; but also another unique idea to WM would be: filters - later on I will explain what I meant by `Stump filter', I look at better and programmable completion; and things like abstraction of things being drawn in root window; improvements over floating point groups; or DSL in Lisp for performing automation; better integration with Emacs etc.). I think at some point it's visible that Emacs is well suited for most of the tasks, but Stump really rocks when it comes to global customisations and interaction between apps, customised automation. More over I think that Stump could be a sort of desktop platform of window manager framework as the Awesome claims to be. Now, it's all good when we talk about it, but what I'm currently interested is to make this ideas come true. (major Stumpers, you really make the life of contributors hard here ;) ). So if you are up to help me with testing, development or have some ideas, please do/tell/write, at least one person would be interested in modes in Stump :) - this is a good start. So the plan is that currently I think most suitable form for me would be to just post a patch here, and see what happens, if people (you) like it, and collect some feedback or refinement of the patch (I still count on any valuable ideas from people with commit access (in other word maintainers), corrections to code, suggestions, what is Stumpsh what not etc.) Now I would love to join you all on freenode (and I tried), but currently quite limited time to do it, so let's stay on ML. Now, personal (or less) question, I think you originally developed pwsafe.el for Emacs - it's a good module. (but honestly I think currently is something broken with x clipboard/selection in pwsafe and it does not work out of the box with Emacs which is pity :( - and one of the reasons I experimented with Stump), what do you think about pwsafe patch I posted few days ago, did you try to use it? (currently I found one issue with the package, it needs to be in :stumpwm package as it uses some of the not exposed functions, but ... if you load the module (at least in SBCL), apply the correction (change the name in the in-package to :stumpwm) it will not work, you need to do M-q : restart-hard and then load again patched pwsafe). If I got a positive feedback (not many users of StumpWM and pwsafe at the same time ;)) I will continue expanding this module. (currently it works in production for me). Ok that's it, so stay tuned for some good stuff coming up! > Stefan. > Cheers; Wojciech >> Hi *, >> >> I would like to ask if somebody would like to see in StumpWM a well >> known features in Emacsen, called minor modes. I researched a bit this >> topic and see that it could be useful to have at least togglable global >> keymaps per frame, window or group. To do this we would need to have >> hierarchy of keymaps, and ability to add and remove dynamically keymap >> to the parent one to ovveride/add specific keybindings. Also what I >> suspect would be useful is to define variables in local scope of frame, >> group or window. Then we would have a clean interface wrapped with some >> macros to allow user to alter behaviour using modes in StumpWM (defining >> modes, plugging keymaps, defining local variables, inheriting modes >> etc). I am sure all these had been considered before and probably are >> not new topic, however I want to emphasise that implementation of modes >> is not possible without mentioned pre-requisites. Modes would allow us >> to implement such things like: >> >> - capturing some of application specific keystrokes, modifying their >> behaviour and sending back to window >> - conditionals keybindings based on application or window class open >> in the window >> - defining new tiling behaviours in generic form of mode >> - local variables would allow whole range of context specific behaviours >> - implementing some new apps in StumpWM would be far more automated. >> clean and robust (think about just simples ones like screen lock or >> productive mode!) >> ... probably a lot more. >> >> There are lot of benefits in having some logic encapsulated in modes, >> and having these local variables that can allow customisation per frame >> or window based on specific constraints. >> >> What do you think about it? If somebody would be interested at least on >> reviewing patches or just helping me out implementing this, I would be >> grateful. Let's give chance for Stump to be better. >> >> Cheers; >> Wojciech >> >> _______________________________________________ >> Stumpwm-devel mailing list >> Stumpwm-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
