From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Inferred function types in the *Help* buffer Date: Thu, 01 Jun 2023 09:34:52 -0400 Message-ID: References: <83o7manh0e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16220"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Andrea Corallo , Eli Zaretskii , emacs-devel To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 01 15:35:37 2023 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 1q4iSl-00041X-Hp for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 15:35:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4iS7-00064H-F0; Thu, 01 Jun 2023 09:34:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4iS5-000643-Hh for emacs-devel@gnu.org; Thu, 01 Jun 2023 09:34:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4iS5-0005xF-5T; Thu, 01 Jun 2023 09:34:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=soXcEK9Ysdg3A6+vdc0ABYKX4gidFJcfjFoeTzs6v/s=; b=PnmnJs9pbmWJraTjMro1 tY0ynID+2SZ/TxzYqjigK78JP/3lkx5Fj0f29TEDoO4ZxDnWHfIJt4grDlyg5DRUucj8Oy/FENdH5 KxoswL3kbRa6+bPu55vBmOHBl0DoH8Mn67IGzviRiOBavFUVcbneCvtjTx4yvwkPuF5UJ52Ju5F6T G4lj8FN1cETdyVrVGZX+ZRo/vePyiXoHKrw3Vt63BX0+dAw9saQxdPts3qqUG2rmasW+bs1fpAXuO 130R8iDe3TRgNBnDW7pLOKstuvsicTGitNNxa5eKo0FQ6PYhNNlnLwc6jXSbBMzs5vA+0xivMcfhs Ejrh1pBPwPAq9g==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1q4iS4-0005gT-UG; Thu, 01 Jun 2023 09:34:52 -0400 In-Reply-To: ("Mattias =?utf-8?Q?Engdeg=C3=A5rd=22's?= message of "Thu, 1 Jun 2023 15:06:24 +0200") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306514 Archived-At: Mattias Engdeg=C3=A5rd writes: > 1 juni 2023 kl. 13.50 skrev Andrea Corallo : > >> 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