Re: Inferred function types in the *Help* buffer

[Mattias Engdegård]

1 juni 2023 kl. 15.34 skrev Andrea Corallo <acorallo@gnu.org>:

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

Maybe. It depends on what the purpose of showing the type in the help test is 
in the first place.

> 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.

Sorry, I originally assumed that I had misunderstood what the types meant and 
how they were used by the native compiler. After all, I cannot take it for 
granted that internals of code found elsewhere should be neatly arranged for my 
own purposes.

> Aren't the entries we have in agreement with the docstring?  If the
> docstring is not in sync with the implementation we have either to fix
> one o the other I think.

It's a policy problem: either we trust handlers to be implemented to spec or we 
distrust them just to be on the safe side. Normally we assume that users follow 
documented rules or suffer the consequences, but in this case it may not be the 
same user who writes the handler and who calls the function, so it may be 
fairer to shield the caller by normalising the return value of all handlers in 
these and other cases.

> -    (coordinates-in-window-p (function (cons window) boolean))
> +    (coordinates-in-window-p (function (cons window) (or cons (member 
> bottom-divider right-divider mode-line header-line 
> tab-lineleft-fringeright-fringevertical-line left-margin right-margin))))

Typos here (and null is missing).

> -    (framep (function (t) boolean))
> +    (framep (function (t) (or boolean (member x w32 ns pc pgtk haiku))))

This may be too fragile. Next port won't find this place to add its name.

Of course, if we manage to put these type declarations near the function 
definitions then accuracy would likely be better and maintenance easier (and 
more likely to take place at all).