unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattias.engdegard@gmail.com>
To: Andrea Corallo <acorallo@gnu.org>
Cc: Andrea Corallo <akrl@sdf.org>, Eli Zaretskii <eliz@gnu.org>,
	emacs-devel <emacs-devel@gnu.org>
Subject: Re: Inferred function types in the *Help* buffer
Date: Thu, 1 Jun 2023 16:50:40 +0200	[thread overview]
Message-ID: <F3D30064-D251-4518-83D7-234B3F78D2FF@gmail.com> (raw)
In-Reply-To: <yp1mt1jmhkz.fsf@fencepost.gnu.org>

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





  reply	other threads:[~2023-06-01 14:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 16:44 Inferred function types in the *Help* buffer Andrea Corallo
2023-05-24 10:46 ` Eli Zaretskii
2023-05-24 12:19   ` Andrea Corallo
2023-05-30 16:46     ` Andrea Corallo
2023-05-30 18:14       ` Mattias Engdegård
2023-05-30 18:48         ` Andrea Corallo
2023-05-31 12:19           ` Andrea Corallo
2023-05-31 14:08             ` Eli Zaretskii
2023-06-01 11:28             ` Mattias Engdegård
2023-06-01 11:35               ` Eli Zaretskii
2023-06-01 11:36                 ` Mattias Engdegård
2023-06-01 11:54                   ` Andrea Corallo
2023-06-01 11:50               ` Andrea Corallo
2023-06-01 13:06                 ` Mattias Engdegård
2023-06-01 13:34                   ` Andrea Corallo
2023-06-01 14:50                     ` Mattias Engdegård [this message]
2023-06-01 15:10                       ` Andrea Corallo
2023-06-01 17:53                         ` Mattias Engdegård
2023-06-01 19:13                           ` Andrea Corallo
2023-06-01 14:09                   ` Andrea Corallo
2023-05-31 13:46       ` Eli Zaretskii
2023-06-01  8:42         ` Andrea Corallo
2023-06-01  8:53           ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2023-05-23 16:47 Payas Relekar
2023-05-23 18:51 ` Philip Kaludercic
2023-05-24 12:20 ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F3D30064-D251-4518-83D7-234B3F78D2FF@gmail.com \
    --to=mattias.engdegard@gmail.com \
    --cc=acorallo@gnu.org \
    --cc=akrl@sdf.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).