[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UPDATE: command: shift_edge



Hi,

On Sat, Dec 08, 2012 at 11:24:31PM +0100, Thorsten Wißmann wrote:
> But I have a bad feeling about this patch anyway, because it assumes
> that frame_move_window() doesn't behave in a cyclic way. (Which may
> change in the future...).

I just triggered an endless loop in shift_edge if focus_follows_shift is
disabled. So please update your master git branch, the first workaround
is added by commit 8b77540.

The endless loop is caused by this: Consider a tag with (at least) two
windows with the IDs 0xA and 0xB and with the following frame layout and
settings:

  herbstclient load '(clients horizontal:0 0xA 0xB)'
  herbstclient set focus_follows_shift 0
  herbstclient set default_direction_external_only 0

Then this command triggers an endless loop:

  herbstclient shift_edge right

This causes shift_edge to constantly shifting the window in that frame
to the right, which just swaps the windows. So there again is a window
at index 0 which can be shifted again. I.e. the layout cycles infinitely
between these two layouts:

  - (clients horizontal:0 0xA 0xB)
  - (clients horizontal:0 0xB 0xA)

The quick fix is two remember focus_follows_shift, set it to 1 and reset
it to its original state after the loop. This is done by 8b77540.

So the open question is: What's the cleanest and best fixup?

  - Solution A: manually shift the window to the edge instead of
    calling the shift command. This also would cause that locking and
    unlocking the monitors isn't needed anymore in shift_edge.

  - Solution B: Remove the setting focus_follows_shift. Is anyone
    out there using this option with the value 0? This option was
    initially added for compatibility because the initial shift-command
    didn't reset the focus.

    Please inform me via irc or the ML if you are using
    focus_follows_shift = 0.

  - Solution C: Do A and B.

Discuss!

Regards,
Thorsten