diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-10-26 00:08:46 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2022-02-14 09:53:04 +0000 |
commit | 7b8c55afd07abf1e2e4efbeca4b9a614ce8d4e1e (patch) | |
tree | 894941d444cc0c4167f48dd18ed1c688e6a9b6b6 /gdb/language.h | |
parent | e867795e8bcd6571c785e5e1d872fff0a5c7b290 (diff) | |
download | fsf-binutils-gdb-7b8c55afd07abf1e2e4efbeca4b9a614ce8d4e1e.zip fsf-binutils-gdb-7b8c55afd07abf1e2e4efbeca4b9a614ce8d4e1e.tar.gz fsf-binutils-gdb-7b8c55afd07abf1e2e4efbeca4b9a614ce8d4e1e.tar.bz2 |
gdb/python: move styling support to gdb.styling
This commit moves the two Python functions that are used for styling
into a new module, gdb.styling, there's then a small update in
python.c so GDB can find the functions in their new location.
The motivation for this change is purely to try and reduce the clutter
in the top-level gdb module, and encapsulate related functions into
modules. I did ponder documenting these functions as part of the
Python API, however, doing so would effectively "fix" the API, and I'm
still wondering if there's improvements that could be made, also, the
colorize function is only called in some cases now that GDB prefers
libsource-highlight, so it's not entirely sure how this would work as
part of a user facing API.
Still, despite these functions never having been part of a documented
API, it is possible that a user out there has overridden these to, in
some way, customize how GDB performs styling. Moving the function as
I propose in this patch could break things for that user, however,
fixing this breakage is trivial, and, as these functions were never
documented, I don't think we should be obliged to not break user code
that relies on them.
Diffstat (limited to 'gdb/language.h')
0 files changed, 0 insertions, 0 deletions