From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andrea Cardaci Newsgroups: gmane.emacs.devel Subject: Re: Zoom: a window management minor mode -- best practices and questions Date: Wed, 2 May 2018 20:41:38 +0200 Message-ID: References: <83muxioten.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f443f5056b3d6fa4" X-Trace: blaine.gmane.org 1525286938 6971 195.159.176.226 (2 May 2018 18:48:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 May 2018 18:48:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 02 20:48:54 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fDwo8-0001hE-Eu for ged-emacs-devel@m.gmane.org; Wed, 02 May 2018 20:48:52 +0200 Original-Received: from localhost ([::1]:52160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDwqF-0000bD-Ck for ged-emacs-devel@m.gmane.org; Wed, 02 May 2018 14:51:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDwhD-00061J-QT for emacs-devel@gnu.org; Wed, 02 May 2018 14:41:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDwhC-00032u-5E for emacs-devel@gnu.org; Wed, 02 May 2018 14:41:43 -0400 Original-Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:46294) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fDwhA-000321-1T; Wed, 02 May 2018 14:41:40 -0400 Original-Received: by mail-qt0-x231.google.com with SMTP id m16-v6so19670481qtg.13; Wed, 02 May 2018 11:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MH+AgmkScqg2eB0Fp6LdwqMNWjp9N/jcDlDMsBOnwlk=; b=UYlv7eRJEBJmvQzGWi2NsdBSyXnP6fDUBU4zpVnoaChC2eYz6xcqI8NmU2puKPU35G Fgu3uwz9a0S8h7DDwgxzqKy4jzf4/f8fWPZ7/gi3klxnJDQrpDKD+hy0nB+GpkHOV7FZ eM4lcTWANYYu4QYxZW5RfYVoseq8I9r3WG1X3VwyB9x1xdo1D0CTRqLh7eCkhRZREkrb 5shLmQkkArvIDaST0+pavRcf/rHswoj2S8GKjJoyuZQvK8B5nxY60B/xBlASO7s8S6Ib 1cR7GKwf9YkkDdn1Cdw2bXqhlmK4Q22CAaHedb6ZaA2c8VRPH7JXneEKBO66aVlhPuXH aYqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MH+AgmkScqg2eB0Fp6LdwqMNWjp9N/jcDlDMsBOnwlk=; b=aIdw0ikRqLjMOLdiqVdRGKRuJt5NTZuhP0U556FauQixJvtn+oSB5psLNC+hlolOIQ Oz9gM6ca9v8AqCbHo89vNbU5jV+TDaZeu00rnzaK8d/WM65/tbybuTO7hTfk7q+Z6+Nm d/FKCNbIs+80O/OdMnu7tFQ2FsUoX0JnkyFVvAxcIe4NWMCepD+ZFcd54ZHWjzQr6cgC bXWUQFRvWFx8AgqsizrSoGF1I3b7eCN1xXKg70YUsVu8j8AqXX/SPQLopyxfOULEuL0w ECZQQ8eH+JqDXqqDNYdOSOedf+ICCcWrYUBMa3R+gP1tBjXuguxhNCrunTSAnM8viX3f RwYg== X-Gm-Message-State: ALQs6tBpbxVMq7h7J/YyaMkr0WG4Wd5dryuTHbZR/CVhMljFf0q1b44/ oCtroSObW3VGmhgw9flxFVLQvGXK0Ppmf6sywJSwv6Ujaag= X-Google-Smtp-Source: AB8JxZqbGsKCkWcBb0iI8oV01zX7ravxXiQWkRk4kOFNcL0qQ+aucOunhK7Qc94iauYepda0ILAXl8zgxOnSA5WCnv4= X-Received: by 2002:ac8:3d41:: with SMTP id u1-v6mr16210423qtf.168.1525286499007; Wed, 02 May 2018 11:41:39 -0700 (PDT) Original-Received: by 10.200.63.210 with HTTP; Wed, 2 May 2018 11:41:38 -0700 (PDT) In-Reply-To: <83muxioten.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::231 X-Mailman-Approved-At: Wed, 02 May 2018 14:50:06 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225037 Archived-At: --000000000000f443f5056b3d6fa4 Content-Type: text/plain; charset="UTF-8" Thanks for the answer. > I understand why you need to hook select-window, but not why you need > the other hook. Is it because there are too many functions that could > modify the window size, and you didn't want to hook all of them? The handler should be triggered in these cases: - a window is resized; - a window is selected; - a window is created (this is actually included in the "a window is resized" case); - a window changes its buffer (because it's possible to exclude certain windows from zooming so the layout should be updated accordingly). So yes, instead of trying to figure out what the functions that cause such events are (probably way too many) I simply tried to hook on the effects of such actions. > Did you try to use pre-redisplay-functions instead? Not yet, but a quick test shows that it gets called *very* often, even when Emacs is idle. I should really implement some additional guard if I decide to go that way to avoid incurring in performance issues. Also it seems to not work well with the `track-mouse` variable that I use to delay the re-layout if there is some mouse selection in progress. Besides, doesn't this in principle suffer of the same do-something-that-triggers-the-hook-inside-such-hook problem like `window-size-change-functions`? > Alternatively, we could provide some control to disable resizing of > the selected window Please elaborate on this point. How can it help this situation? On 2 May 2018 at 19:32, Eli Zaretskii wrote: > > From: Andrea Cardaci > > Date: Wed, 2 May 2018 18:31:11 +0200 > > Cc: Eli Zaretskii > > > > Zoom (https://github.com/cyrus-and/zoom) aims to enforce a fixed window > layout so that the selected window > > is always *big enough*. I think the screencast at the project page is > quite clear about the usage. > > I've seen the screencast before asking the question, but couldn't > grasp the intent well enough, probably because the display in > screencast switches windows too quickly, and it's hard to understand > what Zoom attempts to do. > > > The implementation is very simple, every time a window change is > *detected* the following happens: > > 1. `balance-windows` is called; > > 2. the selected window is resized. > > > > This, in practice, has the effect of disabling the manual resizing of > windows. > > > > The problem is that to implement the "every time a window change is > detected" part I currently hook several > > functions, specifically: > > > > (add-hook 'window-size-change-functions #'zoom--handler) > > (advice-add #'select-window :after #'zoom--handler) > > I understand why you need to hook select-window, but not why you need > the other hook. Is it because there are too many functions that could > modify the window size, and you didn't want to hook all of them? > > Did you try to use pre-redisplay-functions instead? That doesn't > necessarily tell you that the selected window is going to change or > its dimensions are about to change, but determining that for a single > window shouldn't be too expensive, right? > > Alternatively, we could provide some control to disable resizing of > the selected window -- would that be enough, in addition to hooking > select-widnow using the method suggested by martin? > > > My knowledge of the Emacs internals is quite limited but at the highest > level of abstraction what AFAIK is > > missing is a way to enforce custom window layouts and manage the windows > size. This part seems quite > > fragile / extremely hard to work with (just look at the implementation > of `balance-windows`). In addition to that > > there are some features that further complicate the situation, e.g., > side windows and not resizable windows. > > Maybe Martin will suggest a good way of doing that using the existing > facilities, if they are enough. > --000000000000f443f5056b3d6fa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the answer.

> I unde= rstand why you need to hook select-window, but not why you need
&= gt; the other hook.=C2=A0 Is it because there are too many functions that c= ould
> modify the window size, and you didn't want to hook= all of them?

The handler should be triggere= d in these cases:
- a window is resized;
- a window is = selected;
- a window is created (this is actually included in the= "a window is resized" case);
- a window changes its buffer (because it's possible to exclude= certain windows from zooming so the layout should be updated accordingly).=

So yes, instead of trying to figure out what the = functions that cause such events are (probably way too many) I simply tried= to hook on the effects of such actions.

>= Did you try to use pre-redisplay-functions instead?

Not yet, but a quick test shows that it gets called *very* often, = even when Emacs is idle. I should really implement some additional guard if= I decide to go that way to avoid incurring in performance issues.

Also it seems to not work well with the `track-mouse` vari= able that I use to delay the re-layout if there is some mouse selection in = progress.

Besides, doesn't this in principle s= uffer of the same do-something-that-triggers-the-hook-inside-such-hook prob= lem like `window-size-change-functions`?

> Alte= rnatively, we could provide some control to disable resizing of
&= gt; the selected window

Please elaborate on th= is point. How can it help this situation?

On 2 May 2018 at 19:32, Eli Zaretskii <= span dir=3D"ltr"><eliz= @gnu.org> wrote:
> Fro= m: Andrea Cardaci <cyrus.and@gmai= l.com>
> Date: Wed, 2 May 2018 18:31:11 +0200
> Cc: Eli Zaretskii <eliz@gnu.org= >
>
> Zoom (https://github.com/cyrus-and/zoom) aims to enfo= rce a fixed window layout so that the selected window
> is always *big enough*. I think the screencast at the project page is = quite clear about the usage.

I've seen the screencast before asking the question, but couldn&= #39;t
grasp the intent well enough, probably because the display in
screencast switches windows too quickly, and it's hard to understand what Zoom attempts to do.

> The implementation is very simple, every time a window change is *dete= cted* the following happens:
> 1. `balance-windows` is called;
> 2. the selected window is resized.
>
> This, in practice, has the effect of disabling the manual resizing of = windows.
>
> The problem is that to implement the "every time a window change = is detected" part I currently hook several
> functions, specifically:
>
>=C2=A0 =C2=A0 =C2=A0(add-hook 'window-size-change-functions #'z= oom--handler)
>=C2=A0 =C2=A0 =C2=A0(advice-add #'select-window :after #'zoom--= handler)

I understand why you need to hook select-window, but not why you nee= d
the other hook.=C2=A0 Is it because there are too many functions that could=
modify the window size, and you didn't want to hook all of them?

Did you try to use pre-redisplay-functions instead?=C2=A0 That doesn't<= br> necessarily tell you that the selected window is going to change or
its dimensions are about to change, but determining that for a single
window shouldn't be too expensive, right?

Alternatively, we could provide some control to disable resizing of
the selected window -- would that be enough, in addition to hooking
select-widnow using the method suggested by martin?

> My knowledge of the Emacs internals is quite limited but at the highes= t level of abstraction what AFAIK is
> missing is a way to enforce custom window layouts and manage the windo= ws size. This part seems quite
> fragile / extremely hard to work with (just look at the implementation= of `balance-windows`). In addition to that
> there are some features that further complicate the situation, e.g., s= ide windows and not resizable windows.

Maybe Martin will suggest a good way of doing that using the existin= g
facilities, if they are enough.

--000000000000f443f5056b3d6fa4--