Fix problems on frame-info and window-info, Fix sort-tabs

[A7R7]

It is a little complicated.

Let me first point out the problems

The emacs built-in function (frame-position) (that are called inside (holo-layer-get-emacs-frame-info)) have problem running on hyprland, gnome-wayland and maybe other wayland-wms. It returns (0,0) on hyprland and something else on gnome-wayland. Therefore there should be a patch.

The good news is that there's already a patch, (holo-layer--get-frame-coordinate). The problem is that this patch was used in (holo-layer-get-window-info). (holo-layer-get-emacs-frame-info) didn't receive this patch.

Therefore, the plugins that only rely on frame-info do not draw correctly. For example, sort-tabs, cursor-animations, and therefore they have an offset to the right place.

But there're plugins that rely on both frame-info and window-info, for example, window-borders. It draws at x = frame_x + window_x, .aka it's treating window_x as an offset on x relative to frame. However frame_x from (holo-layer-get-emacs-frame-info) doesn't get patched, window_x from (holo-layer-get-window-info) get's patched (which is wrong if we treat window_x as an offset on x relative to frame). The two wrong thing add together and result in a right thing. So we get window-borders drawing at the right place!

Two ways to fix this

1. patch (holo-layer-get-emacs-frame-info), remove patch in (holo-layer-get-window-info). This will treat window-info as offsets relative to emacs-frame.

2. patch (holo-layer-get-emacs-frame-info), do not touch (holo-layer-get-window-info), remove the use of emacs_frame_info in window-borders and possibly other plugins. This will treat window-info as absolute coordinates on the desktop.

Currently I choose the first way. But this fix is possible to break other stuffs on other kinds of desktops.

Fix on sort tabs

it seems that sort-tabs was not respecting emacs_frame_x but respecting emacs_frame_y.

[manateelazycat]

可以中文解释一下吗？没看懂啥意思

[manateelazycat]

我刚刚在本地测试了这个补丁， 这个补丁合并后， 在 Gnome XWayland 环境下， 单显示器单Emacs Frame的情况下， sort-tab 无法显示。

[A7R7]

可以中文解释一下吗？没看懂啥意思

抱歉，我也觉得我写的令人难以理解。我觉得从bug现象的角度出发更容易理解，而不是从修复的角度。

现象

在hyprland下，sort-tabs和cursor-animations的绘画有偏移，而window-borders却绘制在了正确的地方。

原因：

(holo-layer-get-emacs-frame-info)调用了(frame-position)这个emacs内置函数，这个函数在wayland桌面下是有问题的，会因此导致sort-tabs，cursor-animations等需要读取emacs-frame坐标的插件出现绘画偏移。

但是，window-borders绘制的却没有问题，为什么呢？这是因为window-borders同时读取了emacs-frame坐标和emacs内window坐标，并且把这两个坐标相加得出应该绘制的坐标。然而emacs-frame坐标是有问题的，在hyprland下是(0,0)，之所以绘制结果没问题，是因为其读取的emacs内window坐标被补丁(holo-layer--get-frame-coordinate)加上了偏移值，这个偏移值正好是正确的emacs-frame坐标。简而言之，emacs-frame坐标上缺失的数值被emacs内window坐标加了回来。

emacs内window坐标，是由(holo-layer-get-window-info)返回的。如果我们认为(holo-layer-get-window-info)本意是返回emacs内window相对emacs-frame的坐标，那么上面的补丁就不应该加在这里，而是加在(holo-layer-get-emacs-frame-info)。这样既不会影响window-borders，也能修复sort-tabs和cursor-animations的偏移。

修复：

简而言之就是把(holo-layer-get-window-info)里的补丁转移到(holo-layer-get-emacs-frame-info)

[A7R7]

我刚刚在本地测试了这个补丁， 这个补丁合并后， 在 Gnome XWayland 环境下， 单显示器单Emacs Frame的情况下， sort-tab 无法显示。

那我可能是搞错了一些东西，等一下我看看

[A7R7]

原来我读cons用cdar了，犯了一个低级错误。现在我可以在gnome-xorg和hyprland上同时正常运行了，而且是多显示器

[A7R7]

补充：holo_layer.py 是以全屏模式启动的。但是hyprland下一个窗口的全屏会使得其所在workspace下其他窗口全部不渲染，就看不见emacs了。所以需要阻止holo_layer.py全屏，在hyprland.conf加

windowrulev2 = nofullscreenrequest, title:^(holo_layer.py)$

不过正因为hyprland的这一特性，emacs全屏后就看不到holo_layer.py了

[manateelazycat]

补充：holo_layer.py 是以全屏模式启动的。但是hyprland下一个窗口的全屏会使得其所在workspace下其他窗口全部不渲染，就看不见emacs了。所以需要阻止holo_layer.py全屏，在hyprland.conf加

windowrulev2 = nofullscreenrequest, title:^(holo_layer.py)$

不过正因为hyprland的这一特性，emacs全屏后就看不到holo_layer.py了

我早上测试了， sort-tab坐标正常了， 我因为不用 hyprland, 所以没看懂你最后这句话， 这个补丁可以合并还是要再等一等？

[A7R7]

所以没看懂你最后这句

简单的说，hyprland上同一个workspace在有一个窗口全屏后其他窗口都会变透明。所以holo_layer全屏了就看不见emacs，emacs全屏了就看不见holo_layer。

不过我后来想到，可以让emacs和holo_layer都伪全屏来共存

这个补丁可以合并还是要再等一等？

我觉得可以合并，合并后hyprland用户使用holo_layer应该不会有什么大问题了，至于其他小问题可以之后再修（

[manateelazycat]

感谢补丁