GNU bug report logs - #66554
[PATCH] Add the public API of Compat to the core

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 66554 <at> debbugs.gnu.org, philipk <at> posteo.net, stefankangas <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#66554: [PATCH] Add the public API of Compat to the core
Date: Sat, 10 Feb 2024 21:12:00 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: philipk <at> posteo.net,  66554 <at> debbugs.gnu.org,  stefankangas <at> gmail.com,
>   monnier <at> iro.umontreal.ca
> Date: Sat, 10 Feb 2024 19:14:38 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Daniel Mendler <mail <at> daniel-mendler.de>
> >> Cc: Philip Kaludercic <philipk <at> posteo.net>,  66554 <at> debbugs.gnu.org,
> >>   stefankangas <at> gmail.com,  monnier <at> iro.umontreal.ca
> >> Date: Sat, 10 Feb 2024 18:40:21 +0100
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> From: Philip Kaludercic <philipk <at> posteo.net>
> >> >> Cc: mail <at> daniel-mendler.de,  66554 <at> debbugs.gnu.org,  stefankangas <at> gmail.com,
> >> >>   monnier <at> iro.umontreal.ca
> >> >> Date: Sat, 10 Feb 2024 16:46:30 +0000
> >> >> 
> >> >> I might be mistaken, but from a cursory peak at package.el, specifically
> >> >> `package-activate-1', the Info search path is only updated if the
> >> >> package is activated.  If the core-package takes priority over an
> >> >> external package, the external package shouldn't get activated.
> >> >> 
> >> >> This hasn't been a problem in the past, because core packages don't come
> >> >> with their own manuals, but this is an exception since core-Compat is
> >> >> not really the same code as ELPA-Compat.
> >> >> 
> >> >> One way to fix this, would be to explain how to disable a package via
> >> >> `package-load-list' in the Compat manual.  I'll have to try it out, but
> >> >> if it works, I think that solution should be acceptable.
> >> >
> >> > Another way to fix this is simply to include the Compat manual in
> >> > emacs.git.
> >> 
> >> No, this won't be useful. The Compat manual available at a given time is
> >> not relevant for the Emacs version developed at that time. If we would
> >> include the manual Compat 30 in Emacs 30, the manual will document
> >> functionality already present and documented in the Emacs 30 manual
> >> itself. The Compat 30 manual is only relevant for Emacs versions 29 and
> >> older.
> >
> > People who actually install and activate Compat from ELPA will have
> > the manual which comes with it first on the Info search path, no?  So
> > where's the problem, and what does "won't be useful" mean in this
> > context?  To recap, we are discussing ways to make the cross-reference
> > to the Compat manual work in as many use cases as possible, in
> > particular when Compat is either not installed or "not activated".
> 
> I assume it will lead to less confusion if we focus on documenting the
> compat.el functionality in the Elisp manual and refer to the Compat
> manual on ELPA via an http link, instead of copying the Compat manual.
> There should not be a cross-reference problem then?

But we will be back to the issue of having too much to say in the
ELisp manual about a relatively minor, perhaps even obscure, aspects.
Which is why I'd prefer not to have all the information in the ELisp
reference.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.