From: Eli Zaretskii <eliz@gnu.org>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: gdb-patches@sourceware.org, tom@tromey.com
Subject: Re: [PATCH 0/7] Adding startup files to GDB
Date: Thu, 08 Oct 2020 09:56:49 +0300 [thread overview]
Message-ID: <83d01t8atq.fsf@gnu.org> (raw)
In-Reply-To: <cover.1601927355.git.andrew.burgess@embecosm.com> (message from Andrew Burgess on Wed, 7 Oct 2020 21:05:04 +0100)
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> Date: Wed, 7 Oct 2020 21:05:04 +0100
> Cc: Tom Tromey <tom@tromey.com>
>
> This series introduces a new set of command line options and config
> files that can be read very early during the startup process, these
> files/command line flags can then be used to control the very early
> actions that would otherwise not be user controllable.
Even after I've read the documentation parts of the entire series
(which was confusing due to the docs being dispersed between the
messages, and the basic issue with email that you cannot ensure the
order in which the messages wind up in the addressee's inbox), I must
say that I don't understand why we need to expose the startup settings
as normal user options changeable during a session. Since changing
those settings during a session is useless, why have them as options
at all? We could simply honor them as "options" only in the startup
files, and do away with the auto-saving feature. After all, how hard
is it for a developer who uses GDB to debug his/her programs to start
up an editor and edit the startup file? It sounds like much ado about
nothing to me. FWIW.
Thanks.
next prev parent reply other threads:[~2020-10-08 6:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 20:05 Andrew Burgess
2020-10-07 20:05 ` [PATCH 1/7] Add get_standard_config_dir function Andrew Burgess
2020-10-07 20:05 ` [PATCH 2/7] gdb: use get_standard_config_dir when looking for .gdbinit Andrew Burgess
2020-10-08 6:52 ` Eli Zaretskii
2020-11-02 10:20 ` Andrew Burgess
2020-10-22 19:07 ` Tom Tromey
2020-11-09 13:52 ` Tom Tromey
2020-11-09 13:55 ` Tom Tromey
2020-10-07 20:05 ` [PATCH 3/7] gdb: new function to wrap up executing command line scripts/commands Andrew Burgess
2020-10-08 15:25 ` Aktemur, Tankut Baris
2020-11-02 9:48 ` Andrew Burgess
2020-10-22 19:08 ` Tom Tromey
2020-10-07 20:05 ` [PATCH 4/7] gdb: process startup files and startup command line options Andrew Burgess
2020-10-08 6:28 ` Eli Zaretskii
2020-10-07 20:05 ` [PATCH 5/7] gdb: add mechanism to auto-save startup options Andrew Burgess
2020-10-08 6:36 ` Eli Zaretskii
2020-10-07 20:05 ` [PATCH 6/7] Let the user control the startup style Andrew Burgess
2020-10-08 6:40 ` Eli Zaretskii
2020-10-07 20:05 ` [PATCH 7/7] Add "set startup-quietly" Andrew Burgess
2020-10-08 6:44 ` Eli Zaretskii
2020-10-08 6:56 ` Eli Zaretskii [this message]
2020-10-22 19:02 ` [PATCH 0/7] Adding startup files to GDB Tom Tromey
2020-10-28 15:29 ` Andrew Burgess
2021-01-11 16:45 ` Andrew Burgess
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=83d01t8atq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).