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: Tue, 8 May 2018 12:40:01 +0200 Message-ID: References: <83muxioten.fsf@gnu.org> <5AEAB616.4040900@gmx.at> <83603zqqfv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1525775889 13525 195.159.176.226 (8 May 2018 10:38:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 May 2018 10:38:09 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 08 12:38:05 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 1fG00S-0003S1-7o for ged-emacs-devel@m.gmane.org; Tue, 08 May 2018 12:38:04 +0200 Original-Received: from localhost ([::1]:50292 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fG02Z-0003eV-EG for ged-emacs-devel@m.gmane.org; Tue, 08 May 2018 06:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fG02S-0003cY-UQ for emacs-devel@gnu.org; Tue, 08 May 2018 06:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fG02S-0001JB-2r for emacs-devel@gnu.org; Tue, 08 May 2018 06:40:08 -0400 Original-Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:39536) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fG02M-0001HY-W7; Tue, 08 May 2018 06:40:03 -0400 Original-Received: by mail-qt0-x231.google.com with SMTP id f1-v6so40301329qtj.6; Tue, 08 May 2018 03:40:02 -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=F3udObyyFXf4uyzUQAtmIXC6US98kEAGblQHlA7laxE=; b=iO+aJRVOW2sivm3eJim56Ouxcev4bNQQm2iKQ2z0rzB0+obHUwaQhzdM7wl4gEI3Dw TRul1aN7eSdBVFsTfq3tybEL2a17Kry1Ql2otOT2bHS7uS7PF8fO8oee0PYey2CyKQEs olm+iL2fSP4DHUGr2vRhaGRGmYlUZ5SAWSHfU/FVPhZGWsXRVRbpiUH4jw2N50rZ2s+R 51jdgoV5h2nk0tT0iT4VXwi2HAPTK7Qsf2IZ2dSt164OoEOlxnnqbT9xo5JLMXHa3KcL 6VjLKTNTShnlEjO0ou5v+wpHi6DNq+cJROT0locW58ZBkEt5E0G+zoj44MfL4Skv4qtM Wxpg== 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=F3udObyyFXf4uyzUQAtmIXC6US98kEAGblQHlA7laxE=; b=gq6JhBMYNlmkqIkyHr7gt0u+dQg30cvdjFSx0QTNo/ThStYqmDYX66bkpnZ1scXclx 9v1+DFIwN6t91vZmiPPB8IWY/1hZzO5tAbpGCrSKsXt+V01hhYx5uzIZC1nuzMDa5TkD hn7F1N+TNR7HwEPsZVLPbzy+tWgijr/DZ8g7Xm5zsETTfVkeCDt+9RbUAYVrIQusVGjC PqWKtOEkONnf2a6kgNMBKNISMKV32ocSA1eMpky57UGG84NKvyqP0wbsyCJEw8u8aFJY 4fjSN6Nfe/rqNtoFuY5zXUkzODfiUvPYdjLgPbByoBohk/18EGdvO0QVpOfAo1Njq1AO dt4Q== X-Gm-Message-State: ALQs6tBZzJCZtH846zl7/LRb+HUZV+D3jqfguYtSq8azWY64aiXyiNK0 +VYckLodgBOLooo2bQLJkcU5R0qXZSKO2q0an832Lj1x X-Google-Smtp-Source: AB8JxZpuGxca8Cnq8mzeHN4T+va86D7mV9M7DGRcBxUA8a34bp5b+Gd1uYaoDZ8quuXIxxlelBX91VEbUyw+ztXA3qQ= X-Received: by 2002:ac8:2329:: with SMTP id a38-v6mr37871386qta.63.1525776002017; Tue, 08 May 2018 03:40:02 -0700 (PDT) Original-Received: by 10.200.63.210 with HTTP; Tue, 8 May 2018 03:40:01 -0700 (PDT) In-Reply-To: <83603zqqfv.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-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:225150 Archived-At: > I don't remember (perhaps Martin does). But if you show a C-level > backtrace from such a call to buffer-list-update-hook, it will be easy > to say whether this is expected or not. Is there a simple way to dump a backtrace from Emacs? It's easy to reproduce tough: (defun foo () (message "buffer-list-update-hook")) (add-hook 'buffer-list-update-hook 'foo) then simply click in the selected window. Anyway according to the documentation this hook is called by `select-window` which is actually called if you click on a window, even if it is the selected one. > Do you mean that pre-redisplay-function is called? If not, what > exactly do you mean by "relayout is triggered"? Yeah, I mean I collect all the events which tell me that a relayout is needed (window created/destroyed, window/buffer selected, etc.) then finally I perform the actual relayout. If a subsequent event tells me that a relayout is needed but no window has been actually created/destroyed etc. then it's a false positive, in this case for example it happens when `pre-redisplay-function` is called, e.g., when the user clicks in the selected window. (By relayout I mean what Zoom does: `balance-windows` and resize the selected window.) > That's strange. The most frequent call to pre-redisplay-function is > in prepare_menu_bars; are you saying that function is never called on > macOS? Well, there's more than that, it doesn't seem to be a macOS thing. If I do: (defun foo (x) (message "pre-redisplay-function")) (add-hook 'pre-redisplay-function 'foo) Almost always, the hook is not called when I interact with windows and the text selection mark becomes invisible for future selections (!), even in the terminal. Otherwise (but I cannot reproduce it anymore...) the hook is called very frequently, even when Emacs is idle. Emacs 26.0.90 on Linux, using the -Q option. > If you put a breakpoint inside that function, does it never break? `prepare_menu_bars` does break but `FUNCTIONP (Vpre_redisplay_function)` is false so `safe__call1 (true, Vpre_redisplay_function, windows);` is never executed.