all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefankangas@gmail.com>
To: "Harald Jörg" <haj@posteo.de>, emacs-devel@gnu.org
Subject: Re: master b62ad00981e: cperl-mode.el: Make commands and options for Perl info pages obsolete.
Date: Fri, 1 Nov 2024 15:24:13 -0700	[thread overview]
Message-ID: <CADwFkmnYPoSris+bz=Nj9LAQWOzGtZMzTS9XaUwmFFMDnK_NpQ@mail.gmail.com> (raw)
In-Reply-To: <20231026100953.6AFD7C09BE9@vcs2.savannah.gnu.org>

Harald Jörg <haj@posteo.de> writes:

> branch: master
> commit b62ad00981ec98fc07fd798a4e6e75c90aad9200
> Author: Harald Jörg <haj@posteo.de>
> Commit: Harald Jörg <haj@posteo.de>
>
>     cperl-mode.el: Make commands and options for Perl info pages obsolete.
>
>     The Perl documentation in info format is no longer distributed with Perl,
>     nor is it available from CPAN.   Point to cperl-perldoc instead.

Hi Harald,

Apologies for coming back to this after so much time, but I just noticed
this obsoletion.

I have some questions:

First, are we sure that this means that the Info manuals are not
available on any machines?  The situation with Python, for example, is
that upstream does distribute Info pages, and Debian installs these
manuals for me.  If Python upstream would change their mind, I would
fully expect the Debian package maintainers to generate these manuals
themselves.  Perhaps some distributions have taken a wiser decision?

Second, instead of obsoleting these commands, another option here would
be to provide instructions for how users could generate the Info manuals
themselves.  Maybe it's not too hard, given that Perl upstream has been
doing it for many years.  The tooling might already be there.

Third, independently of the above two points, what about users that
generate these Info manuals themselves?  Shouldn't we cater to them?
Can we do that without much hassle?

It seems to me that promoting support for Info manuals is an
increasingly uphill battle in some quarters.  However, it remains a
priority for us to do so, since it is the preferred format for manuals
in the GNU system.  It also happens to be a very convenient format for
our users, since Emacs has an extremely good built-in Info browser.

What do you think?

PS. I do find it regrettable that the Perl maintainers has taken the
decision to stop distributing Info manuals.  If I was more invested in
the Perl community, I'd probably ask them to reconsider.



           reply	other threads:[~2024-11-01 22:24 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20231026100953.6AFD7C09BE9@vcs2.savannah.gnu.org>]

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

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

  git send-email \
    --in-reply-to='CADwFkmnYPoSris+bz=Nj9LAQWOzGtZMzTS9XaUwmFFMDnK_NpQ@mail.gmail.com' \
    --to=stefankangas@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=haj@posteo.de \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.