bug#39179: 27.0.50; [PATCH] Add filter to gdb-mi register buffer

[Yuan Fu]

> On Feb 1, 2020, at 2:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 31 Jan 2020 18:08:18 -0500
>> Cc: 39179@debbugs.gnu.org
>> 
>>> I'm not sure it's a good idea to implement this as a button on the
>>> header-line.  Such buttons are for frequent operations, and also have
>>> the disadvantage of being unavailable on TTY frames.  What are the
>>> chances users will need to redefine the register patters frequently
>>> enough to justify the button?  Wouldn't it be much easier to have a
>>> defcustom whose value users could interactively modify as needed?
>> 
>> I mainly use it to display only the registers I care about, say, all
>> the *dx registers (rdx, edx, dx) or all the r** registers (rdx, rsi,
>> etc).
> 
> I understand, but why wouldn't a simple defcustom do this job?  A list
> of registers to display is a simple thing, no?

My main concern is that defcustom wouldn’t be as convenient as the current one. 
Right now I only need `f + .*dx` and I’m good to go, whereas defcustom I need 
to go to customize and configure there, and come back.


>> And that depends on the program you are working on.
> 
> Really?  In what way?  I could only understand why you'd like to see
> FP registers in some programs, but not in others.  But other than
> that, why would you want to see this or that register?  Are you
> frequently debugging on the machine language level?

Honestly I only used this for the bomb lab in my CS course last semester where 
we need to debug assembly code. So if you think in real life scenarios we don’t 
really need this _quick_ filtering and customize will cut it. I’m fine with 
that too. Is your main reason of objection the (unnecessary) complexity of the 
code?

>> The main motivation behind this patch is that, currently the register buffer 
>> simply displays all the possible registers (153 on my machine), and tracking 
>> on some of them is very hard (scrolling back and forth, very annoying).
> 
> Then perhaps we should allow reordering the registers instead of
> filtering their list, so that registers you want to see are at the
> beginning?

That would be more complex that just filtering IMO. 

> 
>> So this feather is a session-based quick filtering for interesting 
>> registers, I don’t think defcustom makes it better.
> 
> Why don't you think a defcustom will do?

In the “quick” aspect (as I described above).

> 
>> +(defcustom gdb-registers-enable-filter nil
>> +  "If t, enable register name filter in register buffer."
>> +  :local t
>> +  :type 'boolean
>> +  :group 'gdb-buffers
>> +  :version "27.1")
> 
> This should be "28.1", not "27.1".
> 
>> +(defcustom gdb-registers-filter-pattern-list nil
>> +  "Registers that are displayed in register buffer.
>> +
>> +Should be a list.  Registers whose name can match
>> +any of the regexps in the list is displayed."
>                                  ^^
> "are"
> 
>> +  :local t
>> +  :type 'list
>> +  :group 'gdb-buffers
>> +  :version "28.1")
>> +
>> (defvar gdb-debug-log nil
>>   "List of commands sent to and replies received from GDB.
>> Most recent commands are listed first.  This list stores only the last
>> @@ -4238,6 +4256,53 @@ gdb-frame-locals-buffer
>>  'gdb-registers-mode
>>  'gdb-invalidate-registers)
>> 
>> +(defun gdb-header-click-event-handler (function)
>> +  "Return a function that handles clicking event on gdb header buttons.
> 
> This doesn't really return a function, it calls it, right?
> 
> But before we discuss the particular code, let's please first agree on
> the design, OK?

That’s ideal.

Thanks,
Yuan