From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Campbell Barton Newsgroups: gmane.emacs.devel Subject: Re: Possible support for buffer local idle timers? Date: Tue, 21 Sep 2021 20:19:44 +1000 Message-ID: References: <83fstz1cyj.fsf@gnu.org> <83ee9j1b7z.fsf@gnu.org> <45045c06-9595-e106-890f-74a25c945876@gmail.com> <834kae1mya.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="676"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 12:21:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mScuM-000AXL-7O for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 12:21:50 +0200 Original-Received: from localhost ([::1]:38796 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mScuL-0002e4-0d for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 06:21:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mScsZ-0000o5-GF for emacs-devel@gnu.org; Tue, 21 Sep 2021 06:19:59 -0400 Original-Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]:37495) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mScsX-0001gU-OV; Tue, 21 Sep 2021 06:19:59 -0400 Original-Received: by mail-pj1-x102b.google.com with SMTP id me5-20020a17090b17c500b0019af76b7bb4so1596417pjb.2; Tue, 21 Sep 2021 03:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O4CzLLdKR7tWMpSBPUqihOKa4aHhPV5XNosdrgtWKaY=; b=LTCP2l5J7yDOi3Y4IXv3wWuzl4MUreKzLZWW4HOh9xZDKUr0oR87r7OOmd9+CSP4uH d/plnlIPv5JthmWbUj0eQhtkxxWtb/kskGpV1AiO/Mg27P48EQ1VxoeK/Pb/jFgx9rIX yQhLAesOKatQz6F/T2goAVaQx83pQEHu4D0IDyVFMPPz8wiXIN2sTICQ5RFvfQGule8M xcitgQPzKWA9LIHobmXJ/ELC2+4Sqzy2HKjDHUHaNcsunb/4dJz1vwGWv76gkiim+qCe uleAOMb3G1u0p8VkGr5H0LPmFRQmO32b7QaF2VVyvS45suFwYkxN3QdpzPNVU1tHGf9V kyXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O4CzLLdKR7tWMpSBPUqihOKa4aHhPV5XNosdrgtWKaY=; b=4PX3yCDc8vY2yQ4eT2SlLIFjk+wxE75bbU1pSuzfwWwcwFiww+ObtulSXO9jvh11D4 rCY0fiOTWhmhFM1bNBqNHBI2zOtOn8QSCqrSGA6I2mtKPMcAyrZVP7YkFQr23+R120NK K5D4GSm9+kUViLxZdRU7hGMM5tWSZLf6I90Cmvuo69LgAoeIyjWcL3fI8O8bQNU/rsmB EBKS9OEkN+RsSB8XrRditdBCkPAa+Tvxifg4G7ZUotHZrmw9vfTzH2c/mFeA69gfundG ZFFVv0wBMpa+e2KO74WG0Q7MYTEpQiwdcY7NSwNBsGAZyBaIgF/cAbMrnYshfYz1Uz+g 66WA== X-Gm-Message-State: AOAM530We36zOkHF7zmqWv0Lw2URNcROoJBnrgqzlix0bDuj/Lvqf8lc ualvKZCtTUYuDe5XcADVv/Thd9z3AkLBx/K4hIrAKYDE2qc= X-Google-Smtp-Source: ABdhPJyUqLMZ1+UudPhVwfK/Rulwxb+fynazbXjoKVF0mMx4Pm4KO3eOs9aHY4BAitBDJxS3oEMGlqGrftKCFrrNmzY= X-Received: by 2002:a17:90b:4d08:: with SMTP id mw8mr4323026pjb.97.1632219595554; Tue, 21 Sep 2021 03:19:55 -0700 (PDT) In-Reply-To: <834kae1mya.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=ideasman42@gmail.com; helo=mail-pj1-x102b.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275214 Archived-At: On Tue, Sep 21, 2021 at 4:07 PM Eli Zaretskii wrote: > > > Date: Tue, 21 Sep 2021 10:36:05 +1000 > > From: Campbell Barton > > > > > . does the timer start measuring idle time only when the buffer is > > > the current buffer, or regardless of that? > > > > would just go with default behavior of global idle timers since a user > > switching buffers will typically reset idle timers. > > What do you mean by "reset timers" here? I assume that the the act of switching the buffer will cause Emacs not to be idle, so after switching buffers idle timers will begin to run again as their deadlines are met. > > > > . what to do when the timer expired but the buffer wasn't current, > > > and then the buffer became current? does the callback gets called > > > right away, or do we "miss" the timer in that case? > > > > default behavior could be to run timers on the previously active buffer > > (instead of missing them), although tracking this information could get > > more involved. > > > > It may be useful for callers to request not to run in the case the > > buffer becomes inactive. > > I don't understand what you mean by "acting on a buffer". The timer > function can do anything it wants in any buffer. Yes, but as with buffer-local-variables and buffer-local-hooks it can be useful to have buffer-local-timers (or have the functionality even if they have to be implemented with global timers). > > > . how to handle repeated timers? > > > > As far as I can see repeated timers would be the primary use-case, for > > this feature. > > > > I'm not sure what you mean by "how to handle", all callbacks registered > > to run a repeated buffer local timer could share a timer, this would > > store a list of callbacks which would run each time. > > It's related to the second question: if timers don't fire when "their" > buffer is not the current buffer, then repeating timers will > accumulate. Then it becomes an issue what to do when the buffer > eventually becomes the current one: do we run the timer function N > times or just once? I would assume just once, although if it's important that a timer runs for a buffer - as opposed to the buffer loosing focus and not running the timer at all, this could be performed. > > > It may be that all things considered - there are too many ambiguities > > and corner cases for this to be implemented cleanly. > > Indeed, I think the idea is not clear enough, and in general timers do > not interact cleanly with the notion of the current buffer, which in > Emacs is very ephemeral. Emacs switches momentarily to other buffers, > including temporary buffers, a lot, so you could miss a timer tick > very easily due to that. It may be better to consider all visible buffers instead of the active buffer. ... > > > Again, this is meant to be an alternative to packages registering their > > global repeating idle timers that are never removed. > > Never removed why? because of bugs? Recently I referenced idle-highlight-mode, didn't write this package so I can only guess, I would assume this adds a global timer and never removes it's awkward to know if the global timer is still needed by any open buffers. From a quick check I suppose this could use buffer-list-update-hook, although even in that case it's a little odd to be continuously running a timer to highlight something for a buffer that might not be visible. > > If there are better alternatives to this (such as starting/stopping > > global-idle-timers on switching buffers, perhaps using: > > window-state-change-hook, then that might be better, although even then, > > it may be worth presenting this as a buffer-local-idle-timer API. > > I find the notion of stopping a timer when Emacs switches buffers > strange. A timer runs with the time, and time does not stop when you > switch buffers. There's no such notion in Emacs as "buffer-local > time", and if there were, I wouldn't know how to explain its > semantics. Why does it matter how long was a buffer the current > buffer? This is often used for calculating more computationally intensive highlighting information that's associated with a buffer-local minor mode. -- - Campbell