Re: Inferred function types in the *Help* buffer

[Andrea Corallo]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 1 juni 2023 kl. 13.50 skrev Andrea Corallo <acorallo@gnu.org>:
>
>> if something will prove not to
>> be correct we'll just fix it as we do for everything else.
>
> I think the general idea is fine. What I meant was that some type
> specifications can be more of a hindrance than help, in the same way
> that we in some docstrings prefer to override the automatically
> generated argument signature -- for better precision, or to avoid
> confusing the user with technicalities or obsolete arguments.

Are you suggesting we need some kind of override method for this?

> There may also be a problem of inaccuracy, and here is a little
> anecdote. I needed a table of boolean functions that only return nil
> or t for the byte-compiler, so I tried to use
> comp-known-type-specifiers.
>
> Either I misunderstood what a return value of `boolean` means, or that
> list is riddled with errors. The following functions are specified to
> return boolean in comp-known-type-specifiers but actually may return
> other values as well:
>
>   proper-list-p
>   buffer-modified-p
>   coordinates-in-window-p
>   custom-variable-p
>   file-locked-p
>   file-symlink-p
>   frame-visible-p
>   framep
>
> and, since we have no guarantees about what file handlers actually return,
>
>   file-directory-p
>   file-exists-p
>   file-newer-than-file-p
>   file-readable-p
>   file-writable-p

Again, if you've found these to be incorrect that's a bug we already
have in the code in use.  They had to be reported/looked into since
probably the time we noticed this inchoerence for the first time.

Best Regards

  Andrea