* bug#9891: 24.0.90; Duplicated entry at the info directory @ 2011-10-27 19:15 Dani Moncayo 2011-10-28 16:38 ` Glenn Morris 0 siblings, 1 reply; 29+ messages in thread From: Dani Moncayo @ 2011-10-27 19:15 UTC (permalink / raw) To: 9891 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-27 19:15 bug#9891: 24.0.90; Duplicated entry at the info directory Dani Moncayo @ 2011-10-28 16:38 ` Glenn Morris 2011-10-28 17:39 ` Dani Moncayo 0 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2011-10-28 16:38 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-28 16:38 ` Glenn Morris @ 2011-10-28 17:39 ` Dani Moncayo 2011-10-29 18:23 ` Glenn Morris ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Dani Moncayo @ 2011-10-28 17:39 UTC (permalink / raw) To: Glenn Morris; +Cc: 9891 >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-28 17:39 ` Dani Moncayo @ 2011-10-29 18:23 ` Glenn Morris 2011-10-29 18:55 ` Dani Moncayo 2011-10-31 18:49 ` Eli Zaretskii 2022-04-26 13:17 ` Lars Ingebrigtsen 2 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2011-10-29 18:23 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 18:23 ` Glenn Morris @ 2011-10-29 18:55 ` Dani Moncayo 2011-10-29 19:16 ` Dani Moncayo ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: Dani Moncayo @ 2011-10-29 18:55 UTC (permalink / raw) To: Glenn Morris; +Cc: 9891 >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 18:55 ` Dani Moncayo @ 2011-10-29 19:16 ` Dani Moncayo 2011-10-29 20:41 ` Dani Moncayo ` (2 subsequent siblings) 3 siblings, 0 replies; 29+ messages in thread From: Dani Moncayo @ 2011-10-29 19:16 UTC (permalink / raw) To: Glenn Morris; +Cc: 9891 > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 18:55 ` Dani Moncayo 2011-10-29 19:16 ` Dani Moncayo @ 2011-10-29 20:41 ` Dani Moncayo 2011-10-31 18:57 ` Eli Zaretskii 2011-10-29 20:59 ` Eli Zaretskii 2011-10-31 18:53 ` Eli Zaretskii 3 siblings, 1 reply; 29+ messages in thread From: Dani Moncayo @ 2011-10-29 20:41 UTC (permalink / raw) To: Glenn Morris; +Cc: 9891 [-- 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 --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 20:41 ` Dani Moncayo @ 2011-10-31 18:57 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2011-10-31 18:57 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 18:55 ` Dani Moncayo 2011-10-29 19:16 ` Dani Moncayo 2011-10-29 20:41 ` Dani Moncayo @ 2011-10-29 20:59 ` Eli Zaretskii 2011-10-29 21:19 ` Dani Moncayo 2011-10-31 18:53 ` Eli Zaretskii 3 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-10-29 20:59 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 > 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"? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 20:59 ` Eli Zaretskii @ 2011-10-29 21:19 ` Dani Moncayo 0 siblings, 0 replies; 29+ messages in thread From: Dani Moncayo @ 2011-10-29 21:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-29 18:55 ` Dani Moncayo ` (2 preceding siblings ...) 2011-10-29 20:59 ` Eli Zaretskii @ 2011-10-31 18:53 ` Eli Zaretskii 3 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2011-10-31 18:53 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-28 17:39 ` Dani Moncayo 2011-10-29 18:23 ` Glenn Morris @ 2011-10-31 18:49 ` Eli Zaretskii 2011-11-01 9:29 ` Juri Linkov 2022-04-26 13:17 ` Lars Ingebrigtsen 2 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-10-31 18:49 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-31 18:49 ` Eli Zaretskii @ 2011-11-01 9:29 ` Juri Linkov 2011-11-01 11:32 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Juri Linkov @ 2011-11-01 9:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-01 9:29 ` Juri Linkov @ 2011-11-01 11:32 ` Eli Zaretskii 2011-11-01 22:31 ` Juri Linkov 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-11-01 11:32 UTC (permalink / raw) To: Juri Linkov; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-01 11:32 ` Eli Zaretskii @ 2011-11-01 22:31 ` Juri Linkov 2011-11-02 1:39 ` Stefan Monnier 2011-11-02 3:55 ` Eli Zaretskii 0 siblings, 2 replies; 29+ messages in thread From: Juri Linkov @ 2011-11-01 22:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-01 22:31 ` Juri Linkov @ 2011-11-02 1:39 ` Stefan Monnier 2011-11-02 10:01 ` Juri Linkov 2011-11-02 3:55 ` Eli Zaretskii 1 sibling, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-11-02 1:39 UTC (permalink / raw) To: Juri Linkov; +Cc: 9891 > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 1:39 ` Stefan Monnier @ 2011-11-02 10:01 ` Juri Linkov 0 siblings, 0 replies; 29+ messages in thread From: Juri Linkov @ 2011-11-02 10:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-01 22:31 ` Juri Linkov 2011-11-02 1:39 ` Stefan Monnier @ 2011-11-02 3:55 ` Eli Zaretskii 2011-11-02 10:07 ` Juri Linkov 1 sibling, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-11-02 3:55 UTC (permalink / raw) To: Juri Linkov; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 3:55 ` Eli Zaretskii @ 2011-11-02 10:07 ` Juri Linkov 2011-11-02 10:57 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Juri Linkov @ 2011-11-02 10:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> 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'. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 10:07 ` Juri Linkov @ 2011-11-02 10:57 ` Eli Zaretskii 2011-11-02 12:41 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-11-02 10:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 9891 > 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 10:57 ` Eli Zaretskii @ 2011-11-02 12:41 ` Stefan Monnier 2011-11-02 13:03 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-11-02 12:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> >> * _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" ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 12:41 ` Stefan Monnier @ 2011-11-02 13:03 ` Eli Zaretskii 2011-11-02 14:05 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-11-02 13:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 13:03 ` Eli Zaretskii @ 2011-11-02 14:05 ` Stefan Monnier 2011-11-02 14:33 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Stefan Monnier @ 2011-11-02 14:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 14:05 ` Stefan Monnier @ 2011-11-02 14:33 ` Drew Adams 2011-11-02 17:28 ` Andreas Schwab 2011-11-02 17:54 ` Eli Zaretskii 2 siblings, 0 replies; 29+ messages in thread From: Drew Adams @ 2011-11-02 14:33 UTC (permalink / raw) To: 'Stefan Monnier', 'Eli Zaretskii'; +Cc: 9891 > - 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'? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 14:05 ` Stefan Monnier 2011-11-02 14:33 ` Drew Adams @ 2011-11-02 17:28 ` Andreas Schwab 2011-11-02 17:54 ` Eli Zaretskii 2 siblings, 0 replies; 29+ messages in thread From: Andreas Schwab @ 2011-11-02 17:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9891 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." ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 14:05 ` Stefan Monnier 2011-11-02 14:33 ` Drew Adams 2011-11-02 17:28 ` Andreas Schwab @ 2011-11-02 17:54 ` Eli Zaretskii 2011-11-02 19:52 ` Stefan Monnier 2 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2011-11-02 17:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9891 > 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 17:54 ` Eli Zaretskii @ 2011-11-02 19:52 ` Stefan Monnier 2011-11-05 13:54 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-11-02 19:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9891 >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-11-02 19:52 ` Stefan Monnier @ 2011-11-05 13:54 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2011-11-05 13:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 9891 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9891: 24.0.90; Duplicated entry at the info directory 2011-10-28 17:39 ` Dani Moncayo 2011-10-29 18:23 ` Glenn Morris 2011-10-31 18:49 ` Eli Zaretskii @ 2022-04-26 13:17 ` Lars Ingebrigtsen 2 siblings, 0 replies; 29+ messages in thread From: Lars Ingebrigtsen @ 2022-04-26 13:17 UTC (permalink / raw) To: Dani Moncayo; +Cc: Glenn Morris, 9891 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2022-04-26 13:17 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-27 19:15 bug#9891: 24.0.90; Duplicated entry at the info directory Dani Moncayo 2011-10-28 16:38 ` Glenn Morris 2011-10-28 17:39 ` Dani Moncayo 2011-10-29 18:23 ` Glenn Morris 2011-10-29 18:55 ` Dani Moncayo 2011-10-29 19:16 ` Dani Moncayo 2011-10-29 20:41 ` Dani Moncayo 2011-10-31 18:57 ` Eli Zaretskii 2011-10-29 20:59 ` Eli Zaretskii 2011-10-29 21:19 ` Dani Moncayo 2011-10-31 18:53 ` Eli Zaretskii 2011-10-31 18:49 ` Eli Zaretskii 2011-11-01 9:29 ` Juri Linkov 2011-11-01 11:32 ` Eli Zaretskii 2011-11-01 22:31 ` Juri Linkov 2011-11-02 1:39 ` Stefan Monnier 2011-11-02 10:01 ` Juri Linkov 2011-11-02 3:55 ` Eli Zaretskii 2011-11-02 10:07 ` Juri Linkov 2011-11-02 10:57 ` Eli Zaretskii 2011-11-02 12:41 ` Stefan Monnier 2011-11-02 13:03 ` Eli Zaretskii 2011-11-02 14:05 ` Stefan Monnier 2011-11-02 14:33 ` Drew Adams 2011-11-02 17:28 ` Andreas Schwab 2011-11-02 17:54 ` Eli Zaretskii 2011-11-02 19:52 ` Stefan Monnier 2011-11-05 13:54 ` Eli Zaretskii 2022-04-26 13:17 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).
![[-- Attachment #2: 1.png --] [-- Type: image/png, Size: 159732 bytes --]](../../CAH8Pv0h6mSZKBao11m9rm4v4m2at6cu-iJjeZCCmvZHDZcFLZw@mail.gmail.com/2-1.png){kind=link}
![[-- Attachment #3: 2.png --] [-- Type: image/png, Size: 150917 bytes --]](../../CAH8Pv0h6mSZKBao11m9rm4v4m2at6cu-iJjeZCCmvZHDZcFLZw@mail.gmail.com/3-2.png){kind=link}