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

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

[Dani Moncayo]

There are two identical entries at the info directory (C-h i), like this one:

  * Info               How to use the documentation browsing system.

I guess that duplication isn't intended, hence this bug report.


In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601)
 of 2011-10-27 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5)'


-- 
Dani Moncayo

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

[Glenn Morris]

Dani Moncayo wrote:

> There are two identical entries at the info directory (C-h i), like this one:
>
>   * Info               How to use the documentation browsing system.

Do you have multiple info dir files with entries for `Info' on your
system, or a single dir file with duplicated entries, or multiple copies
of info's info file (maybe one compressed, one not compressed?) in
$INFOPATH (or whatever the MS Windows equivalent is)?

There is only one entry for `* Info' in info/dir in the Emacs source, so
I am not sure this is an Emacs issue.

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

[Dani Moncayo]

>> There are two identical entries at the info directory (C-h i), like this one:
>>
>>   * Info               How to use the documentation browsing system.
>
> Do you have multiple info dir files with entries for `Info' on your
> system, or a single dir file with duplicated entries, or multiple copies
> of info's info file (maybe one compressed, one not compressed?) in
> $INFOPATH (or whatever the MS Windows equivalent is)?
>
> There is only one entry for `* Info' in info/dir in the Emacs source, so
> I am not sure this is an Emacs issue.


I don't have an INFOPATH environment variable, but I've seen that,
inside Emacs, the value of the variable `Info-directory-list' is
("c:/emacs/trunk/info/" "c:/emacs/build/info/").

Each of these two directories has a `dir' file.  They are exact copies
from the emacs-trunk repository (with a single `Info' entry).

I thought this issue would have an immediate and trivial solution, but
since (a) it's something more obscure, (b) it's specific to my setup,
and (c) It's unimportant, I don't think it's worth to spend more time
on this.

So, feel free to close this report.

Thanks.

-- 
Dani Moncayo

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

[Glenn Morris]

Dani Moncayo wrote:

> I don't have an INFOPATH environment variable, but I've seen that,
> inside Emacs, the value of the variable `Info-directory-list' is
> ("c:/emacs/trunk/info/" "c:/emacs/build/info/").
>
> Each of these two directories has a `dir' file.  They are exact copies
> from the emacs-trunk repository (with a single `Info' entry).

Then I think the duplication in the info menu is expected. IIUC, info
does not make any attempt to "uniquify" menu entries (the standalone
info program behaves in the same way).

I think the only remaining issue that might be a bug is: did the normal
Emacs-on-MS-Windows build process create these duplicate directories,
or did you do something to end up in that state?

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

[Dani Moncayo]

>> I don't have an INFOPATH environment variable, but I've seen that,
>> inside Emacs, the value of the variable `Info-directory-list' is
>> ("c:/emacs/trunk/info/" "c:/emacs/build/info/").
>>
>> Each of these two directories has a `dir' file.  They are exact copies
>> from the emacs-trunk repository (with a single `Info' entry).
>
> Then I think the duplication in the info menu is expected. IIUC, info
> does not make any attempt to "uniquify" menu entries (the standalone
> info program behaves in the same way).

Aha, but then I wonder why the only entry that gets duplicated is the
`Info' one, instead of every menu entry.  BTW, the extra `Info' entry
isn't located next to the first one, but at the very end of the buffer
(just after the `SMTP' entry).

> I think the only remaining issue that might be a bug is: did the normal
> Emacs-on-MS-Windows build process create these duplicate directories,
> or did you do something to end up in that state?

My build process was pretty "normal", I think:
1. Get an updated version of the source code, storing it in
"c:/emacs/trunk/" directory.
2. "configure"
3. "mingw32-make bootstrap"
4. "mingw32-make info".
5. "mingw32-make dist".

FWIW: The above process was done from a Windows console whose PATH
environment variable has "c:/emacs/build/bin" among its directories,
where "c:/emacs/build/" holds a previous emacs build.

FWIW 2: With the official windows build
(http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.0.90-bin-i386.zip)
I don't see the duplicated `Info' entry.


-- 
Dani Moncayo

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

[Dani Moncayo]

> My build process was pretty "normal", I think:
> 1. Get an updated version of the source code, storing it in
> "c:/emacs/trunk/" directory.
> 2. "configure"
> 3. "mingw32-make bootstrap"
> 4. "mingw32-make info".
> 5. "mingw32-make dist".
>
> FWIW: The above process was done from a Windows console whose PATH
> environment variable has "c:/emacs/build/bin" among its directories,
> where "c:/emacs/build/" holds a previous emacs build.

I've tried to build from a console whose PATH doesn't have the
"c:/emacs/build/bin" directory, and the duplication is still there.
So this fact seems to be irrelevant.

-- 
Dani Moncayo

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

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

> FWIW 2: With the official windows build
> (http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.0.90-bin-i386.zip)
> I don't see the duplicated `Info' entry.

It may be a different problem, but even with that official build, I
see something strange.

I've attached two screenshots:
* "1.png" shows the info node "(dir)Top" versus the file "info/dir".
* "2.png" shows the info node "(emacs)Top" versus the file "info/emacs-1".

In the second case, subtitles like "Indexes (each index contains a
large menu)" or "Important General Concepts" that appear in the
"info/emacs-1" file are also shown in the info buffer.

But in the first case, the subtitles ("Emacs", "GNU Emacs Lisp",
"Emacs editing modes", ...) that appear in the "info/dir" file,
doesn't appear in the corresponding info buffer.  Why?

--
Dani Moncayo

[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 159732 bytes --]

[-- Attachment #3: 2.png --]
[-- Type: image/png, Size: 150917 bytes --]

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

[Eli Zaretskii]

> Date: Sat, 29 Oct 2011 20:55:25 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 9891@debbugs.gnu.org
> 
> My build process was pretty "normal", I think:
> 1. Get an updated version of the source code, storing it in
> "c:/emacs/trunk/" directory.
> 2. "configure"
> 3. "mingw32-make bootstrap"
> 4. "mingw32-make info".
> 5. "mingw32-make dist".

??? Why do you need the last step?  Why not just "make install"?

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

[Dani Moncayo]

>> My build process was pretty "normal", I think:
>> 1. Get an updated version of the source code, storing it in
>> "c:/emacs/trunk/" directory.
>> 2. "configure"
>> 3. "mingw32-make bootstrap"
>> 4. "mingw32-make info".
>> 5. "mingw32-make dist".
>
> ??? Why do you need the last step?  Why not just "make install"?

Because I wanted to create a distributable copy, which I could carry
to other PCs.  (The "dist" target is for that, no?)

I've just tried "mingw32-make install", executed the resulting
"emacs.exe" and typed "C-h i".  This time, the duplicated `Info' has
disappeared (no idea why).

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Fri, 28 Oct 2011 19:39:06 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 9891@debbugs.gnu.org
> 
> I don't have an INFOPATH environment variable, but I've seen that,
> inside Emacs, the value of the variable `Info-directory-list' is
> ("c:/emacs/trunk/info/" "c:/emacs/build/info/").
> 
> Each of these two directories has a `dir' file.  They are exact copies
> from the emacs-trunk repository (with a single `Info' entry).
> 
> I thought this issue would have an immediate and trivial solution, but
> since (a) it's something more obscure, (b) it's specific to my setup,
> and (c) It's unimportant, I don't think it's worth to spend more time
> on this.

This is not specific to your setup.  Emacs deliberately includes in
Info-directory-list both the source and the installation directories.
This is explained in the doc string.

This is also not unimportant.  info.el goes to great lengths to
streamline the top-level Info directory, so that code better be right,
or we should simply remove it.

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

[Eli Zaretskii]

> Date: Sat, 29 Oct 2011 20:55:25 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 9891@debbugs.gnu.org
> 
> >> I don't have an INFOPATH environment variable, but I've seen that,
> >> inside Emacs, the value of the variable `Info-directory-list' is
> >> ("c:/emacs/trunk/info/" "c:/emacs/build/info/").
> >>
> >> Each of these two directories has a `dir' file.  They are exact copies
> >> from the emacs-trunk repository (with a single `Info' entry).
> >
> > Then I think the duplication in the info menu is expected. IIUC, info
> > does not make any attempt to "uniquify" menu entries (the standalone
> > info program behaves in the same way).

This is false; see Info-dir-remove-duplicates.

> Aha, but then I wonder why the only entry that gets duplicated is the
> `Info' one, instead of every menu entry.  BTW, the extra `Info' entry
> isn't located next to the first one, but at the very end of the buffer
> (just after the `SMTP' entry).

This happens because after concatenating the two identical `dir'
files, the second `Info' entry looks as if it belongs to the last
heading, "Emacs lisp libraries".  Info-dir-remove-duplicates only
removes duplicates under the same heading.

> > I think the only remaining issue that might be a bug is: did the normal
> > Emacs-on-MS-Windows build process create these duplicate directories,
> > or did you do something to end up in that state?

It is normal.

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

[Eli Zaretskii]

> Date: Sat, 29 Oct 2011 22:41:51 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 9891@debbugs.gnu.org
> 
> > FWIW 2: With the official windows build
> > (http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.0.90-bin-i386.zip)
> > I don't see the duplicated `Info' entry.
> 
> It may be a different problem, but even with that official build, I
> see something strange.
> 
> I've attached two screenshots:
> * "1.png" shows the info node "(dir)Top" versus the file "info/dir".
> * "2.png" shows the info node "(emacs)Top" versus the file "info/emacs-1".
> 
> In the second case, subtitles like "Indexes (each index contains a
> large menu)" or "Important General Concepts" that appear in the
> "info/emacs-1" file are also shown in the info buffer.
> 
> But in the first case, the subtitles ("Emacs", "GNU Emacs Lisp",
> "Emacs editing modes", ...) that appear in the "info/dir" file,
> doesn't appear in the corresponding info buffer.  Why?

This is not a different problem, it's a consequence of the same
function Info-dir-remove-duplicates.  It happens here:

	  ;; Look for other headings of the same category and merge them.
	  (save-excursion
	    (while (re-search-forward "^\\(\\w.*\\)\n\\*" limit t)
	      (when (if re (save-match-data (string-match re (match-string 1)))
		      (equal name (match-string 1)))
		(forward-line 0)
		;; Delete redundant heading.                 <<<<<<<<<<<
		(delete-region (match-beginning 0) (point))  <<<<<<<<<<<

In this case, `re' is "Emacs", because Info-dir-remove-duplicates saw
the heading "Emacs".  Because `re' is non-nil, every heading that
matches "Emacs" will be removed.  And guess what? they _all_ match!

So I think it's a bug either in Info-dir-remove-duplicates or in the
regexps in Info-streamline-headings: they should match the entire
line, not just any substring.

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

[Juri Linkov]

> 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.  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.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Dani Moncayo <dmoncayo@gmail.com>,  9891@debbugs.gnu.org
> 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.

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

[Juri Linkov]

>> I think duplicate entries is not a problem.
>
> If they aren't, then why do we have Info-dir-remove-duplicates?

I meant that duplicate entries is not a problem when they lead to
different manuals.  IOW, when their absolute filenames are not duplicated.

> 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.

True, but this is what I see on GNU/Linux in "(dir) Top", at the top:

* Info: (info).                 How to use the documentation browsing system.

and in the "Texinfo documentation system" section:

* Info: (info).                 How to use the documentation browsing system.

The former is from the Emacs source tree, and the latter duplicate
is from /usr/share/info/.

> 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.

I think it's more wrong when clicking on the link in the
"Texinfo documentation system" section visits the Info file
from the Emacs source tree instead of the Texinfo installation
in /usr/share/info/.

> 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.

There is no problem with `Info-directory-list' where the
Emacs source location takes precedence over /usr/share/info/.
This is correct.

> 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.

The problem with removing duplicates is its heuristics that is too
unpredictable and ad-hoc.  Sometimes it leaves duplicates not removed,
and sometimes removes non-duplicates, e.g. I see that it removed the
second entry from these lines in `dir':

* _exit: (libc)Termination Internals.
* _Exit: (libc)Termination Internals.

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

[Stefan Monnier]

> True, but this is what I see on GNU/Linux in "(dir) Top", at the top:

> * Info: (info).                 How to use the documentation browsing system.

> and in the "Texinfo documentation system" section:

> * Info: (info).                 How to use the documentation browsing system.

Info doesn't look at the context: it only sees those two lines, which
are identical and hence it would be a bug to behave differently on those
two lines.

> The former is from the Emacs source tree, and the latter duplicate
> is from /usr/share/info/.

Only *you* know that: Emacs has no clue whatsoever where those lines
come from.

> I think it's more wrong when clicking on the link in the
> "Texinfo documentation system" section visits the Info file
> from the Emacs source tree instead of the Texinfo installation
> in /usr/share/info/.

That happens to work for you because by chance the "Texinfo
documentation system" section only exists in one of the dir files, so
the entries in that section are "unambiguously" bound to that dir file
and hence to the directory where it was found.  But that's not the way
`dir' files and section headers usually behave, so there's no code in
info.el to try and special case such situations.


        Stefan

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

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: dmoncayo@gmail.com,  9891@debbugs.gnu.org
> Date: Wed, 02 Nov 2011 00:31:14 +0200
> 
> True, but this is what I see on GNU/Linux in "(dir) Top", at the top:
> 
> * Info: (info).                 How to use the documentation browsing system.
> 
> and in the "Texinfo documentation system" section:
> 
> * Info: (info).                 How to use the documentation browsing system.
> 
> The former is from the Emacs source tree, and the latter duplicate
> is from /usr/share/info/.

Emacs cannot fix that.  You need to fix this by re-arranging and/or
editing your DIR files.

> I think it's more wrong when clicking on the link in the
> "Texinfo documentation system" section visits the Info file
> from the Emacs source tree instead of the Texinfo installation
> in /usr/share/info/.

Then make the entries unambiguous.

> The problem with removing duplicates is its heuristics that is too
> unpredictable and ad-hoc.  Sometimes it leaves duplicates not removed,
> and sometimes removes non-duplicates, e.g. I see that it removed the
> second entry from these lines in `dir':
> 
> * _exit: (libc)Termination Internals.
> * _Exit: (libc)Termination Internals.

Case sensitivity?  Anyway, if the code in Info-dir-remove-duplicates
is imperfect, we should improve it.

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

[Juri Linkov]

> That happens to work for you because by chance the "Texinfo
> documentation system" section only exists in one of the dir files, so
> the entries in that section are "unambiguously" bound to that dir file
> and hence to the directory where it was found.  But that's not the way
> `dir' files and section headers usually behave, so there's no code in
> info.el to try and special case such situations.

Now I understand that `dir' files are not necessarily located in the
same directory as Info files they are referring to.  Then absolute
filenames of Info files can't be deduced from the absolute filename
of the `dir' file.

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

[Juri Linkov]

>> True, but this is what I see on GNU/Linux in "(dir) Top", at the top:
>>
>> * Info: (info).                 How to use the documentation browsing system.
>>
>> and in the "Texinfo documentation system" section:
>>
>> * Info: (info).                 How to use the documentation browsing system.
>>
>> The former is from the Emacs source tree, and the latter duplicate
>> is from /usr/share/info/.
>
> Emacs cannot fix that.  You need to fix this by re-arranging and/or
> editing your DIR files.

I don't want to edit installed DIR files, and on systems where you have
no root privileges you can't edit them anyway.

>> The problem with removing duplicates is its heuristics that is too
>> unpredictable and ad-hoc.  Sometimes it leaves duplicates not removed,
>> and sometimes removes non-duplicates, e.g. I see that it removed the
>> second entry from these lines in `dir':
>>
>> * _exit: (libc)Termination Internals.
>> * _Exit: (libc)Termination Internals.
>
> Case sensitivity?  Anyway, if the code in Info-dir-remove-duplicates
> is imperfect, we should improve it.

Yes, it seems this case insensitivity is intentional
in `Info-dir-remove-duplicates'.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: dmoncayo@gmail.com,  9891@debbugs.gnu.org
> Date: Wed, 02 Nov 2011 12:07:54 +0200
> 
> > Emacs cannot fix that.  You need to fix this by re-arranging and/or
> > editing your DIR files.
> 
> I don't want to edit installed DIR files, and on systems where you have
> no root privileges you can't edit them anyway.

In that case, you will have to ask your friendly sysadmin to do that.

> >> * _exit: (libc)Termination Internals.
> >> * _Exit: (libc)Termination Internals.
> >
> > Case sensitivity?  Anyway, if the code in Info-dir-remove-duplicates
> > is imperfect, we should improve it.
> 
> Yes, it seems this case insensitivity is intentional
> in `Info-dir-remove-duplicates'.

I don't see why this is TRT.  In this case, the case insensitivity is
clearly doing The Wrong Thing.  Stefan?

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

[Stefan Monnier]

>> >> * _exit: (libc)Termination Internals.
>> >> * _Exit: (libc)Termination Internals.
>> > Case sensitivity?  Anyway, if the code in Info-dir-remove-duplicates
>> > is imperfect, we should improve it.
>> Yes, it seems this case insensitivity is intentional
>> in `Info-dir-remove-duplicates'.
> I don't see why this is TRT.  In this case, the case insensitivity is
> clearly doing The Wrong Thing.  Stefan?

I'm not sure what is being discussed.  Is it that the two above lines
are kept, or that one of the two is removed as a duplicate?

And why is the other behavior better?


        Stefan "To my layman's eyes, the two lines are equivalent, just
                like "* GDB: (gdb)" and "* Gdb: (gdb)" and should be
                collapsed into one"

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Juri Linkov <juri@jurta.org>, 9891@debbugs.gnu.org
> Date: Wed, 02 Nov 2011 08:41:58 -0400
> 
> I'm not sure what is being discussed.  Is it that the two above lines
> are kept, or that one of the two is removed as a duplicate?

That it is removed.

> And why is the other behavior better?

Because these are 2 different glibc functions.

>         Stefan "To my layman's eyes, the two lines are equivalent, just
>                 like "* GDB: (gdb)" and "* Gdb: (gdb)" and should be
>                 collapsed into one"

Evidently, this is not always true.  Leaving redundant information is
a lesser evil than removing non-redundant one, IMO.

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

[Stefan Monnier]

>> I'm not sure what is being discussed.  Is it that the two above lines
>> are kept, or that one of the two is removed as a duplicate?
> That it is removed.
>> And why is the other behavior better?
> Because these are 2 different glibc functions.
>> Stefan "To my layman's eyes, the two lines are equivalent, just
>> like "* GDB: (gdb)" and "* Gdb: (gdb)" and should be
>> collapsed into one"
> Evidently, this is not always true.  Leaving redundant information is
> a lesser evil than removing non-redundant one, IMO.

I think I'm beginning to understand: the problem is that the "top-level
dir" is used in two very different contexts:
- for interactive use, where it should be shortish and avoid redundancy.
- for non-interactive use, typically to make `info' emulate `man', where
  the toplevel `dir' is abused as an index.  This only works for
  specially built `dir' files and I don't see it used in Debian,
  for instance.
The Info-dir-remove-duplicates is clearly meant for the first use and
I think that's the most important use, so if we want to make it handle
the second case we'll have to make sure it doesn't hurt the first.


        Stefan

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

[Drew Adams]

> - for non-interactive use, typically to make `info' emulate 
>   `man', where the toplevel `dir' is abused as an index.

I have not been following this thread - at all, so ignore if this is
inappropriate.

We already have the ability to create a virtual index/menu/book.  Would that be
useful here, instead of trying to shovel things into `dir'?

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

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The Info-dir-remove-duplicates is clearly meant for the first use and
> I think that's the most important use, so if we want to make it handle
> the second case we'll have to make sure it doesn't hurt the first.

Info-dir-remove-duplicates should only remove duplicates coming from
different (later) dir files.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: juri@jurta.org, 9891@debbugs.gnu.org
> Date: Wed, 02 Nov 2011 10:05:39 -0400
> 
> I think I'm beginning to understand: the problem is that the "top-level
> dir" is used in two very different contexts:
> - for interactive use, where it should be shortish and avoid redundancy.
> - for non-interactive use, typically to make `info' emulate `man', where
>   the toplevel `dir' is abused as an index.  This only works for
>   specially built `dir' files and I don't see it used in Debian,
>   for instance.
> The Info-dir-remove-duplicates is clearly meant for the first use and
> I think that's the most important use, so if we want to make it handle
> the second case we'll have to make sure it doesn't hurt the first.

What would constitute "hurting the first use case"?

I intend to make a change whereby the header lines we maintain on
Emacs's info/dir file are not deleted (by removing ("Emacs . "Emacs)
from Info-streamline-headers) -- would that "hurt", and if so, why?

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

[Stefan Monnier]

>> I think I'm beginning to understand: the problem is that the "top-level
>> dir" is used in two very different contexts:
>> - for interactive use, where it should be shortish and avoid redundancy.
>> - for non-interactive use, typically to make `info' emulate `man', where
>> the toplevel `dir' is abused as an index.  This only works for
>> specially built `dir' files and I don't see it used in Debian,
>> for instance.
>> The Info-dir-remove-duplicates is clearly meant for the first use and
>> I think that's the most important use, so if we want to make it handle
>> the second case we'll have to make sure it doesn't hurt the first.
> What would constitute "hurting the first use case"?

An example of hurting the first use case would be to keep "* GDB: (gdb)"
along with "* Gdb: (gdb)".

> I intend to make a change whereby the header lines we maintain on
> Emacs's info/dir file are not deleted (by removing ("Emacs . "Emacs)
> from Info-streamline-headers) -- would that "hurt", and if so, why?

I added that code because I bumped into different dir entries which used
slightly different header lines for fundamentally the same purpose.
E.g. my current /usr/share/info/dir contains:

   Emacs
   * Ada mode: (emacs-21/ada-mode).
                                   The GNU Emacs mode for editing Ada.
   [...]
   Emacs editing modes
   * Ada mode: (emacs-23/ada-mode).
                                   Emacs mode for editing and compiling Ada code.
   [...]
   Emacs network features
   [...]
   * TRAMP: (emacs-23/tramp).      Transparent Remote Access, Multiple Protocol 
                                     Emacs remote file access via rsh and rcp.
   [...]
   GNU Emacs
   * TRAMP: (emacs-22/tramp).      Transparent Remote Access, Multiple Protocol 
                                     GNU Emacs remote file access via rsh and rcp.

And of course, between these headings appear some others that aren't
related to Emacs.  It's a pretty messy part of the Texinfo
infrastructure and would deserve to be improved.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: juri@jurta.org, 9891@debbugs.gnu.org
> Date: Wed, 02 Nov 2011 15:52:54 -0400
> 
> I added that code because I bumped into different dir entries which used
> slightly different header lines for fundamentally the same purpose.
> E.g. my current /usr/share/info/dir contains:
> 
>    Emacs
>    * Ada mode: (emacs-21/ada-mode).
>                                    The GNU Emacs mode for editing Ada.
>    [...]
>    Emacs editing modes
>    * Ada mode: (emacs-23/ada-mode).
>                                    Emacs mode for editing and compiling Ada code.
>    [...]
>    Emacs network features
>    [...]
>    * TRAMP: (emacs-23/tramp).      Transparent Remote Access, Multiple Protocol 
>                                      Emacs remote file access via rsh and rcp.
>    [...]
>    GNU Emacs
>    * TRAMP: (emacs-22/tramp).      Transparent Remote Access, Multiple Protocol 
>                                      GNU Emacs remote file access via rsh and rcp.

But these all are different entries, they will not (and should not) be
unified into a single entry.  I agree it's unfortunate that, e.g.,
emacs-21/ada-mode and emacs-23/ada-mode will not appear under the same
heading, but it's not too bad to have them under different headings.
They are there and they can be easily found.

By contrast, the current code forcibly _removes_ all the headings we
put on our info/dir, which is shooting ourselves in the foot: we make
_our_ DIR menu worse because _someone_else_ can't get their act
together in _their_ `dir' files.  This sounds backwards to me: if
users don't like the results, let them complain to those who are
responsible for that result, rather than to us.

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

[Lars Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

> I thought this issue would have an immediate and trivial solution, but
> since (a) it's something more obscure, (b) it's specific to my setup,
> and (c) It's unimportant, I don't think it's worth to spend more time
> on this.
>
> So, feel free to close this report.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, there didn't seem to be anything practical to
do here, so I'm closing this bug report.  If I misunderstood, please
respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no