From: Pedro Alves <palves@redhat.com>
To: chet.ramey@case.edu, Yury Gribov <y.gribov@samsung.com>,
bug-readline@gnu.org
Cc: Vyacheslav Barinov <v.barinov@samsung.com>,
Yury Usishchev <y.usishchev@samsung.com>,
Doug Evans <dje@google.com>,
"gdb@sourceware.org" <gdb@sourceware.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [Bug-readline] [PATCH] Enable visibility annotations
Date: Thu, 14 Apr 2016 15:19:00 -0000 [thread overview]
Message-ID: <570FB4FB.7090002@redhat.com> (raw)
In-Reply-To: <570FB04D.2060107@case.edu>
[gdb list, plus a couple people]
See https://lists.gnu.org/archive/html/bug-readline/2016-04/msg00006.html
(note that ml archive only refreshes every 30 mins...)
On 04/14/2016 03:59 PM, Chet Ramey wrote:
> On 4/14/16 6:47 AM, Pedro Alves wrote:
>
>> FYI, this is probably doing to break (at least) gdb against system
>> readline. gdb relies on accessing a few private readline symbols... :-/
>>
>> E.g.:
>>
>> tui/tui-io.c:437: extern int _rl_echoing_p;
>> completer.c:1677: extern int _rl_complete_mark_directories;
>> completer.c:1770:extern int _rl_completion_prefix_display_length;
>> completer.c:1771:extern int _rl_print_completions_horizontally;
>>
>> Unless/until someone fixes these and adds the missing public APIs
>> to readline,
>
> These aren't exactly the result of `missing public APIs'. echoing_p is
> a saved value indicating whether or not the terminal flags readline
> inherits include ECHO -- something an application can easily check for
> itself.
It's not that GDB wants to do something with the value. It's that
when gdb enables/disables its TUI/curses mode (c-a x), it needs to
save/restore that variable, here:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/tui/tui-io.c;h=18c648c08fdbe9a8f7d04c406c6a99e9149ca295;hb=2d059a33d890c017c8105b102a6b56ccbd6128b2#l426
That's quite old code. This gdb commit:
commit cc88a640ca1d0356c5feb40bb48869bab5a2bdce
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
AuthorDate: Wed May 11 23:38:44 2011 +0000
Imported readline 6.2, and upstream patch 001.
(That's gdb's built-in fallback readline copy, which is
discouraged in favor of the system one.)
Did:
void
tui_setup_io (int mode)
{
- extern int readline_echoing_p;
-
+ extern int _rl_echoing_p;
+
So looks like at some point readline_echoing_p was renamed
to _rl_echoing_p?
And that readline_echoing_p referencing code was added back in 2001 ...:
a198b876 gdb/tui/tuiIO.c (Stephane Carrez 2001-07-21 19:56:54 +0000 506) void
a198b876 gdb/tui/tuiIO.c (Stephane Carrez 2001-07-21 19:56:54 +0000 507) tui_setup_io (int mode)
a198b876 gdb/tui/tuiIO.c (Stephane Carrez 2001-07-21 19:56:54 +0000 508) {
a198b876 gdb/tui/tuiIO.c (Stephane Carrez 2001-07-21 19:56:54 +0000 509) extern int readline_echoing_p;
a198b876 gdb/tui/tuiIO.c (Stephane Carrez 2001-07-21 19:56:54 +0000 510)
I haven't tried to remove that and see what breaks.
> The others are values for settable variables and should be retrieved
> using rl_variable_value (variable_name). Since it returns a string,
> you can use the public macro RL_BOOLEAN_VARIABLE_VALUE to turn it into
> an int.
The GDB commit that added those was:
commit 82083d6dbbc0b2f6a76095582c6e7ffb3e06432a
Author: Doug Evans <xdje42@gmail.com>
AuthorDate: Sat Jan 31 14:11:54 2015 -0800
Unify CLI/TUI interface to readline tab completion.
This copies a lot of code from readline, but this is temporary.
Readline currently doesn't export what we need.
The plan is to have something that has been working for awhile,
and then we'll have a complete story to present to the readline
maintainers.
This is again about the curses mode (TUI).
Doug, could you comment?
> Bash doesn't use any _rl_ readline symbols, so I know it can be done.
Thanks,
Pedro Alves
next parent reply other threads:[~2016-04-14 15:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <570F38DD.1030703@samsung.com>
[not found] ` <570F3C7E.30005@samsung.com>
[not found] ` <570F7554.7070901@redhat.com>
[not found] ` <570FB04D.2060107@case.edu>
2016-04-14 15:19 ` Pedro Alves [this message]
2016-04-18 18:16 Doug Evans
2016-04-20 6:02 ` Yury Gribov
2016-04-20 9:22 ` Pedro Alves
2016-04-20 9:45 ` Yury Gribov
2016-04-20 10:19 ` Pedro Alves
2016-04-20 10:55 ` Yury Gribov
2016-04-20 15:30 ` Chet Ramey
2016-04-20 21:16 ` Chet Ramey
2016-04-22 14:43 ` Pedro Alves
2016-04-22 15:25 ` Chet Ramey
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=570FB4FB.7090002@redhat.com \
--to=palves@redhat.com \
--cc=bug-readline@gnu.org \
--cc=chet.ramey@case.edu \
--cc=dje@google.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=v.barinov@samsung.com \
--cc=y.gribov@samsung.com \
--cc=y.usishchev@samsung.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