Emacs cvs newbie problems

Emacs cvs newbie problems

[Steven T. Hatton]

I've been using XEmacs for several years now, but I'm finding there are a few 
features in (GNU) Emacs which I'm not finding in XEmacs.  I therefore wanted 
to take a look at the latest cvs snapshot.  I did what I consider a normal 
cvs checkout:

cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/emacs co emacs

Whic was my best guess on the basis of the http://savana.gnu.org site.  I 
attempted to ./configure && make. This resulted in a message saying:
Essential Lisp files seem to be missing.  You should either
do `make bootstrap' or create `lisp/abbrev.elc' somehow.

'make bootstrap' puked on info/tramp: 

cd /download/org/gnu/emacs/emacs/man; makeinfo tramp.texi
tramp.texi:25: Unknown command `copying'.
tramp.texi:50: Unmatched `@end'.
makeinfo: Removing output file `../info/tramp' due to errors; use --force to 
preserve.
make[1]: *** [../info/tramp] Error 2
make[1]: Leaving directory `/download/org/gnu/emacs/emacs/man'
make: *** [info] Error 2

I then downloaded the latest stable tarball and that ./configured and made 
like a charm.  I'm sure I could snag the `lisp/abbrev.elc' from that build, 
but seems a whole lot like cheating.  Is the current cvs image makeable?

STH

Re: Emacs cvs newbie problems

[Damien Elmes]

"Steven T. Hatton" <hattons@speakeasy.net> writes:

> 'make bootstrap' puked on info/tramp: 
>
> cd /download/org/gnu/emacs/emacs/man; makeinfo tramp.texi
> tramp.texi:25: Unknown command `copying'.
> tramp.texi:50: Unmatched `@end'.
> makeinfo: Removing output file `../info/tramp' due to errors; use --force to 
> preserve.
> make[1]: *** [../info/tramp] Error 2
> make[1]: Leaving directory `/download/org/gnu/emacs/emacs/man'
> make: *** [info] Error 2
>
> I then downloaded the latest stable tarball and that ./configured and made 
> like a charm.  I'm sure I could snag the `lisp/abbrev.elc' from that build, 
> but seems a whole lot like cheating.  Is the current cvs image makeable?

You need texinfo 4.2.

Regards,

-- 
Damien Elmes

Re: Emacs cvs newbie problems

[Steven T. Hatton]

On Saturday 14 September 2002 02:40, Damien Elmes wrote:
> "Steven T. Hatton" <hattons@speakeasy.net> writes:
> > 'make bootstrap' puked on info/tramp:
>
> You need texinfo 4.2.

Yup! Thank's for the RE.  I actually figured that out after poking around in
the <info>.texi's.

I do have a follow-on:  Now that I have Emacs built, I am having problems
which seem to result from not having the correct packages installed.  I'm not
finding the documentation to be very helpful in determining what the
'standard' packages are, and how to install them.  Is there a cheat sheet for
this?  As it stands, I feel like I'm on an easter-egg hunt.

Yes, I know I'm spoiled! But that XEmacs feature *is* very nice.

-- STH

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Steven T. Hatton wrote:

   I'm not finding the documentation to be very helpful in determining
   what the 'standard' packages are, and how to install them.  Is
   there a cheat sheet for this?

Are you talking about C-h p or am I misunderstanding you?

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Steven T. Hatton]

On Saturday 14 September 2002 17:12, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    I'm not finding the documentation to be very helpful in determining
>    what the 'standard' packages are, and how to install them.  Is
>    there a cheat sheet for this?
>
> Are you talking about C-h p or am I misunderstanding you?

I think you misunderstood the question, but that *is* part of the answer. :-)

I was actually asking if there is a list of what packages 'should' be 
installed in order for Emacs to act 'normal'.  I also was looking for 
something which will tell me how to install packages in the 'correct' way.  
For example, I don't believe psgml is installed in my cvs-built setup.  I 
would like to install that, 'correctly'.

From browsing that (C-h p) list it looks as though a lack of packages is *not* 
my primary problem.  Here's an example of what's going on:  When I open an 
elisp file and select Options->Syntax Highlighting, I get an error message in 
the echo area saying:
"Wrong type argument: commandp, (quote global-font-lock-mode)"

The SuSE built emacs works find in the same user environment.

Where'd I go wrong? This is similar to the problems I have with XEmacs when I 
don't have the packages available to the executable.

> Sincerely,
>
> Luc.

-- STH

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Steven T. Hatton wrote:

   I was actually asking if there is a list of what packages 'should' be 
   installed in order for Emacs to act 'normal'.

To look "normal" to me, none.  To look "normal" to you, I have no
idea.

   I also was looking for 
   something which will tell me how to install packages in the
   'correct' way.

To install package foo, put

(require 'foo)

in your .emacs.  Some packages may require additional steps.  This is
usually mentioned in the documentation for the package.

I believe you can get help for such questions at gnu.emacs.help.
This is a site for Emacs development.

   Here's an example of what's going on: When I open an elisp file and
   select Options->Syntax Highlighting, I get an error message in the
   echo area saying: "Wrong type argument: commandp, (quote
   global-font-lock-mode)"
   
This seems to be a different matter.  I do not use the menu-bar
myself, so I have no experience with this.  I reproduced the described
behavior using emacs-21.3.50 -q.  Something similar happens for the
two options right below it.  The menu-bar is meant for beginning
users.  Hence I believe you should not have to worry about which
packages should be loaded.  I believe that should be done
automatically for you.  I personally have the impression that this is
a bug.  (It seems to me that somehow these commands got quoted in a
situation where they should not have been.)

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Steven T. Hattonn wrote:

   When I open an elisp file and select Options->Syntax Highlighting,
   I get an error message in the echo area saying: "Wrong type
   argument: commandp, (quote global-font-lock-mode)"

   The SuSE built emacs works find in the same user environment.

In my previous reply, I believe I forgot to read this last sentence.
This behavior is definitely a recently introduced bug.  The bug does
not occur in emacs-21.2.90 -q.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Steven T. Hatton]

Luc Teirlinck wrote:

>Steven T. Hatton wrote:
>
>   I was actually asking if there is a list of what packages 'should' be 
>   installed in order for Emacs to act 'normal'.
>
>To look "normal" to me, none.  To look "normal" to you, I have no
>idea.
>
>   I also was looking for 
>   something which will tell me how to install packages in the
>   'correct' way.
>
>To install package foo, put
>
>(require 'foo)
>
>in your .emacs.  Some packages may require additional steps.  This is
>usually mentioned in the documentation for the package.
>  
>
To me this is something of a borderline issue. If I do what a normal 
user would do and grab an rpm from SuSE Linux and let rpm do its magic, 
everything works fine.  If I come into the cvs wanting to take a look at 
the latest build, this *appears* differently than it would to a typical 
user.  I'll grant you, I am not an Emacs power user.  XEmacs has really 
spoiled me in a lot of ways.  The package system really *is* magic.

I guess that question relates to system administration rather than 
development in the sense that I'm trying to perform sysadmin 
proceedures. I actually wanted to know how to add a package system-wide. 
 But that was not my question.  My question is:

how do I find the information in a finite period?  

I'm not going to win any popularity contests by saying this on an Emacs 
developers' list, but I can't think of a more appropreate place to say 
it.  The Emacs community does not communicate well with the uninitiated. 
 I've said this on the XEmacs beta list as well.  I understand there are 
many reasons things are this way.  Easy to access documentation is a 
pain to create, and I know there is some really wonderful documentation 
for certain aspects of Emacs; perhas for most aspects of Emacs.  But 
*finding* things seems unnecessarily difficult.  This is a general 
statement which I believe *is* relevent to Emacs developers.  I 
therefore am _not_ looking for answers to specific questions which I am 
using as examples.  That being said, here is an example:

If I crack open the info reader and view the top level directory, I see 
an extensive list of topics.  If I know what I'm looking for, and how to 
spell it, I can C-s for it.  If I'm not so sure of what I'm looking for, 
finding something in that list can be rather difficult.  The order in 
which the information is presented is not obvious, even to a person who 
is a long time (X)Emacs user.  Having a way of sorting the list, for 
example, alpabetically, might be helpful.

Things have gotten much better with the introduction of easy to use 
documentation search tools.  And I appreciate the effort of the 
person/people who created that functionallity.

I'm not really addressing a developer issue at the 'bug' level, or the 
'new feature' level.  This is a 'gestalt', 'weltanshauung' or 'paradigm' 
issue.  I believe (X)Emacs has lost a lot of potentially productive 
user/developers because the initial learning curve makes it 
prohibatively expensive to learn.  It's notnecessarrily that people are 
lazy.  We simply have short-term productivity demands on us which 
prevent us from being able to invest the time necessary to master Emacs 
in the way the current structure requires.

I'm not saying I have the solutions to this 'perceived' problem.  If I 
did, I would tell you what they are.  I think what I'm saying, is: there 
seems to be a 'work-flow' issue with the way Emacs and the supporting 
materials are structured.  I don't know exactly how to analyze this, but 
I'm suggesting the path a user needs to take to achieve 'typical' goals 
is often not clear.  It would be an interesting study to take a dozen or 
so college freshmen, wire them up with monitors of biological stress 
indicators, and synchronize the data with a trace of their online 
behavior as they attempt to learn to use Emacs to edit XML with xmlns 
tags for a project which is due at the end of the week.

>I believe you can get help for such questions at gnu.emacs.help.
>This is a site for Emacs development.
>
>   Here's an example of what's going on: When I open an elisp file and
>   select Options->Syntax Highlighting, I get an error message in the
>   echo area saying: "Wrong type argument: commandp, (quote
>   global-font-lock-mode)"
>   
>This seems to be a different matter.  I do not use the menu-bar
>myself, so I have no experience with this.  I reproduced the described
>behavior using emacs-21.3.50 -q.  Something similar happens for the
>two options right below it.  The menu-bar is meant for beginning
>users.  Hence I believe you should not have to worry about which
>packages should be loaded. 
>
My only reason for thinking it might be a package issue is because of 
similar types of behavior with XEmacs.  I guess what I was looking for 
was a 'check list' .  It now appears to me, such was not necessary.  It 
would still be nice to have some type of a 'now that you've built Emacs, 
here's how to configure additional packages and features', pointer.

>> I believe that should be done
>automatically for you.  I personally have the impression that this is
>a bug.  (It seems to me that somehow these commands got quoted in a
>situation where they should not have been.)
>
Well, I guess part of this is a result of the fact that I'm both a (GNU) 
Emacs newbie and a newbie to the Emacs cvs. I'm fairly proficient with 
XEmacs from the perspective of using it as an editor.  In a pinch I can 
go and hack the LISP, I would like to be better at that.  I have built 
XEmacs from cvs literally hundreds of times.  It is part of my daily 
ritual, along with grabbing the latest Mozilla build.  With XEmacs, most 
of the packages I'm interested in are available through the use of the 
package tool.  I don't need to mess with configuring them.  With Emacs, 
I have to do the same thing by hand.  So, if I do have a *specific* 
question, it is, where to I find the 'how to install packages, gospel, 
accoring to the pros'?  Perhaps you've answered this by telling me to 
look at the documentation for each package.  There is something 
unsatisfactory with that answere.  It begs the question of how a package 
provider should design his package for installation?

>
>Sincerely,
>
>Luc.
>
Here's something to think about:
Java - powerful, easy to use. - Created by Emacs hacker James Gosling, 
et al.
Netscape Navigator - powerful, easy to use -Created by Emacs hackers 
Zawinski and Andreesen, et al.
KDE - powerful, easy to use - Created by XEmacs user Matthias Ettrich, 
et al.
Linux Kernel - powerful, (fairly) easy to configure, build and install - 
Created by Emacs user Linux Torvalds, et al.
Emacs - powerful - Created by Richard Stallman, et al.

>  
>
-- STH

Re: Emacs cvs newbie problems

[Richard Stallman]

Please try this patch--it should make the first issue easier to understand,
and explain how to solve the second.

*** Makefile.in.~1.266.~	Wed Sep 11 23:16:28 2002
--- Makefile.in	Sat Sep 14 15:12:24 2002
***************
*** 715,723 ****
  .PHONY: maybe_bootstrap
  
  maybe_bootstrap:
! 	@if [ ! -f $(srcdir)/lisp/abbrev.elc ]; then \
! 	  echo "Essential Lisp files seem to be missing.  You should either"; \
! 	  echo "do \`make bootstrap' or create \`lisp/abbrev.elc' somehow.";    \
  	  exit 1;\
  	fi
  
--- 715,725 ----
  .PHONY: maybe_bootstrap
  
  maybe_bootstrap:
!         @bar=`echo ./lisp/*.elc`; \
! 	if [ "$bar" = './lisp/*.elc' ]; then \
! 	  echo "Your tree does not include the compiled Lisp files."; \
! 	  echo "You need to do \`make bootstrap' to build Emacs."; \
! 	  echo "Emacs now requires Texinfo version 4.2."; \
  	  exit 1;\
  	fi

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Steven T. Hatton wrote:

   So, if I do have a *specific* 
   question, it is, where to I find the 'how to install packages, gospel, 
   accoring to the pros'?  Perhaps you've answered this by telling me to 
   look at the documentation for each package.

I gave you a completely general answer to a completely general
question.  I believe that, for certain specific specialized packages,
you have to do look at the documentation for those packages.  Some
packages are of such a nature that they are extremely unlikely to be
used by "newbies" anyway.  For the most often used packages,
especially those most often used by newbies, the customize facility
provides a simpler alternative to the ".emacs solution". Try Customize
Emacs under Options on the menu-bar, for instance.

I gave you specific answers to your specific questions.  I pointed out
which of the difficulties you encountered were misconceptions on your
part and which ones were bugs in emacs-21.3.50.

However, I am not going to discuss the very general philosophical
issues you raised.  I am just an "ordinary subscriber" to this list
and not an "official spokesperson" for Emacs.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Steven T. Hatton]

On Saturday 14 September 2002 22:42, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    So, if I do have a *specific*
>    question, it is, where to I find the 'how to install packages, gospel,
>    accoring to the pros'?  Perhaps you've answered this by telling me to
>    look at the documentation for each package.
>
> I gave you a completely general answer to a completely general
> question.  I believe that, for certain specific specialized packages,
> you have to do look at the documentation for those packages.  Some
> packages are of such a nature that they are extremely unlikely to be
> used by "newbies" anyway.  For the most often used packages,
> especially those most often used by newbies, the customize facility
> provides a simpler alternative to the ".emacs solution". Try Customize
> Emacs under Options on the menu-bar, for instance.
>
> I gave you specific answers to your specific questions.  I pointed out
> which of the difficulties you encountered were misconceptions on your
> part and which ones were bugs in emacs-21.3.50.
>
> However, I am not going to discuss the very general philosophical
> issues you raised.  I am just an "ordinary subscriber" to this list
> and not an "official spokesperson" for Emacs.

I was looking for the Emacs counterpart for this:
http://www.xemacs.org/Documentation/21.5/html/lispref_4.html#SEC19

> Sincerely,
>
> Luc.

Re: Emacs cvs newbie problems

[Miles Bader]

[Pardon me, I don't have your original message, so I might be confused about
 what you're asking]

On Sat, Sep 14, 2002 at 09:24:52PM -0400, Steven T. Hatton wrote:
> I'm not really addressing a developer issue at the 'bug' level, or the 
> 'new feature' level.  This is a 'gestalt', 'weltanshauung' or 'paradigm' 
> issue.

Try asking specific questions.  You're more likely to get a response.

Do you have an actual package you want to install?  Note that Emacs comes
with many packages by default that are optional in xemacs, so you might not
need to do anything.

Many packages come with Makefiles, and you can just do configure/make
etc. just like a non-lisp program.  Packages that don't, are often so simple
that the answer is `drop it into the site-lisp directory'.  But as Luc said,
the answer may be different depending on what you what to do.

Once you installed a few things, you'll probably know what to do, and won't
need to ask anymore (until you run into some wierd-ass package that really is
hard to install -- but in that case it will probably be something strange that
simply doesn't follow the rules anyway).

[the rest of this is arguably flame-bait, so continue reading at your own risk]

> Here's something to think about:
[...cut...]

I'm not sure why you posted this list; all of the items you mentioned are so
different that there's really little you can say about them as a group, and
certainly comparing emacs with them seems rather pointless.

[java is a programming language definition; KDE provides only the basic
extensibility for users (and is not easy to install by any stretch of the
imagination); netscape provides almost no user extensibility at all
(`powerful'?); Linux kernel configuration -- `easy to use for the
uninitiated'?  Hint: no.]

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Emacs cvs newbie problems

[Kai Großjohann]

"Steven T. Hatton" <hattons@speakeasy.net> (by way of Steven T. Hatton <hattons@speakeasy.net>) writes:

> I do have a follow-on:  Now that I have Emacs built, I am having
> problems which seem to result from not having the correct packages
> installed.  I'm not finding the documentation to be very helpful in
> determining what the 'standard' packages are, and how to install
> them.

Contrary to XEmacs, Emacs does not have a package system.  Similar to
the Sumo tarball, all packages are included in the Emacs tarball
already (or in the CVS repository).

For installing stuff that does not come with Emacs, such as AUC-TeX
or PSGML, you have to install it manually.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Steven Hatton wrote:

   For example, I don't believe psgml is installed in my cvs-built setup.  I 
   would like to install that, 'correctly'.

I somehow "missed" this concrete question.  Because you kept talking
about "standard" packages, my answers concentrated on the packages
listed by C-h p (or Find Emacs Packages under Help on the menu-bar),
for which no real "installation" is necessary, although you still have
to "load" them (or better "require" them, to avoid repeated loading).
For the most often used packages you do not even need to do that,
because the customize facility or the menu-bar will do that
automatically for you.  In the current CVS version, there is a bug in
the menu-bar, as I pointed out.

For other packages, there is the Find Extra Packages option under Help
on the menu-bar.  A buffer "MORE.STUFF" will appear.  You can conduct
a search for psgml in that buffer.

Result:

 * PSGML: <URL:http://www.lysator.liu.se/projects/about_psgml.html>
   DTD-aware serious SGML/XML editing.

I personally know of no better way to do this kind of stuff.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Richard Stallman]

      The order in 
    which the information is presented is not obvious, even to a person who 
    is a long time (X)Emacs user.  Having a way of sorting the list, for 
    example, alpabetically, might be helpful.

If each part of the menu were sorted alphabetically, would that help?
We could make install-info do that.

Re: Emacs cvs newbie problems

[Richard Stallman]

    With XEmacs, most 
    of the packages I'm interested in are available through the use of the 
    package tool.  I don't need to mess with configuring them.  With Emacs, 
    I have to do the same thing by hand.

Is this really true?  I would have said no, so I think it would be
useful to make sure we are talking about the same thing.  Could you
give an example of one Emacs package that you have to "configure", and
exactly what actions are needed to "configure" it?

Re: Emacs cvs newbie problems

[Richard Stallman]

       When I open an elisp file and select Options->Syntax Highlighting,
       I get an error message in the echo area saying: "Wrong type
       argument: commandp, (quote global-font-lock-mode)"

I fixed this bug.  Thanks.

Re: Emacs cvs newbie problems

[Karl Berry]

    If each part of the menu were sorted alphabetically, would that help?
    We could make install-info do that.

It already does.  If we're talking about the Info dir file.

Re: Emacs cvs newbie problems

[Miles Bader]

On Sun, Sep 15, 2002 at 08:02:14PM -0400, Karl Berry wrote:
>     If each part of the menu were sorted alphabetically, would that help?
>     We could make install-info do that.
> 
> It already does.  If we're talking about the Info dir file.

On my system (debian) it's kind of `half alphabetical' -- that is, there will
be a bunch of entries in alphabetical order, and then _another_ group in
alphabetical order, and ... (these `groups' I'm referring to are not the
topical sections, just runs of entries).  THis may be because debian's
install-info doesn't do any ordering though, I'm not sure.

BTW, does anyone know if debian's _really_ going to start using the standard
install-info?

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Emacs cvs newbie problems

[Steven T. Hatton]

On Sunday 15 September 2002 20:02, Karl Berry wrote:
>     If each part of the menu were sorted alphabetically, would that help?
>     We could make install-info do that.
>
> It already does.  If we're talking about the Info dir file.

This may indeed be what I find confusing.  It does seem the entries are sorted 
alphabetically, but in groups which have no obvious divisions.  Perhaps some 
kind of heading for each group of sorted headings would be helpful.  A brief 
glance through the `ls info' output suggests to me the groupings are by 
'document', ie:
ada-mode autotype calc ccmode cl dir dired-x ebrowse ediff efaq eintr elisp 
emacs emacs-mime eshell eudc ...

Of course the ording of these documents is not alphabetical.  Perhaps what I 
find confusing is the fact that there is revelent structure which is not 
immediately apearent in the presentation.

-- STH

Re: Emacs cvs newbie problems

[Alan Shutko]

Miles Bader <miles@gnu.org> writes:

> BTW, does anyone know if debian's _really_ going to start using the standard
> install-info?

I don't think so.  Last I read, the plan was to get rid of the debian
install-info in favor of some other type of system, allowing GNU
install-info to be installed, but not using it for anything.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
The Economy is weird -- banks fail before toasters do.

Re: Emacs cvs newbie problems

[Rob Browning]

Alan Shutko <ats@acm.org> writes:

> I don't think so.  Last I read, the plan was to get rid of the
> debian install-info in favor of some other type of system, allowing
> GNU install-info to be installed, but not using it for anything.

And there's still the problem we've never quite resolved, but made
some progress on from time to time regarding how to handle installing
info pages for multiple versions of emacs (or anything else --
autoconf, automake, etc.) at the same time.  I'm still planning to
revisit this when I can, but anyone else who is interested is welcome
to work on it.

Fixing things so that each separate tree of info pages is internally
self consistent (say the emacs-19 tree and the emacs-21 tree) probably
isn't too tall an order, but deciding what to do about cross
references from other packages (or sets of pages like elisp.info)
looks to be non-trivial.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Emacs cvs newbie problems

[Richard Stallman]

	If each part of the menu were sorted alphabetically, would that help?
	We could make install-info do that.

    It already does.  If we're talking about the Info dir file.

It is not ordered alphabetically in my Info dir file.
Is this a recent change in install-info?
Maybe the problem is because I am using Debian.

Meanwhile, there should be some exceptions to alphabetical order.  For
instance, in the Emacs section, the Emacs item should come first.
This could be a general rule--an item whose name equals the name of
the section comes first in that section.

It might be good to add some other features for controlling the order,
if you can figure out some useful ways to do this.

Re: Emacs cvs newbie problems

[Karl Berry]

    Is this a recent change in install-info?

No.  In fact I think it was in your original code.

    Maybe the problem is because I am using Debian.

Sounds likely to me, since Debian does not use Texinfo's install-info,
as far as I know, but instead has its own completely separate program
called install-info.

    This could be a general rule--an item whose name equals the name of
    the section comes first in that section.

Makes sense.

Thanks,
karl

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 16 Sep 2002 15:28:14 -0400
> 
> 	If each part of the menu were sorted alphabetically, would that help?
> 	We could make install-info do that.
> 
>     It already does.  If we're talking about the Info dir file.
> 
> It is not ordered alphabetically in my Info dir file.

If you are talking about the DIR file which comes with Emacs, then
it's done on purpose.  See below.

IIRC, install-info sorts sections and in each section it sorts the
entries of that section.

> Is this a recent change in install-info?

It's not a recent change, but the code was made more reliable in
Texinfo 4.0.

> Meanwhile, there should be some exceptions to alphabetical order.  For
> instance, in the Emacs section, the Emacs item should come first.

That's exactly the reason why the DIR file in the Emacs distribution
is not really sorted alphabetically.  It is produced by hand rather
than by install-info, and the order comes from a human.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Mon, 16 Sep 2002 00:40:50 -0500
> 
> Fixing things so that each separate tree of info pages is internally
> self consistent (say the emacs-19 tree and the emacs-21 tree) probably
> isn't too tall an order, but deciding what to do about cross
> references from other packages (or sets of pages like elisp.info)
> looks to be non-trivial.

I agree that this is an important issue that we should try to resolve.

Re: Emacs cvs newbie problems

[Luc Teirlinck]

I assume that what we are talking about is the output of C-h i (or
equivalently Help -> More Manuals -> All Other Manuals (Info) on the
menu-bar).

I have two small remarks on this.

First, why is the more convenient key binding C-h i not mentioned on
the menu-bar entry?  It was mentioned in Emacs20.7, but somehow
disappeared in Emacs21.

Secondly, what part of the following is intentional, a system specific
problem or a bug in the current CVS version?

From the C-h i output:

Texinfo documentation system
* Info: (info).         How to use the documentation browsing system.
* Texinfo: (texinfo).           The GNU documentation format.
* info standalone: (info-stnd).            Read Info documents without Emacs.
* infokey: (info-stnd)Invoking infokey.    Compile Info customizations.
* install-info: (texinfo)Invoking install-info. Update info/dir entries.
* makeinfo: (texinfo)Invoking makeinfo.         Translate Texinfo source.
* texi2dvi: (texinfo)Format with texi2dvi.      Print Texinfo documents.
* texindex: (texinfo)Format with tex/texindex.  Sort Texinfo index files.

Texinfo documentation system
* Info: (info).         How to use the documentation browsing system.
* Texinfo: (texinfo).           The GNU documentation format.
* info standalone: (info-stnd).            Read Info documents without Emacs.
* infokey: (info-stnd)Invoking infokey.    Compile Info customizations.
* install-info: (texinfo)Invoking install-info. Update info/dir entries.
* makeinfo: (texinfo)Invoking makeinfo.         Translate Texinfo source.
* texi2dvi: (texinfo)Format with texi2dvi.      Print Texinfo documents.
* texindex: (texinfo)Format with tex/texindex.  Sort Texinfo index files.

Texinfo documentation system
* Standalone info program: (info-stnd).    Standalone Info-reading program.
* Texinfo: (texinfo).           The GNU documentation format.
* install-info: (texinfo)Invoking install-info. Update info/dir entries.
* makeinfo: (texinfo)Invoking makeinfo.         Translate Texinfo source.
* texi2dvi: (texinfo)Format with texi2dvi.      Print Texinfo documents.
* texindex: (texinfo)Format with tex/texindex.  Sort Texinfo index files.


It would seem to me that the first identical repetition is a bug.  It
does not occur in Emacs21.2.90 on the same system.

The third slightly different version might be intentional and be meant
more for the standalone version.  It does appear in earlier Emacs
versions too.  It is confusing however.  If it is intentional a
non-identical title might help.  "Standalone info program" in the
third copy seems to lead to exactly the same buffer as "info
standalone" in the two previous copies.  Is that third copy not quite
simply a bug too?

Emacs version and system information:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (emacs-version)
"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2002-09-19 on swt40.swt.com"
ELISP> system-configuration
"i686-pc-linux-gnu"
ELISP> 

I am running Red Hat 7.2.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> why is the more convenient key binding C-h i not mentioned on
> the menu-bar entry?  It was mentioned in Emacs20.7, but somehow
> disappeared in Emacs21.

The two are subtly different -- `C-h i' pops up the *info* buffer 
at whichever page you left it last, whereas the menu entry always goes
to the top-level directory.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Emacs cvs newbie problems

[Richard Stallman]

The repetition of three identical sections in the Info directory
is some kind of bug.  Can you track down what causes it?

    First, why is the more convenient key binding C-h i not mentioned on
    the menu-bar entry?

Because C-h i is a different command.  This menu item runs
Info-directory.

I am sure that was done deliberately.  However, it could be that
running info would be better than running Info-directory.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 20 Sep 2002 14:42:13 -0400
> 
> The repetition of three identical sections in the Info directory
> is some kind of bug.  Can you track down what causes it?

I'm quite sure that Luc has several DIR files on his system, each one
with a single copy of that section.  If that's true, this is expected
behavior: Info does not examine DIR files it finds for repeated items,
it simply concatenates all the DIR files into a single DIR node.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> Date: Thu, 19 Sep 2002 22:09:51 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> It would seem to me that the first identical repetition is a bug.  It
> does not occur in Emacs21.2.90 on the same system.

How many DIR files do you have on your INFOPATH on that system, and
how many of those DIR files have the Texinfo section?

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Eli Zaretskii wrote:

   How many DIR files do you have on your INFOPATH on that system, and
   how many of those DIR files have the Texinfo section?

Transcript of an ielm run:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (getenv "INFOPATH")
nil
ELISP> Info-directory-list
("/usr/local/info/" "/usr/local/share/info/" "/usr/info/" "/usr/share/info/" "/usr/local/info/")

As you can see from this ielm run, my INFOPATH is nil.

The fist two identical sections occur in /usr/local/info/dir and
/usr/info/dir.  usr/local/info/ occurs twice in Info-directory-list,
but that does not seem to produce a third identical copy.  The third,
slightly different, version occurs in /usr/share/info/dir, which is a
symbolic link to etc/info-dir.  /usr/local/share/info is just an empty
directory.

All of this seems to explain my C-h i output.  I still do not
understand whether this is just a local problem with my own setup or a
problem with the Emacs CVS.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Maybe the repeated info sections could be due to the fact that I have
several Emacs versions installed: 21.1.90, 21.2.90, 21.3.50, all of
which I installed using "make install" in the "standard" places, and a
Red Hat 7.2 installed version of 20.7.

I guess that would explain the problem, as long as nobody else, who
has only the latest CVS installed, is seeing the problem.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Luc Teirlinck]

From my earlier message:

   I still do not understand whether this is just a local problem with
   my own setup or a problem with the Emacs CVS.

I sent two messages to emacs-devel, that got apparently received by
emacs-devel in reverse order.  This might be confusing.  As I pointed
out in my "other" message, I now am inclined to believe that it is
just a local problem, as long as nobody else is seeing the problem.
Sorry for the "false alarm" in that case.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> Date: Fri, 20 Sep 2002 17:07:27 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> Eli Zaretskii wrote:
> 
>    How many DIR files do you have on your INFOPATH on that system, and
>    how many of those DIR files have the Texinfo section?
> 
> Transcript of an ielm run:
> 
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (getenv "INFOPATH")
> nil
> ELISP> Info-directory-list
> ("/usr/local/info/" "/usr/local/share/info/" "/usr/info/" "/usr/share/info/" "/usr/local/info/")
> 
> As you can see from this ielm run, my INFOPATH is nil.

Sorry for inaccurate wording: Info-directory-list and INFOPATH are two
sources where Emacs gets the list of directories to search for DIR
files.  I should have mentioned both.

> The fist two identical sections occur in /usr/local/info/dir and
> /usr/info/dir.  usr/local/info/ occurs twice in Info-directory-list,
> but that does not seem to produce a third identical copy.  The third,
> slightly different, version occurs in /usr/share/info/dir, which is a
> symbolic link to etc/info-dir.  /usr/local/share/info is just an empty
> directory.
> 
> All of this seems to explain my C-h i output.

Indeed.

> I still do not
> understand whether this is just a local problem with my own setup or a
> problem with the Emacs CVS.

IMHO, it's a local problem on your machine.

Re: Emacs cvs newbie problems

[Richard Stallman]

    The fist two identical sections occur in /usr/local/info/dir and
    /usr/info/dir.  The third,
    slightly different, version occurs in /usr/share/info/dir, which is a
    symbolic link to etc/info-dir.

Can you try to track down how it came to be that these various different
dir files got installed?  Which versions of which packages installed them?

This is not a bug in info.el, but I wonder if it could merge these sections
rather than just putting them in side by side.

Re: Emacs cvs newbie problems

[Luc Teirlinck]

Richard Stallman wrote:

   Can you try to track down how it came to be that these various different
   dir files got installed?  Which versions of which packages installed them?

Yes.

ELISP> Info-directory-list
("/usr/local/info/" "/usr/local/share/info/" "/usr/info/"
"/usr/share/info/" "/usr/local/info/")

The dir file in /usr/local/info was installed (or updated) by
emacs-21.3.50.

/usr/local/share/info is an empty directory.

The dir file in /usr/info was installed by texinfo-4.2.

The dir file in /usr/share/info (a symlink to /etc/info-dir) came with
Red Hat 7.2.

I have the impression that any "dir" files installed by emacs-21.1.90
or 21.2.90 got overridden by emacs-23.3.50.

   This is not a bug in info.el, but I wonder if it could merge these sections
   rather than just putting them in side by side.

That might be more difficult than might appear at first.

What seems to complicate matters a lot is the fact that identical or
nearly identical sections, as well as individual entries, may have
different names.  

I have a section "Emacs" installed (or updated) by emacs-21.3.50 and a
nearly identical section "GNU Emacs" in the "dir" installed by
Red Hat 7.2.

I have entries:

* info standalone: (info-stnd).            Read Info documents without
  Emacs.

and:

* Standalone info program: (info-stnd).    Standalone Info-reading
  program.

in different "Texinfo documentation system" sections that lead to
exactly the same *info* buffer.

It would be relatively easy for me to hand correct my own messy
situation, but finding a good general solution seems difficult.

I do not know how frequently the problem I encountered occurs for
other people.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Sat, 21 Sep 2002, Luc Teirlinck wrote:

> I have the impression that any "dir" files installed by emacs-21.1.90
> or 21.2.90 got overridden by emacs-23.3.50.

That's probably true, as "make install" installs the DIR file which came 
with the distribution, and the place it puts that file does not depend on 
the Emacs version.

>    This is not a bug in info.el, but I wonder if it could merge these sections
>    rather than just putting them in side by side.
> 
> That might be more difficult than might appear at first.
> 
> What seems to complicate matters a lot is the fact that identical or
> nearly identical sections, as well as individual entries, may have
> different names.  

Right.  In general, it's the job of install-info to remove redundant 
sections, but it only does so for a single DIR file, the one whose file 
name it gets from the command-line arguments.

Re: Emacs cvs newbie problems

[Richard Stallman]

    The dir file in /usr/local/info was installed (or updated) by
    emacs-21.3.50.

    The dir file in /usr/share/info (a symlink to /etc/info-dir) came with
    Red Hat 7.2.

    The dir file in /usr/info was installed by texinfo-4.2.

This could be a problem we have to fix, an inconsistency between Emacs
and Texinfo.  Maybe Emacs should install into /usr/info if it has a
dir file in it.

Should Texinfo (and Emacs) install into /usr/share/info rather than /usr/info?

Could Emacs be smarter about merging the various Info dir files?

Karl, would you be willing to study the situation and make a
recommendation?

Re: Emacs cvs newbie problems

[Luc Teirlinck]

From Richard Stallman's message:

       The dir file in /usr/local/info was installed (or updated) by
       emacs-21.3.50.

       The dir file in /usr/share/info (a symlink to /etc/info-dir) came with
       Red Hat 7.2.

       The dir file in /usr/info was installed by texinfo-4.2.

   This could be a problem we have to fix, an inconsistency between Emacs
   and Texinfo.  Maybe Emacs should install into /usr/info if it has a
   dir file in it.

   Should Texinfo (and Emacs) install into /usr/share/info rather than
   /usr/info?

It is a while ago that I installed texinfo-4.2, but if I remember well
I might have overridden the place Texinfo got installed, which probably
explain the inconsistency.  Hence, the inconsistency is probably not a
problem with texinfo.

Sincerely,

Luc.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Sun, 29 Sep 2002, Luc Teirlinck wrote:

> >From Richard Stallman's message:
> 
>        The dir file in /usr/local/info was installed (or updated) by
>        emacs-21.3.50.
> 
>        The dir file in /usr/share/info (a symlink to /etc/info-dir) came with
>        Red Hat 7.2.
> 
>        The dir file in /usr/info was installed by texinfo-4.2.
> 
>    This could be a problem we have to fix, an inconsistency between Emacs
>    and Texinfo.  Maybe Emacs should install into /usr/info if it has a
>    dir file in it.
> 
>    Should Texinfo (and Emacs) install into /usr/share/info rather than
>    /usr/info?
> 
> It is a while ago that I installed texinfo-4.2, but if I remember well
> I might have overridden the place Texinfo got installed, which probably
> explain the inconsistency.

Right, Texinfo by default installs the Info files into /usr/local/info.

Re: Emacs cvs newbie problems

[Karl Berry]

    Should Texinfo (and Emacs) install into /usr/share/info rather than /usr/info?

Well, all programs install into $(infodir)/dir as far as I know.
I don't see anything to change there.

Until now, the definition of $(infodir) has been $(prefix)/info, but 
I gather we now will prefer $(datadir)/info.

    Could Emacs be smarter about merging the various Info dir files?

The answer to that seems to be yes.  If there are two dir entries which
both refer to the same filename(node), as with `emacs' in this case, I
can't see much point in including them both in the merged dir file,
since they're going to end up at the same place.  This would have fixed
Luc's problem.

I can imagine various other new features, but nothing that really seems
worth it.

Another part of the problem is the plethora of dircategories that are in
use.  Both the packagers and the maintainers tend to make up a new
category at the drop of a hat, and this results in the same dir entries
being repeated over and over again.

Luc, can you please send a shar file (or whatever) with all the dir
files on your system, so we have something to work with?

Thanks,
karl

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> Date: Mon, 30 Sep 2002 10:12:32 -0400
> From: karl@freefriends.org (Karl Berry)
> 
>     Could Emacs be smarter about merging the various Info dir files?
> 
> The answer to that seems to be yes.  If there are two dir entries which
> both refer to the same filename(node), as with `emacs' in this case, I
> can't see much point in including them both in the merged dir file,
> since they're going to end up at the same place.

The hard question is which one to choose...

Re: Emacs cvs newbie problems

[Karl Berry]

    The hard question is which one to choose...

My suggestion would be, whichever is in the earlier dir file in the dir
path.  I mean, if the dir path is /dir1:/dir2, then use the entry from
/dir1/dir in preference to one from /dir2/dir.

I don't think it really makes much difference, at least in Luc's case
they were all 100% identical anyway.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Mon, 30 Sep 2002, Karl Berry wrote:

>     The hard question is which one to choose...
> 
> My suggestion would be, whichever is in the earlier dir file in the dir
> path.

That won't be a bad strategy, IMHO.  However, the order of the 
directories in the search path might have nothing to do with dir files, 
it probably is more relevant to the order in which the user wants Info
files (i.e. the manuals themselves) to be found.  So we could be left
with a wrong section.

Re: Emacs cvs newbie problems

[Richard Stallman]

       This could be a problem we have to fix, an inconsistency between Emacs
       and Texinfo.  Maybe Emacs should install into /usr/info if it has a
       dir file in it.

       Should Texinfo (and Emacs) install into /usr/share/info rather than
       /usr/info?

    It is a while ago that I installed texinfo-4.2, but if I remember well
    I might have overridden the place Texinfo got installed, which probably
    explain the inconsistency.  Hence, the inconsistency is probably not a
    problem with texinfo.

That is good news, but we still have the question of /usr/share/info
vs /usr/info.  Which is a better default?

Re: Emacs cvs newbie problems

[Richard Stallman]

    Should Texinfo (and Emacs) install into /usr/share/info rather than /usr/info?

    Until now, the definition of $(infodir) has been $(prefix)/info, but 
    I gather we now will prefer $(datadir)/info.

Actually make-stds.texi already says it should be $(datarootdir)/info.
By default, both of them are, /usr/local/share/info.  However, 
If we want /usr/share/info, neither $(datadir) nor $(datarootdir)
will get us that.

    Another part of the problem is the plethora of dircategories that are in
    use.  Both the packagers and the maintainers tend to make up a new
    category at the drop of a hat, and this results in the same dir entries
    being repeated over and over again.

Would you like to develop a standard list of dircategory values?

Re: Emacs cvs newbie problems

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> That is good news, but we still have the question of /usr/share/info
> vs /usr/info.  Which is a better default?

/usr/share/info, I think -- it (1) makes sense [info files are `shareable']
(2) is what debian and other gnu/linux systems seem to use.

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Emacs cvs newbie problems

[Karl Berry]

    the order of the 
    directories in the search path might have nothing to do with dir files, 

I wasn't proposing using the search path (PATH).  I was proposing the
dir path (INFOPATH / Info-directory-list).

    So we could be left with a wrong section.

By `section' do you mean dircategory?  If so, dir entries in different
categories always have to be included in the merge.  At least I was
taking that as a given.

Thus:
1) if direntry A has the same (filename)nodename as direntry B,
2) and A and B have the same dircategory,
3) then include whichever of A and B belongs to the dir file earlier in
   the dir path.

I don't think any real information can be lost by this algorithm, all
the same entries will end up in the merged dir file, all the same info
files can be reached.  The only change will be the elimination of
(some) duplicates, as far as I can see.

Thanks,
k

Re: Emacs cvs newbie problems

[Karl Berry]

    /usr/share/info, I think -- it (1) makes sense [info files are `shareable']
    (2) is what debian and other gnu/linux systems seem to use.

Sorry, but I don't understand what we are discussing.

Surely the value for infodir should be the same in the emacs
distribution as it is in every other distribution -- namely
$(datarootdir)/info (or $(prefix)/info until datarootdir makes it into
autoconf).  And the default prefix should presumably be /usr/local for
emacs as it is for everything else.

Hopefully no one is really proposing hardwiring infodir as
/usr/share/info?!  Or making the default prefix be /usr?  That makes no
sense to me.

    If we want /usr/share/info ...

Why would we want this?  I am baffled.  What problem are we trying to
solve?  As far as I can see, everyone is happy already.  Packagers can
get what they want now (by setting prefix=/usr), so they are happy.  And
individual sysadmins can get what they want (by leaving prefix alone or
setting it to whatever their local site convention is), so they are
happy.

Am I missing something?

Re: Emacs cvs newbie problems

[Karl Berry]

    Would you like to develop a standard list of dircategory values?

Oh, I've been doing that since day 1, but that has little effect on what
people actually do in their texinfo files.  I write to various
maintainers about it when I have a chance, and they are usually
receptive, but it's a big job.

Re: Emacs cvs newbie problems

[Stefan Monnier]

>     Would you like to develop a standard list of dircategory values?
> 
> Oh, I've been doing that since day 1, but that has little effect on what
> people actually do in their texinfo files.  I write to various
> maintainers about it when I have a chance, and they are usually
> receptive, but it's a big job.

How about changing makeinfo to complain when the specified dircategory
is not among the few standard ones ?
BTW, looking at the TeXinfo doc I have it says:

  Here are some recommended `@dircategory' categories:

     GNU packages
     GNU programming tools
     GNU programming documentation
     GNU Emacs Lisp
     GNU libraries
     Linux
     TeX
     Individual utilities

I suggest we change `Linux' to `GNU/Linux' and change `GNU Emacs Lisp'
to `GNU Emacs' (or maybe `Emacs' which is what Emacs uses).
Also I don't understand the difference between
`GNU programming tools' and `GNU programming documentation'.


	Stefan

Re: Emacs cvs newbie problems

[Karl Berry]

    How about changing makeinfo to complain when the specified dircategory
    is not among the few standard ones ?

I think that would be too frustrating -- the problem is that there is
more than a few.  I wouldn't want to prejudge a maintainer's decision on
what category to use.

    I suggest we change `Linux' to `GNU/Linux' 

Yes.  Actually I just removed that category some time ago.

    and change `GNU Emacs Lisp'
    to `GNU Emacs' (or maybe `Emacs' which is what Emacs uses).

Well, my thought was that the main `Emacs' entry could be in `GNU
packages', and then all the manuals for the elisp addons would be `GNU
Emacs Lisp'.  Then the main emacs entry is not lost in the welter of
other emacs-related entries.  But I'm certainly not going to insist,
whatever you think best.

     Also I don't understand the difference between
    `GNU programming tools' and `GNU programming documentation'.

GNU packages: programs that any user might use
GNU programming tools: programs that only programmers use
GNU programming documentation: related documentation for programmers

As in:

GNU programming documentation
* GDB internals: (gdbint).      Debugger internals.
* Ld internals: (ldint).        GNU linker internals.
* Source config: (cfg-paper).   Some theory on configuring source packages.
* Stabs: (stabs).               Symbol table debugging information format.

GNU programming tools
* As: (as).                     Assembler.
* Autoconf: (autoconf).         Create source code configuration scripts
* Binutils: (binutils).         ar/copy/objdump/nm/size/strip/ranlib.
* Bison: (bison).               LALR(1) parser generator.
* CVS: (cvs).                   Concurrent versions system for source control.
* Cpp: (cpp).		        The GNU C preprocessor.
...

I'll see if I can come up with some more concrete recommendations and
put them in the manual.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> Date: Tue, 1 Oct 2002 10:13:42 -0400
> From: karl@freefriends.org (Karl Berry)
> 
>     the order of the 
>     directories in the search path might have nothing to do with dir files, 
> 
> I wasn't proposing using the search path (PATH).  I was proposing the
> dir path (INFOPATH / Info-directory-list).

I'm sorry for inaccuerate wording.  I was also talking about INFOPATH
(or its Emacs equivalent).

>     So we could be left with a wrong section.
> 
> By `section' do you mean dircategory?

No, I mean the @direntry menu entries.  That is, selecting the entries
from the DIR file found in the first directory on INFOPATH might leave
us with wrong entries.

> 1) if direntry A has the same (filename)nodename as direntry B,
> 2) and A and B have the same dircategory,
> 3) then include whichever of A and B belongs to the dir file earlier in
>    the dir path.
> 
> I don't think any real information can be lost by this algorithm

The text after (filename)nodename might be different, as well as the
menu entry name:

 * Foo: (foo)bar.     The GNU Foo program.

vs

 * Foobar: (foo)bar.  The One and Only GNU FooBar program.

(Not that this is crucial, but still...)

Re: Emacs cvs newbie problems

[Stefan Monnier]

>     How about changing makeinfo to complain when the specified dircategory
>     is not among the few standard ones ?
> 
> I think that would be too frustrating -- the problem is that there is
> more than a few.  I wouldn't want to prejudge a maintainer's decision on
> what category to use.

By `complain' I don't mean "raise an error".
It can be a gentle reminder pointing to the documentation.

>     and change `GNU Emacs Lisp'
>     to `GNU Emacs' (or maybe `Emacs' which is what Emacs uses).
> 
> Well, my thought was that the main `Emacs' entry could be in `GNU
> packages', and then all the manuals for the elisp addons would be `GNU
> Emacs Lisp'.  Then the main emacs entry is not lost in the welter of
> other emacs-related entries.  But I'm certainly not going to insist,
> whatever you think best.

The packages happen to be written in Lisp but are not related to Lisp,
they're related to Emacs, so I think `GNU Emacs' or `GNU Emacs packages'
would be better.


	Stefan

Re: Emacs cvs newbie problems

[Stefan Monnier]

> The text after (filename)nodename might be different, as well as the
> menu entry name:
> 
>  * Foo: (foo)bar.     The GNU Foo program.
> 
> vs
> 
>  * Foobar: (foo)bar.  The One and Only GNU FooBar program.

Since I mostly use `m <foo> RET' I think those two entries should simply
not be merged.  OTOH,

   * Foo: (foo)bar.     The GNU Foo program.
vs
   * Foo: (foo)baz.  The One and Only GNU FooBar program.

is up in the air.  I know that the second one is useless for `m Foo RET'
purposes, but maybe it works when moving to the entry and pressing RET
(or when double clicking) ?


	Stefan

Re: Emacs cvs newbie problems

[Karl Berry]

       * Foo: (foo)bar.     The GNU Foo program.
    vs
       * Foo: (foo)baz.  The One and Only GNU FooBar program.

No, these definitely should not be merged, IMHO.  bar != baz.

I agree, probably not to merge
* Foo: (foo)bar.
* Foobar: (foo)bar.
either.

However, I think these can be merged:
* Foo: (foo)bar.   GNU Foo.
* Foo: (foo)bar.   The one and only GNU Foo.
where only the commentary differs.  It's a judgement call, but personally I
think having one menu entry is better in this case, because it's fewer
entries in the dir file.  Most likely one or the other them will be the
older commentary, so why bother having it?

Finally, the most important (and most common) thing to merge would be
when everything is exactly the same:
* Foo: (foo)bar.   GNU Foo.
* Foo: (foo)bar.   GNU Foo.

That is the case that instigated the whole discussion.

Thanks,
karl

Re: Emacs cvs newbie problems

[Stefan Monnier]

>        * Foo: (foo)bar.     The GNU Foo program.
>     vs
>        * Foo: (foo)baz.  The One and Only GNU FooBar program.
> 
> No, these definitely should not be merged, IMHO.  bar != baz.

But note that `m Foo RET' will ignore the second one.
As said, it might still be usable by middle-clicking on it, but it's
still rather bogus overall anyway.  Which is why I wouldn't object to
merging such entries.

> However, I think these can be merged:
> * Foo: (foo)bar.   GNU Foo.
> * Foo: (foo)bar.   The one and only GNU Foo.
> where only the commentary differs.  It's a judgement call, but personally I
> think having one menu entry is better in this case, because it's fewer
> entries in the dir file.  Most likely one or the other them will be the
> older commentary, so why bother having it?

Agreed.


	Stefan

Re: Emacs cvs newbie problems

[Karl Berry]

    But note that `m Foo RET' will ignore the second one.

That's ok, since there are other ways of using it.
I think it makes the rules simpler not to merge them.

In practice, I don't think it matters, because I doubt there are any
such entries as these:
* Foo: (foo)bar.
* Foo: (foo)baz.
At least I've never seen any.  The preceding `Foo' is always different.

Re: Emacs cvs newbie problems

[Richard Stallman]

	Would you like to develop a standard list of dircategory values?

    Oh, I've been doing that since day 1, but that has little effect on what
    people actually do in their texinfo files.

Where is this list?  If the GNU Project releases it and publicizes
it as a standard, that might have some effect.

    How about changing makeinfo to complain when the specified dircategory
    is not among the few standard ones ?

For that to be reasonable, our list would have to be thoroughly
complete.  It seems unlikely a priori that we could make a list
that people never need to extend.  I think we should first try
putting

      Here are some recommended `@dircategory' categories:

	 GNU packages
	 GNU programming tools
	 GNU programming documentation
	 GNU Emacs Lisp
	 GNU libraries

Those don't seem like useful categories.  Useful categories relate to
jobs the user wants to find out how to do.

	 Linux

It may be that "Linux" is a useful category, but if we recommend
it, we should recommend it for a specific purpose, the kernel.

Even if we do recommend it for that, we take the risk that people
will misunderstand it and misuse it.

    I suggest we change `Linux' to `GNU/Linux'

GNU/Linux appears to be a useless category.  On a GNU/Linux system,
"GNU/Linux" as a category is equivalent to "everything".

Re: Emacs cvs newbie problems

[Richard Stallman]

    Curious. There's no single .el file in the HEAD with no-byte-compile in
    the first line, while there are about 10 (some of them automatically
    generated) with no-byte-compile in a Local Variables section.

Perhaps in some of these files there was a good reason -- such as,
some of them may be a few other local variables.  Or perhaps in some
of these files it would be better to put this in the first line.

Re: Emacs cvs newbie problems

[Richard Stallman]

    Thus:
    1) if direntry A has the same (filename)nodename as direntry B,
    2) and A and B have the same dircategory,
    3) then include whichever of A and B belongs to the dir file earlier in
       the dir path.

It seems reasonable to me.

Re: Emacs cvs newbie problems

[Richard Stallman]

    Sorry, but I don't understand what we are discussing.

We are discussing what should be the standard default for the Make
variable infodir.  Do we want it to be /usr/share/info or
/usr/local/share/info?

    Surely the value for infodir should be the same in the emacs
    distribution as it is in every other distribution

They should certaiuly be the same; the question is what the value
should be.  If we use $(datadir)/info, that will normally be
/usr/local/share/info.

Is that good?

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Tue, 1 Oct 2002, Stefan Monnier wrote:

>    * Foo: (foo)bar.     The GNU Foo program.
> vs
>    * Foo: (foo)baz.  The One and Only GNU FooBar program.
> 
> is up in the air.  I know that the second one is useless for `m Foo RET'
> purposes, but maybe it works when moving to the entry and pressing RET

Yes, RET with the cursor on an entry should select that entry.  IIRC, 
this already works like that.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Tue, 1 Oct 2002, Karl Berry wrote:

> However, I think these can be merged:
> * Foo: (foo)bar.   GNU Foo.
> * Foo: (foo)bar.   The one and only GNU Foo.
> where only the commentary differs.

I tend to agree, since the loss of information is minimal.

> Finally, the most important (and most common) thing to merge would be
> when everything is exactly the same:
> * Foo: (foo)bar.   GNU Foo.
> * Foo: (foo)bar.   GNU Foo.

Yes.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Tue, 1 Oct 2002, Karl Berry wrote:

> In practice, I don't think it matters, because I doubt there are any
> such entries as these:
> * Foo: (foo)bar.
> * Foo: (foo)baz.
> At least I've never seen any.

I have ;-).  Texinfo made such a change in the "makeinfo" entry somewhere 
circa v4.0 (because the name of the node which describes makeinfo's usage 
changed).  If a user had two DIR files, one with the old Texinfo group, 
the other with the new, that user would see such situation.

Re: Emacs cvs newbie problems

[Karl Berry]

    If we use $(datadir)/info, that will normally be
    /usr/local/share/info.

    Is that good?

In my opinion: Yes.  As I said, I strongly feel that $(infodir) should
depend on $(prefix) (via $(datadir) or $(datarootdir) or whatever), just
like everything else.  Not be hardwired to /usr/something.  I see many
disadvantages to hardwiring into /usr, and no advantages, as I discussed
in my last message.

Thanks,
karl

Re: Emacs cvs newbie problems

[Karl Berry]

    Where is this list?

It is in the Texinfo manual.  Since I made up the list at the same time
we added the @dircategory/@direntry feature, I figured it would be
better to get some experience with it before trying to promulgate
anything too widely as a standard.

    Those don't seem like useful categories.  Useful categories relate to
    jobs the user wants to find out how to do.

Well, I think they do.  Here was my thinking: if the user is a
programmer, then they are looking for programming tools, or libraries,
or documentation.  If the user is using emacs, then they might look for
Emacs packages; and if they don't use emacs, they have no interest in
emacs packages.  (Pretend `GNU Emacs Lisp' is just `Emacs', which is
what you actually use.)  If the user is not a programmer, then they're
interested in all the "other" packages.

Since you don't like those, can you give some specific examples of
the broad categories that you would prefer, and how maintainers should
choose categories?

FYI, here is the real list from my system, including numerous categories
from various packages I've installed on my system, such as gettext,
lilypond, and a2ps.  So you can get a sense of what maintainers are
actually doing.  (`Individual utilities' is important; it has an entry
for each program like cp/rm/sort/etc.  This is so people can say "info
cp" or whatever and get something useful.  There's also an entry for the
general manual -- coreutils or whatever.)

GNU Packages
Texinfo documentation system
Printing Tools
GNU programming tools
Emacs
GNU Gettext Utilities
GNU programming support
GNU libraries
GNU programming documentation
GNU organization
GNU music project
TeX
DOS 
Other things
Individual utilities

Any advice gratefully received ...

k

Re: Emacs cvs newbie problems

[Karl Berry]

    > * Foo: (foo)bar.
    > * Foo: (foo)baz.

    Texinfo made such a change in the "makeinfo" entry 

Well, silly me :).  I still think, though, that to make the rules for
merging as straightforward as possible, we should not merge these.  But
if there's strong sentiment otherwise, I don't exist.

Re: Emacs cvs newbie problems

[Richard Stallman]

    >        * Foo: (foo)bar.     The GNU Foo program.
    >     vs
    >        * Foo: (foo)baz.  The One and Only GNU FooBar program.
    > 
    > No, these definitely should not be merged, IMHO.  bar != baz.

    But note that `m Foo RET' will ignore the second one.
    As said, it might still be usable by middle-clicking on it, but it's
    still rather bogus overall anyway.  Which is why I wouldn't object to
    merging such entries.

The existence of such entries is in itself a sort of a problem;
it would be better not to merge them, so that the problem is visible
in the merged dir file.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> Date: Wed, 2 Oct 2002 09:36:15 -0400
> From: karl@freefriends.org (Karl Berry)
> 
>     > * Foo: (foo)bar.
>     > * Foo: (foo)baz.
> 
>     Texinfo made such a change in the "makeinfo" entry 
> 
> Well, silly me :).  I still think, though, that to make the rules for
> merging as straightforward as possible, we should not merge these.

Yes, I agree.

Re: Emacs cvs newbie problems

[Richard Stallman]

    GNU Packages
    Texinfo documentation system
    Printing Tools
    GNU programming tools
    Emacs
    GNU Gettext Utilities
    GNU programming support
    GNU libraries
    GNU programming documentation
    GNU organization
    GNU music project
    TeX
    DOS 
    Other things
    Individual utilities

TeX, DOS and Emacs seem like useful categories.  "Printing" would be a
good category, but the name "Printing tools" is not as good.

The others don't make any sense.  They are either too broad, or too
narrow, or they focus on the wrong distinctions (such as GNU vs
non-GNU or tools vs support).

Texinfo probably belongs in the TeX category, and in a category
called "Text Formatting".  Gettext belongs in "Internationalization".

Programming tools probably should be divided into
two categories, "Programming" and "Scripting".
Popular languages such as C, C++, Perl, Python, and Java
probably deserve categories too.

Do you see the logic now?  Imagine that you know vaguely what sort of
job you want to do but you don't know what programs there are to do
it.  What categories would be useful for you?

It's like choosing subject listings for the Subject catalog in a
library: you want them to be useful for people to find books they have
never heard of.  "GNU libraries" as a subject is analogous to "Random
House hardcovers"--not a useful subject classification.

Re: Emacs cvs newbie problems

[Richard Stallman]

	If we use $(datadir)/info, that will normally be
	/usr/local/share/info.

	Is that good?

    In my opinion: Yes.  As I said, I strongly feel that $(infodir) should
    depend on $(prefix) (via $(datadir) or $(datarootdir) or whatever), just
    like everything else.  Not be hardwired to /usr/something.

This means that on a system which comes with an Info directory
in /usr/info, our packages will by default not install into that
directory.  I think that is somewhat of a problem.  Can we find
a way to solve it?

Re: Emacs cvs newbie problems

[Eli Zaretskii]

On Wed, 2 Oct 2002, Richard Stallman wrote:

> This means that on a system which comes with an Info directory
> in /usr/info, our packages will by default not install into that
> directory.

I thought that on such a system, whoever configures and installs GNU 
packages should invoke configure with --infodir=/usr/info.

> I think that is somewhat of a problem.  Can we find
> a way to solve it?

We'd need a way to find the system Info directory.  The problem is 
actually even harder than that, since on at least some systems there
are several Info directories.

Re: Emacs cvs newbie problems

[Karl Berry]

    This means that on a system which comes with an Info directory
    in /usr/info, our packages will by default not install into that
    directory.  I think that is somewhat of a problem.  Can we find
    a way to solve it?

Hmm.  I don't understand why it's a problem any more than it's a problem
for binaries.  If one downloads the emacs tar.gz and does configure &&
make && make install, the binaries don't end up in /usr/bin.  This is a
feature, not a bug.  Same for info files.

The configure system allows for installers to choose where to put the
installed files, using the options Eli mentioned, or other ways.  This
is good, because /usr/info is just one of dozens of existing site
configurations.  I still don't see what we gain by somehow making one
particular install directory for one particular file type a special case
... ?

Re: Emacs cvs newbie problems

[Richard Stallman]

    > This means that on a system which comes with an Info directory
    > in /usr/info, our packages will by default not install into that
    > directory.

    I thought that on such a system, whoever configures and installs GNU 
    packages should invoke configure with --infodir=/usr/info.

Yes, that is what they should do to get correct results.
But lots of people will forget to do it.

Perhaps we can design a rule for choosingthe default for infodir
based on where info files already exist on the system.

    > I think that is somewhat of a problem.  Can we find
    > a way to solve it?

    We'd need a way to find the system Info directory.  The problem is 
    actually even harder than that, since on at least some systems there
    are several Info directories.

The existence of several Info directories is not a disaster, but it is
somewhat of a problem.  Avoiding that problem is the goal of this
discussion.  If all packages find the same right place to install
their Info files, we won't get multiple Info directories.

If there happen to be multiple Info directories already, it doesn't
matter tremendously which on a new file is installed in, as long as it
is installed in one of them and not in a new directory.  If all packages
avoid creating a new directory, then you will only have one.

This suggests that configure should find an existing Info directory
which is a good place to install, and use that as the default for
infodir.  If none is found, the default can be $(datadir)/info.

Do you see any problem with that idea?

Re: Emacs cvs newbie problems

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> This means that on a system which comes with an Info directory
> in /usr/info, our packages will by default not install into that
> directory.

As Karl Berry explained: that's a feature.  I don't want my own info
files end up in /usr; my local stuff belongs to /usr/local -- stuff
provided by the system belongs to /usr.  Thus using

    $(datadir)/info

is the solution (instead of the current default $(prefix)/info ).

> I think that is somewhat of a problem.

The "real" problem is, Emacs resp. info (the binary) will collaps
/usr/share/info/dir and /usr/local/share/info/dir into one and the same
TOC _unconditionally_.  Thus I cannot view the Emacs manual coming with
the system (21.2) and the one I installed on my own (21.3.50 in
/usr/local/...) at the same time easily.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Emacs cvs newbie problems

[Karl Berry]

    If there happen to be multiple Info directories already, it doesn't
    matter tremendously which on a new file is installed in, 

It doesn't matter from the point of view of info (which is a problem in
itself, as Karl E. points out), but it may matter very much from the
point of view of the sysadmin.

For example, I know of sites that install emacs 21.2 into
/tools/emacs-21.2, completely.  This can ease upgrades, etc.  If
configure went ahead and installed the emacs 21.2 info files into
/usr/local/info, that would defeat the purpose.

    The existence of several Info directories is not a disaster, but it is
    somewhat of a problem.

I disagree.  When several info directories exist, that is usually
exactly what the installer/sysadmin wants to have.  Trying to make
configure outguess the local sysadmin seems quite wrong (not to mention
impossible) to me.

In my view, the simple infodir=$(datarootdir)/info default we have now
is not broken, in any way.  Instead of changing that, I suggest (once
again) that we simply fix the dir merging as we have discussed so that
redundant entries are not included.  That is what gave rise to the
original bug report and all the ensuing discussion -- not the existence
of multiple dir files.

Re: Emacs cvs newbie problems

[Stefan Monnier]

> In my view, the simple infodir=$(datarootdir)/info default we have now
> is not broken, in any way.  Instead of changing that, I suggest (once
> again) that we simply fix the dir merging as we have discussed so that
> redundant entries are not included.  That is what gave rise to the
> original bug report and all the ensuing discussion -- not the existence
> of multiple dir files.

100% agreement.  It would be completely wrong to hard code anything
like "/usr" or "usr/info".


	Stefan

Re: Emacs cvs newbie problems

[Richard Stallman]

    As Karl Berry explained: that's a feature.  I don't want my own info
    files end up in /usr; my local stuff belongs to /usr/local -- stuff
    provided by the system belongs to /usr.

I am not convinced that Info files "belong" in these two places, but
let's suppose you have put Info files for installed packages in both
places.  (You can certainly do that if you want to.)

    The "real" problem is, Emacs resp. info (the binary) will collaps
    /usr/share/info/dir and /usr/local/share/info/dir into one and the same
    TOC _unconditionally_.

This merging is absolutely necessary.  Since both groups of packages
are available to an ordinary user, when person runs Info, an ordinary
user should see an Info dir that lists both groups of packages.

      Thus I cannot view the Emacs manual coming with
    the system (21.2) and the one I installed on my own (21.3.50 in
    /usr/local/...) at the same time easily.

The word "thus" is misleading; it implies that the merging
of the Info directories is solely responsible for this consequence.
I don't think that is true, and I think that it would be very hard
to avoid this consequence.

Re: Emacs cvs newbie problems

[Karl Berry]

    Do you see the logic now?  

I see the logic.  However, it will take a substantial amount of time to
come up with better categories for all the many manuals out there,
contact their maintainers, follow up to make sure the changes are made,
etc.  Can you post a request for a volunteer to do this?  If I did it,
I'd have no time to do anything else :).  I'll add it to the Texinfo
TODO file, too.

Thanks,
karl

Re: Emacs cvs newbie problems

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> I am not convinced that Info files "belong" in these two places, but
> let's suppose you have put Info files for installed packages in both
> places.  (You can certainly do that if you want to.)

It was meant as an example.  Or think about /usr/share/info/dir and
$HOME/usr/share/info/dir.

> This merging is absolutely necessary.  Since both groups of packages
> are available to an ordinary user, when person runs Info, an ordinary
> user should see an Info dir that lists both groups of packages.

This sounds as it might be desirable to accumulate entries.

> The word "thus" is misleading; it implies that the merging
> of the Info directories is solely responsible for this consequence.
> I don't think that is true, and I think that it would be very hard
> to avoid this consequence.

Why not providing two or more parts:

Manuals in $HOME/usr/share/info
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
* Emacs: ($HOME/usr/share/info/emacs).	The extensible self-documenting
                                          text editor (21.3.50).
* ... and more private docs


Manuals in /usr/share/info
+=+=+=+=+=+=+=+=+=+=+=+=+=
* Emacs: (emacs).	The extensible self-documenting text editor (21.2).
* ... other docs coming with the system 

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Fri, 04 Oct 2002 12:05:30 +0200
> 
> Thus I cannot view the Emacs manual coming with
> the system (21.2) and the one I installed on my own (21.3.50 in
> /usr/local/...) at the same time easily.

Being able to install several different versions of the same package
and get the right manual with each one of them is a separate problem,
not yet solved in the current Texinfo setup and code.  It is a hard
problem, since manuals include references to other manuals, and so
there could be dependencies between different versions of different
packages.  Whether DIR entries are or aren't merged is not going to
solve this.

The problem we were discussing in this thread is much narrower and
easier to solve.

Re: Emacs cvs newbie problems

[Eli Zaretskii]

> From: karl@freefriends.org (Karl Berry)
> Date: Fri, 4 Oct 2002 09:00:32 -0400
> 
> In my view, the simple infodir=$(datarootdir)/info default we have now
> is not broken, in any way.  Instead of changing that, I suggest (once
> again) that we simply fix the dir merging as we have discussed so that
> redundant entries are not included.

I agree.

Re: Emacs cvs newbie problems

[Richard Stallman]

    It doesn't matter from the point of view of info (which is a problem in
    itself, as Karl E. points out), but it may matter very much from the
    point of view of the sysadmin.

A sysadmin will able to specify the place to install Info files.
The issue is what to do for the default.

    I disagree.  When several info directories exist, that is usually
    exactly what the installer/sysadmin wants to have.

You seem to have in mind rather sophisticated installers.  Those will
be able to specify options to get whatever they want.  Many, though,
are not so sophisticated; for them, the defaults "just happen".
They are likely to get info files divided between /usr/share/info and
/usr/local/share/info without ever thinking about whether they wanted
that.

The person who reported this bug did not carefully choose to put
Info files in three places.  He chose one of the three, but the other two
just happened.

Re: Emacs cvs newbie problems

[Stefan Monnier]

> You seem to have in mind rather sophisticated installers.  Those will
> be able to specify options to get whatever they want.  Many, though,
> are not so sophisticated; for them, the defaults "just happen".
> They are likely to get info files divided between /usr/share/info and
> /usr/local/share/info without ever thinking about whether they wanted
> that.

And they'll get executables in both /usr/bin and /usr/local/bin.
Seems quite normal to me.


	Stefan

Re: Emacs cvs newbie problems

[Richard Stallman]

    Why not providing two or more parts:

    Manuals in $HOME/usr/share/info
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


    Manuals in /usr/share/info

The usual reason, today, why there are manuals in multiple
directories is because of incompatibilities between packages.
In other words, it is an accident.  The distinction is meaningless
and Info should try to pretend it did not happen.

If we can ever clear up these incompatibilities, if normally all the
files go in one directory, then perhaps multiple Info directories will
only occur when the person who installed the packages specifically
wants them.  Then your feature would become useful.

Re: Emacs cvs newbie problems

[Richard Stallman]

    I see the logic.  However, it will take a substantial amount of time to
    come up with better categories for all the many manuals out there,
    contact their maintainers, follow up to make sure the changes are made,
    etc.

Here is an idea: follow the categories of the Free Software Directory.

What do you think of that idea?  You won't have to make a table
of your own.

Re: Emacs cvs newbie problems

[Richard Stallman]

    > In my view, the simple infodir=$(datarootdir)/info default we have now
    > is not broken, in any way.  Instead of changing that, I suggest (once
    > again) that we simply fix the dir merging as we have discussed so that
    > redundant entries are not included.

Fixing dir merging sufficiently well would eliminate the problem,
I agree.  We can try to do that and see if the results are good.

Re: Emacs cvs newbie problems

[Richard Stallman]

    > They are likely to get info files divided between /usr/share/info and
    > /usr/local/share/info without ever thinking about whether they wanted
    > that.

    And they'll get executables in both /usr/bin and /usr/local/bin.
    Seems quite normal to me.

"Merging" of /usr/bin and /usr/local/bin by searching PATH works
very cleanly, so it is not a problem.  If merging Info directories
could work smoothly as that, it would not be a problem to have
multiple Info directories either.  We can aim for that, but I am
not confident that we will get there.

Re: Emacs cvs newbie problems

[Karl Berry]

    The usual reason, today, why there are manuals in multiple
    directories is because of incompatibilities between packages.
    In other words, it is an accident.

That is one reason.  But the main reason I personally have seen is not
accidental at all -- it is so sysadmins can keep locally installed
manuals separate from those installed with the system.  Otherwise, you
lose your local dir file entries when system upgrades are done.

Anyway, I'll work on changing standalone info to do the merging.
Hopefully someone here can fix info.el in emacs (which is far more
widely used).

Thanks,
k

Re: Emacs cvs newbie problems

[Karl Berry]

    Here is an idea: follow the categories of the Free Software Directory.

    What do you think of that idea?  You won't have to make a table
    of your own.

I think that's a fine idea in principle, and I'll change the Texinfo
manual to recommend this.  Thanks.

Did you have in mind using just the top level categories, or categories
at any level?  It almost would seem that we want to replicate that whole
structure in the dir file, but dir files aren't set up to allow such a
thing right now.

BTW, browsing around http://www.gnu.org/directory/, I am pretty baffled
by some of the categorizations.  I would have never have guess that diff
would be under "word processing", for example (although I can see why in
retrospect, using an unusual definition of the phrase).

Also, basic programs like cp/ls/mv fit are not listed except under `All
GNU Packages'.  Seems like there should be a category for ... what
... File Manipulation?  And it almost seems to me like `Miscellaneous'
should not exist -- it's against the principle of organizing packages
usefully in the first place.

At any rate, it will still take a lot more time than I can commit to
find where existing manuals fit into those categories, contact manual
authors, get them to make the changes, etc.  Perhaps someone out there
would like to volunteer.

Re: Emacs cvs newbie problems

[Stefan Monnier]

>     The usual reason, today, why there are manuals in multiple
>     directories is because of incompatibilities between packages.
>     In other words, it is an accident.
> 
> That is one reason.  But the main reason I personally have seen is not
> accidental at all -- it is so sysadmins can keep locally installed
> manuals separate from those installed with the system.  Otherwise, you
> lose your local dir file entries when system upgrades are done.

Also because those various dirs might be managed by different people
with different access rights.  The obvious example is with
/usr/info vs ~/info.


	Stefan

Re: Emacs cvs newbie problems

[Richard Stallman]

    Did you have in mind using just the top level categories, or categories
    at any level?

Either one, whichever seems appropriate.

		   It almost would seem that we want to replicate that whole
    structure in the dir file, but dir files aren't set up to allow such a
    thing right now.

It is not immediately obvious how one would do that.  With node
structure?