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 10:36:05 +1000 Message-ID: <45045c06-9595-e106-890f-74a25c945876@gmail.com> References: <83fstz1cyj.fsf@gnu.org> <83ee9j1b7z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23611"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 02:37:03 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 1mSTmR-0005x2-7h for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 02:37:03 +0200 Original-Received: from localhost ([::1]:41254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSTmO-0005c4-0S for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Sep 2021 20:37:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSTld-0004wH-3b for emacs-devel@gnu.org; Mon, 20 Sep 2021 20:36:13 -0400 Original-Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]:36659) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSTlb-00007i-D1; Mon, 20 Sep 2021 20:36:12 -0400 Original-Received: by mail-pf1-x42a.google.com with SMTP id m26so17833428pff.3; Mon, 20 Sep 2021 17:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=O6lVOFCyT4G2thpNeFf3YpxYquAd51LGnI1/9x/SLrM=; b=j9mlZgc917mWcEj8cOlHRByqJTW4RPtu+bB97wk6izEmBdYk9S/ShabzLfxs1iIRTD NyoJjg96+/vthH2NFStCZeTMWcmBnDPVsSf/1qRLNOctWEUfbXTdTR6fi2vpledn4UfE d2l8jaYEkM1gW0b5qB8Jf4EoVd9esAWx5te3xWiyt+Sj56Zow/V6lpn4kZf+kz8HpU0v JFvxvG3Eu+AV30D7Qaqm9PreKYNhaznTaQVeLgOwmvWqn/ImD8xtmffvnGPIrczDHqN7 ekK4Bd8HlKtAQh8f0vFKWy2h/SiFwkmsuLTk/7ritnua6dRfOs/kblRjDVXawkjAXT6q GePw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=O6lVOFCyT4G2thpNeFf3YpxYquAd51LGnI1/9x/SLrM=; b=lYQQeSa8+yz16YERP0jVkwoIjzHzJ4PSspx4s+dVB/teWO08XiUy8M/xNZ+XmENqqq YfYXk3EtI+/hF3iHcGGjM/PSJP4pZD3B296LCM/DGO5twewmK066DTgPiu2kD+VSy24b Y/gR1zqF+939Fb7RdQHolPfgOHBdjU6QMXX4cONw2/p2p8le4js8BB0IS5enHi9PK27K loS77uisC491wfrxA6qn34bTfmrSz+FMA0bGwYukITcCFbG7iNYWZrkwpaVYkgu/cWJZ pkc7fcMb+gB57czSBrciq0RS2zeg708dp/em6zVnIv6wa4nkKgRevchu1CeEhTyOikoL WqkQ== X-Gm-Message-State: AOAM533Kc+t45L9j2eWcyLMnrAPplq6VeOrst/jmYwz7TyG+3TG+nxey 2QOXC7mWeLSsf3rveCrPOz0ywMiITBA= X-Google-Smtp-Source: ABdhPJy+f2pFzY9vUGwWPp0LjErb49m8QsM4azgNRo3NHcKrajWq6+mXBubxBKMguliPu0FKmzy3FQ== X-Received: by 2002:a05:6a00:a8a:b029:356:be61:7f18 with SMTP id b10-20020a056a000a8ab0290356be617f18mr27628716pfl.29.1632184568304; Mon, 20 Sep 2021 17:36:08 -0700 (PDT) Original-Received: from ?IPV6:2402:b801:2844:2100::1? ([2402:b801:2844:2100::1]) by smtp.gmail.com with ESMTPSA id q21sm492691pjg.55.2021.09.20.17.36.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Sep 2021 17:36:07 -0700 (PDT) Content-Language: en-US In-Reply-To: <83ee9j1b7z.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::42a; envelope-from=ideasman42@gmail.com; helo=mail-pf1-x42a.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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, NICE_REPLY_A=-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:275183 Archived-At: On 9/21/21 02:08, Eli Zaretskii wrote: >> From: Campbell Barton >> Date: Tue, 21 Sep 2021 01:50:47 +1000 >> Cc: emacs-devel@gnu.org >> >>> I'm not sure I understand how would that work. Timers run as part of >>> the Emacs main command loop, so they are by their nature global. How >>> did you imagine that a buffer-local timer would express its "locality"? >> >> Yes, the idle timers themselves would be global, but only some buffers >> would have call-backs registered to run with these timers. >> >> Exactly how this works internally is an implementation detail, for the >> purpose of discussion it could work like this: >> >> ;; Setup might look like this. >> (setq-local my-timer-handle (run-with-idle-timer-local delay t 'my-fn)) >> >> Internally a pool of repeating timers would be kept, one for each >> unique delay used by one or more handles, this handle would be created >> and added to a list of handles associated with this timer. >> Running the timer would loop over callbacks running them if their >> buffer matches the current buffer. > > So you want such a "buffer-local" timer call its timer function only > if/when the buffer is the current buffer? That raises some issues > that I think would need to be figured out: Right, there are indeed some wrinkles to figure out... my sense is it's only practical to do this if it fits well with the existing global timers. > > . 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 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. > . 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 may be that all things considered - there are too many ambiguities and corner cases for this to be implemented cleanly. To be sure of this I think I'd have to attempt to write a small API to test if it's practical. Again, this is meant to be an alternative to packages registering their global repeating idle timers that are never removed. 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.