bug#58964: 28.2; `file-notify--handle-event` setting callback function to nil

[Alejandro Pérez Carballo]

Hi Michael, 

Thanks for writing back. 

> This is not a valid call of `file-notify--handle-event', see its
> docstring how it shall be applied.

I've looked at the docstring but don't really see why what I gave is not a 
valid call of the function. 

    Signature
    (file-notify--handle-event DESC ACTIONS FILE FILE1-OR-COOKIE)
    
    Documentation
    Handle an event returned from file notification.
    
    DESC is the back-end descriptor.  ACTIONS is a list of:
     created
     changed
     attribute-changed
     deleted
     renamed           -- FILE is old name, FILE1-OR-COOKIE is new name or nil
     renamed-from      -- FILE is old name, FILE1-OR-COOKIE is cookie or nil
     renamed-to        -- FILE is new name, FILE1-OR-COOKIE is cookie or nil
     stopped           -- no more events after this should be sent


I thought the descriptor would just be one of the keys in the hash table that 
is the value of `file-notify-descriptors', but maybe I'm misunderstanding how 
that's all supposed to work. So basically, the call that's giving me the error 
is this: 

    (file-notify--handle-event 18 '(renamed attribute-changed deleted) 
"/Users/apc/tmp/test.el" nil)

Is that not a valid call? (I was passing as first argument `(car 
(hash-table-keys file-notify-descriptors))` because I thought it would be 
easier to use for reproduction purposes than asking people to see what the key 
associated with the visited file in `file-notify-descriptors` was.)

As for your other questions: I am not trying to call this function directly, 
but instead trying to find the source of an error message I've been getting on 
and off for months. After leaving `debug-on-error' on for a while, I finally 
got a backtrace. From what I could tell, that was the cause of the trouble. 
Something in my system is making a call to `file-notify--handle-event' with 
similar arguments (it was a different file, and a different key, the one that 
in fact was associated with the file in question in the 
`file-notify-descriptors` table). 

Unfortunately, I cannot find the original backtrace information. If indeed what 
I provided was not a valid call of the function, I'll have to wait until next 
time the error shows up and see if I get more information about what could be 
making that invalid call in my system. 

Best, 

A.

> On Nov 3, 2022, at 3:46 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> Alejandro Pérez Carballo <apc@umass.edu> writes:
> 
> Hi Alejandro,
> 
>> The following minimal configuration can be used to trigger the bug on my
>> end, replacing “~/tmp/test.el” with a path to a file of your choice:
>> 
>>    (require 'filenotify)
>>    (require 'autorevert)
>>    (require 'subr-x)
>>    (global-auto-revert-mode)
>> 
>>    (save-window-excursion
>>      (find-file "~/tmp/test.el"))
>> 
>> Once that’s loaded, calling this:
>> 
>>    (file-notify--handle-event (car (hash-table-keys 
>> file-notify-descriptors)) '(renamed attribute-changed deleted) 
>> (expand-file-name "~/tmp/test.el") nil)
>> 
>> gives me an error
>> 
>>    file-notify--call-handler: Symbol’s function definition is void: nil
> 
> This is not a valid call of `file-notify--handle-event', see its
> docstring how it shall be applied.
> 
> Furthermore, this function is an internal one which shouldn't be called
> from outside filenotify.el. What's your use case for this?
> 
> Best regards, Michael.