[patch#2 2/6] set auto-load * main part

[Eli Zaretskii]

> Date: Tue, 3 Apr 2012 20:33:01 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> > > +@node Auto-loading
> > > +@section Automatically loading associated files
> > 
> > "@cindex auto-loading" would be good here.
> 
> Done.  Therefore also changed now:
> 	@node Python Auto-loading
> 	@subsection Python Auto-loading
> 	@cindex auto-loading, Python
> 	->
> 	@cindex Python auto-loading, Python

Do we really need "Python" twice?

> > I suggest "... to prevent @value{GDBN} from reading any auto-loaded files"
> > instead.
> 
> I think the meaning is not right now.
> 
> There are three categories of files:
> 
> 1. /etc/gdbinit (system gdbinit) and ~/.gdbinit:
>    They can be disabled only by -nx.
> 2. Current directory .gdbinit
>    They can be disabled either by -nx or by 'set auto-load local-gdbinit no'.
> 3. Files like objfile-gdb.py or libthread_db.so.1
>    These can be disabled only by 'set auto-load no' (or more specific variants).
> 
> There exists currently no 'set auto-load system-gdbinit'
> or 'set auto-load home-gdbinit' so the option -nx still needs to be used in
> some cases.
> 
> Using -nx will not disable for example the objfile-gdb.py loading.
> 
> The current paragraph
> 
> # Be aware that system init file (@pxref{System-wide configuration})
> # and init files from your home directory (@pxref{Home Directory Init File})
> # still get read still get read (as they come from generally trusted
> # directories).  You could use also the @ref{-nx} option to prevent @value{GDBN}
> # from reading any auto-loaded files instead.
> 
> IMO says that -nx will disable even objfile-gdb.py, libthread_db.so.1 etc.
> auto-loading.  Or at least it is ambiguous in such way.

Point taken, but then what _did_ you mean by "very every"?

> 
> 
> > > +@smallexample
> > > +(gdb) info auto-load
> > > +gdb-scripts:  Loaded  Script                                                                 
> > > +Yes     /home/user/gdb/gdb-gdb.rc                         
> > 
> > This is a strange layout, and I'm quite sure it will look wrong in
> > Info (as the trailing whitespace won't do what you think).  Can you
> > show how this display is supposed to look like on the screen?
> 
> The trailing spaces are fixed now.  (Trailing spaces appear in GDB output in
> general but that is really outside of the scope of this patchset.)
> 
> The table header was not properly aligned for "info auto-load" while it was
> right for the specific commands like "info auto-load gdb-scripts".  The code is
> no longer much nice (introduced there #define INFO_AUTO_LOAD hack) but I agree
> the layout looks much better now.
> 
> Fixed therefore also the doc:
> 
> @smallexample
> (gdb) info auto-load
> gdb-scripts:  
> Loaded  Script
> Yes     /home/user/gdb/gdb-gdb.gdb
> libthread-db:  No auto-loaded libthread-db.
> local-gdbinit:  Local .gdbinit file "/home/user/gdb/.gdbinit" has been loaded.
> python-scripts:  
> Loaded  Script
> Yes     /home/user/gdb/gdb-gdb.py
> @end smallexample
> 
> 
> > > +@multitable {@xref{dotdebug_gdb_scripts section}.} {See @ref{set auto-load python-scripts}}
> > > +@item @xref{objfile-gdb.py file}.
> > > +@tab See @ref{set auto-load python-scripts}.
> > 
> > Does this table with 2 cross-references on each line look good in the
> > Info manual?
> 
> IMO it looks great:
> 
> *Note objfile-gdb.py file::.            See *note set auto-load python-scripts::.
> *Note objfile-gdb.gdb file::.           See *note set auto-load gdb-scripts::.
> *Note dotdebug_gdb_scripts section::.   See *note set auto-load python-scripts::.
> *Note Current Directory Init File::.    See *note set auto-load local-gdbinit::.
> *Note libthread_db.so.1 file::.         See *note set auto-load libthread-db::.
> 
> That "Note" and "note" are excessive there but I could not get rid of them.
> I wanted to have there something like @menu but @menu is very special and
> I cannot have arbitrary number of @menus inside the @node, moreover to
> reference arbitrary @nodes in the document.  So I found @multitable to be the
> most close to @menu one can get.
> 
> It looks even slightly better in PDF.

OK, fine with me.