Re: [RP] ratpoison, patches, and the future

[Jeff Abrahamson]

On 30 December 2014 at 01:08, Jérémie Courrèges-Anglas <address@hidden> wrote:

Hi,

Joren Van Onder <address@hidden> 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. 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.