From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org, dje@google.com
Subject: Re: [patch+7.5] auto-load: User conveniences suggested by Doug Evans
Date: Fri, 24 Aug 2012 16:11:00 -0000 [thread overview]
Message-ID: <20120824161059.GC7200@host2.jankratochvil.net> (raw)
In-Reply-To: <83k3wsb0da.fsf@gnu.org>
On Tue, 21 Aug 2012 19:50:25 +0200, Eli Zaretskii wrote:
> > + if (!advice_printed)
> > + {
> > + const char *homedir = getenv ("HOME");
> > + char *homeinit;
> > +
> > + if (homedir == NULL)
> > + homedir = "$HOME";
>
> This should fall back on $USERPROFILE or on $APPDATA on MS-Windows if
> $HOME is not defined. $USERPROFILE/$APPDATA are Windows equivalents
> of $HOME, but some Windows users (including yours truly) set $HOME to
> another directory (e.g., I don't like having my precious files on a
> system disk, because disasters strike there more frequently).
GDB main.c get_init_files does just:
homedir = getenv ("HOME");
So if getenv ("HOME") does not work GDB will not find such .gdbinit file
anyway. GDB maybe should do on MS-Windows also getenv ("USERPROFILE") etc.
but that is an unrelated issue needing a fix in main.c get_init_files first.
That part
if (homedir == NULL)
homedir = "$HOME";
may apply for MinGW but it tries to suggest you should 'set HOME c:\' for
example first. It is very MinGW specific problem. Any change here without
change in main.c get_init_files does not make sense.
> > + printf_filtered (_("\
> > +To enable execution of this file add \"add-auto-load-safe-path %s\" \
> > +line to \"%s\".\n\
>
> Suggest to move the "add-auto-load-safe-path" part to a new line,
> because the file name displayed after that will probably overflow the
> terminal line.
Even the line "add-auto-load-safe-path %s" itself may and will overflow the
terminal line. I do not find it such a problem, any terminal wraps lines and
most terminals nowadays are several times wider than 80 columns so I do not
think it makes sense to artifically wrap lines for them. If the user wants
the output more narrow let she narrow her terminal.
> > + scripts_directory_help = xstrprintf (_("\
> > +Automatically loaded %s%s%sGDB scripts\n\
> > +(named OBJFILE%s) are located in one of the directories listed by this\n\
> > +option.\n\
> > +This option is ignored for the kinds of scripts \
> > +having 'set auto-load ... off'.\n\
> > +Directories listed here need to be present also \
> > +in the 'set auto-load safe-path'\n\
> > +option."),
>
> Here, the lines are unnecessarily too short, IMO.
I think there should be some clear decision what should the GDB output conform
to. In this and the paragraph above we have exactly opposite opinions whether
to wrap the text or not.
My opinion:
So far I believe constant text should be formatted to 80 columns, which is
terrible to read but it should conform to GNU Coding Style like the source
does. But when there is some variable text (%s) contained therein one cannot
expect how the variable text is wide so one can leave it wide enough.
> > -Set the list of directories from which it is safe to auto-load files."), _("\
> > -Show the list of directories from which it is safe to auto-load files."), _("\
> > +Set the list of paths from which it is safe to auto-load files."), _("\
> > +Show the list of paths from which it is safe to auto-load files."), _("\
>
> Why "paths" instead of directories? GNU Coding Standards frown on
> using "paths" with this semantics.
>
> If the problem is that these can be both files and directories,
Yes.
> let's say "list of files and directories that are safe for auto-loading".
OK. I hope you are fine with "path" in the second part:
-for the 'set auto-load ...' options. Each directory can be also shell\n\
+for the 'set auto-load ...' options. Each path entry can be also shell\n\
wildcard pattern; '*' does not match directory separator.\n\
Thanks,
Jan
next prev parent reply other threads:[~2012-08-24 16:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 14:44 Jan Kratochvil
2012-08-21 17:50 ` Eli Zaretskii
2012-08-24 16:11 ` Jan Kratochvil [this message]
2012-08-24 18:15 ` Eli Zaretskii
2012-09-09 8:53 ` Jan Kratochvil
2012-09-09 17:26 ` Eli Zaretskii
2012-09-09 17:55 ` Jan Kratochvil
2012-09-09 18:09 ` Eli Zaretskii
2012-08-22 15:46 ` Pedro Alves
2012-08-24 15:13 ` Jan Kratochvil
2012-08-24 15:17 ` Pedro Alves
2012-08-24 15:19 ` Eli Zaretskii
2012-08-24 15:28 ` Pedro Alves
2012-08-24 15:31 ` Pedro Alves
2012-08-24 15:43 ` Jan Kratochvil
2012-08-24 17:56 ` Eli Zaretskii
2012-08-24 18:01 ` Jan Kratochvil
2012-08-24 18:26 ` Eli Zaretskii
2012-08-27 18:02 ` Pedro Alves
2012-08-27 18:12 ` Jan Kratochvil
2012-09-09 9:02 ` Jan Kratochvil
2012-09-10 11:29 ` Pedro Alves
2012-09-10 11:47 ` Jan Kratochvil
2012-09-10 13:06 ` Pedro Alves
2012-09-10 15:28 ` Jan Kratochvil
2012-09-17 18:29 ` [commit+7.5] " Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120824161059.GC7200@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox