[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Info-url-for-node support more than just "elisp" and "emacs"
From: |
T.V Raman |
Subject: |
Re: Should Info-url-for-node support more than just "elisp" and "emacs" manuals? |
Date: |
Wed, 29 Nov 2023 20:43:52 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Mekeor Melire <mekeor@posteo.de> writes:
also perhaps search for the info manuals under .emacs.d/elpa?
> 2023-11-29 16:48 eliz@gnu.org:
>
>> I think we should support the manuals on gnu.org, but the problem is
>> it's hard to do that without an explicit list of all of them, and
>> that
>> list will then have to be continuously maintained to keep it
>> up-to-date.
>>
>>
>> So maybe just support all of the manuals that come with Emacs, and
>> provide a defcustom for users to extend the list by specifying
>> associations of the form (MANUAL-NAME . URL) ?
>
> I agree on the scope and will implement it.
>
> Regarding the form of the associations, it seems your suggestion would
> lead to many of duplications of URLs. I'd prefer to use the form from
> the shared code snippet, or something similar.
>
>
>> We don't begin our symbols with a slash.
> [...]
>> This is not our style of nesting parentheses.
>
> Sorry if I wasn't clear: The attached code was not meant as a patch to
> Emacs; I was just sharing my personal configuration, in order to ask
> if you're interested in a patch to Emacs.
>
>
>> > ;; Encode a bunch of characters the way that makeinfo >
>> does.
>>
>> I think if we need to follow Texinfo, we should have here a more
>> specific pointer to where this encoding by Texinfo is documented.
>
> This comment actually is from Emacs' info.el. But I will follow your request
> and investigate the Texinfo docs.
>
>
> https://git.sv.gnu.org/cgit/emacs.git/tree/lisp/info.el?h=7a5c91a2831602c3cd961158cf0b6a876852d7ac#n1806
>
>
>> Thanks.
>
> Thank you for sharing your thoughts!
>
>
> I will revisit this thread, when a patch is ready. I'll also do the
> FSF-copyright-assignment-stuff in the meantime, as the patch might be
> big enough to require it.
>
--