Re: ratpoison, patches, and the future

On 30 December 2014 at 01:08, Jérémie Courrèges-Anglas <[email protected]>
wrote:

>
> Hi,
>
> Joren Van Onder <[email protected]> writes:
>
> > Hi Jeff,
> >
> > I've built your ratpoison and I've been running it today. I've taken a
> > quick look at your git log to figure out what kind of things you added
> > or changed from a user perspective (so disregarding internal stuff and
> > refactoring), just to make sure I'm not missing out on something. I've
> > come up with pushwindow, pullwindow and focus_policy. Does that sound
> > right?
>

Yes, this is precisely correct. I am embarrassed that I forgot to provide a
summary of what I'd done when I sent that email. I added the commands push
and pull window (bound to 'h' and 'l' respectively, the final letter of
each of those words). This changed the binding for redisplay on 'l' (still
avalable at "C-l"), which we discussed on the list here
<http://lists.nongnu.org/archive/html/ratpoison-devel/2014-10/msg00013.html>.
Those two commands I had sent as patches.

I also added the option to change mouse focus policy. I realize now I did
not send that change to the list as patches for review, as I was holding
off whilst waiting for a response on the earlier patches, with which these
conflicted somewhat. I won't make that mistake again.



> > I really like the push/pullwindow commands, they make certain things
> > much easier.
>

Thank you.



> It's not clear to me whether push/pullwindow are just syntactic sugar or
> not, as put by Johannes Altmanninger:
>
>
> http://lists.nongnu.org/archive/html/ratpoison-devel/2014-10/msg00000.html
>

A sufficiently curmudgeonly computer programmer might claim that everything
beyond a Turing Machine is syntactic sugar. The more pertinent question to
me is whether it provides a useful abstraction (Johannes, Joren, and I say
yes; Jérémie weighs in against; hundreds more say nothing ;-) and does it
detract from those who don't want it (no complaints of additional slowness
in the command parser so far ;-).

For the ease of non-link followers, I think Johannes was expressing his
appreciation, with the nuance that it's nice to have the composable
underlying actions available as well. He proposed a couple aliases of
existing rp commands, and then remarked

"Of course these aliases are not as nice as real commands, (e.g. they
behave oddly when targeting the current frame, they may also be slower) but
combining ratpoison commands is more flexible and can match everyone's
needs."

(He will surely chime in if he is still around, now that his name has been
twice invoked. ;-)


 > In regards to the focus_policy, is there a specific reason
> > you didn't implement that as a variable (that can be modified with
> > 'set')? Not a big deal ofcourse, but I feel it would be more in line
> > with how ratpoison is currently being configured.
>

I'm amenable to that. I'll make the change. Thanks for the proposal.


Looks like we'll be able to get rid of contrib/sloppy.c,
> wheee...
>

;-)

And sloppy has some nefarious effects on modal dialogs, as it wants to
focus windows instead of frames. I won't miss that, even while mouse-based
focusing feels essential to me with 4.5K pixels on my desktop.

(Fwiw, I don't find mouse-based focusing useful at all on my laptop. YMMV.)


 > I also like your plan to support workspaces. As some other people have
> > said, rpws isn't really all that great. And I'm not sure why the
> > decision was made to implement workspaces in a perl script of all
> > things. It is much slower than the native ratpoison commands. These days
> > I tend to just use ratpoison groups because of this. This works well but
> > has some obvious limitations, because a ratpoison group is just a group
> > of windows without any kind of frame layout associated with it. Portings
> > rpws functionality into ratpoison itself would be great. (I haven't
> > looked at the code, but it might not be that hard if it's possible to
> > reuse the already existing group code and add a frame layout and
> > window->frame mappings (fdump) to each group to make up a workspace.)


Thanks for the positive feedback. I want to set up some tests and some
performance measures first, as (1) I'd like some assurance that my breakage
surface is small, and (2) I'd like to be able to brag about how much faster
it is. ;-)


Jérémie sent me some code feedback in private. Most of it was a bit
ordinary stuff that needn't be repeated. Worth repeating here, however:

   - He expressed a concern that I developed all of these on the same
   branch. Actually, I did (and do) all of my work on separate branches, but
   in frustration that the code wasn't being merged into HEAD, I did it myself
   in my repository to make it easier to use the code, both for me and for
   others to try.
   - He proposes that focus_policy become focus or focuspolicy (I prefer
   the latter, other opinions?). He also proposes that the third option be
   follows rather than ffm, I have no objection.
   - He's not so keen on my refactoring of cmd_select() and
   set_active_window_body(), suggesting they don't bring real improvement. I
   disagree. Both functions were overly long to my eye and harder to
   understand for it. (A quick git annotate on window.c even suggests that
   Jérémie may be the author of the FIXME on set_active_window_body(). ;-)

Patches will follow.

_______________________________________________
Ratpoison-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel