unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 73626@debbugs.gnu.org
Subject: bug#73626: 30.0.91; Type specifiers of functions
Date: Fri, 25 Oct 2024 05:35:30 -0400	[thread overview]
Message-ID: <yp1ldycsexp.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <86ikthcxjx.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 Oct 2024 18:47:46 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: 73626@debbugs.gnu.org
>> Date: Wed, 23 Oct 2024 18:29:06 -0400
>> 
>> Hi Eli,
>> 
>> sorry for being late on this.
>
> No sweat.
>
>> >  . what is the importance of inferred vs declared type
>> 
>> The user get to know that the function type was computed by the compiler
>> or manually declared by the user.
>
> And why is that important?

I think might be informative for the user to know if the interface was
intentionally declared by the programmer or just inferred by the
compiler.  Of course this my evaluation is somehow subjective.

>> >  . how to read the type specifiers,
>> 
>> The format is the same described for type declarations ((elisp)Top >
>> Functions > Declare Form).
>
> OK, but the relation of that to what we show in the *Help* buffers is
> not obvious.

Agree.

>> I agree we should probably better document this somewhere else, probably
>> in Lisp Data Types?
>
> We need first mention this in "(emacs)Name Help", with a
> cross-reference to wherever we describe that in the ELisp manual.  I
> tend to think that the main place where this is described in ELisp
> manual is somewhere in Lisp data Types, perhaps in Type Hierarchy.
>
>> >  . why "C-h f" shows this information only for some functions and not
>> >    for others, and what is the significance of that
>> 
>> C-h f does not show the inferred type if the functions has still to be
>> native compiled and loaded, the reason is simply that is the native
>> compiler computing the type.
>
> This should also be documented in "Name Help", I think.
>
>> > Bottom line: we decided that this information is important enough to
>> > show it in the *Help* buffer, so we should explain its arcane parts to
>> > make them useful.
>> 
>> Agree. Is '(elisp)Top > Lisp Data Types' a reasonable place for that?
>
> Yes, I think so.

Ok gonna work on this.

  Andrea





  reply	other threads:[~2024-10-25  9:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04 12:25 bug#73626: 30.0.91; Type specifiers of functions Eli Zaretskii
2024-10-19  7:01 ` Eli Zaretskii
2024-10-23 22:29 ` Andrea Corallo
2024-10-24 15:47   ` Eli Zaretskii
2024-10-25  9:35     ` Andrea Corallo [this message]
2024-10-25 10:19       ` Eli Zaretskii

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=yp1ldycsexp.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=73626@debbugs.gnu.org \
    --cc=eliz@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).