bug#51094: Check if run-with{-idle, }-timer needs to create a timer

[Philip Kaludercic <philipk@posteo.net>]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:


> Philip Kaludercic [2021-10-08 09:36 +0000] wrote:
>
>> I have seen a few packages use run-with-timer or run-with-idle-timer,
>> where the SECS parameter is configurable with a user option. When this
>> timer doesn't repeat itself and it makes sense to set SECS to 0 when you
>> want something to run immediately, I don't think it makes sense to
>> create a timer object.
>
> IIUC, the semantics of SECS=0 (alias nil) is not the same as eager
> funcall, because timer functions are intended to be run asynchronously
> in a separate command loop.  So often what is meant by "now" is e.g. "as
> soon as I quit the current active minibuffer".

I see, it might be necessary to consider examples where this might go
wrong.

> I realise this patch does not touch run-at-time, but it's documented as
> being interchangeable with run-with-timer, so the eager funcall sounds
> like a breaking change.
>
> If packages indeed want to run something immediately, why create a timer
> at all?  Or am I misunderstanding something?

Because you might want to delay certain things, such as highlighting or
completion. It makes sense on older devices, but modern systems can run
a lot of things immediately. Consider lazy-highlight-initial-delay or
the icomplete options. On my desktop I have no issue with setting
lazy-highlight-initial-delay to 0 but on my laptop I keep the default
value.

> Thanks,

-- 
	Philip Kaludercic