Subject: Re: bug#9891: 24.0.90; Duplicated entry at the info directory

From: Eli Zaretskii <[email-masked]>
Date: Tue, 01 Nov 2011 07:32:32 -0400

> From: Juri Linkov <[email-masked]>
> Cc: Dani Moncayo <[email-masked]>,  [email-masked]
> Date: Tue, 01 Nov 2011 11:29:48 +0200
> 
> > This is not specific to your setup.  Emacs deliberately includes in
> > Info-directory-list both the source and the installation directories.
> 
> I think duplicate entries is not a problem.

If they aren't, then why do we have Info-dir-remove-duplicates?

> The problem is that selecting a menu entry from the installation
> directory navigates to the manual from the source directory, because
> their filenames are not absolute in `dir'.  This is too confusing.
> I think that menu entries from the installation directory should
> lead to the manuals in the installation directory, and menu entries
> from the source directory should lead to the manuals in the source
> directory.

This is not specific to the situation with source and build
directories.  This will happen any time you have identical entries
collected from different DIR files, each one of them referring to a
different copy/version of the same manual.  Info always searches for
each file along Info-directory-list (INFOPATH for the stand-alone Info
reader) in the order of the directories in that list, and displays the
first matching manual it finds.  As long as this is the way it works,
you will be unable to solve this problem.  It's like with searching
exec-path for executable programs or load-path for Lisp libraries.

Even if you convert the file names in DIR entries to absolute form
(which I think is wrong, see below), there are cross-references to
other manuals inside each manual, which all use non-absolute file
names; they are looked up using the same search order as described
above.  That way lies madness.

Emacs does try to arrange Info-directory-list in the order that makes
some sense when there are duplicates (see the doc strings of this and
the related variables).  That logic should mostly work, but if it
doesn't, I see no way around it except for the user to customize the
list or to re-arrange her Info directories.

Converting the file names into absolute ones means we diverge even
more from the stand-alone Info reader, and effectively abandon any
attempt to remove duplicate entries, instead _forcing_ the user to
have duplicates.  I don't think this is a good idea, because the
underlying problem is eventually that of the user or the sysadmin.