emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inferred function types in the *Help* buffer


From: Andrea Corallo
Subject: Re: Inferred function types in the *Help* buffer
Date: Wed, 31 May 2023 08:19:31 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Andrea Corallo <acorallo@gnu.org> writes:

> Mattias EngdegÄrd <mattias.engdegard@gmail.com> writes:
>
>> 30 maj 2023 kl. 18.46 skrev Andrea Corallo <acorallo@gnu.org>:
>>
>>> Ideally I think we should have a declare syntax and maybe an extention
>>> to the DEFUN macro to cover for primitives as well, in order to have
>>> these declaration where each function is defined.
>>
>> That would probably be a good thing in the long run, yes. There are other 
>> declarations we would like to be able to attach to DEFUN as well.
>
> Hi Mattias,
>
> thanks for your feedback.
>
> yep agree, I think we should convey on a syntax for everything we want
> to express (type and other properties), so we have something to
> implement on the long run both for the Lisp both for the C side.
>
>>>  But probably for now
>>> something like the attached patch is sufficient and considerably less
>>> invasive?
>>
>> Actually it sort of increases coupling; I'd rather it stayed in
>> comp.el for the time being. You could write a function (in comp.el)
>> for access.
>
> The main reason why I'd like to move them out is not to require the load
> of comp.el for a simple C-h f.  Secondary yeah I think that if it's in
> use outside the compilation functionality should just not live there.

Thinking about more I can't see why we should force people to load
comp.el for a simple C-h f.  If this data is consumed by both comp.el
and help-fns.el it should stay in a commonly available place.

Moreover this functionality would be available to non native compiled
Emacsen as well, so forcing the load of comp.el feels to me even more
odd.

  Andrea



reply via email to

[Prev in Thread] Current Thread [Next in Thread]