[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