emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: improve gud-gdb completion


From: Michael Welsh Duggan
Subject: Re: improve gud-gdb completion
Date: Thu, 29 Jul 2021 21:10:57 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Michael Welsh Duggan <mwd@md5i.com> writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> I'd like to improve completion in gud-gdb.
>>>
>>> Currently, it completes on names in the buffer being debugged, but it
>>> doesn't include "." in the name, so if I'm trying to print
>>> "Incremental_Parser.Parse_Errors.Length", it only completes to
>>> "Incremental_Parser".
>>>
>>> However, I can't figure out exactly what elisp code is harvesting names
>>> from the buffer.
>>>
>>> TAB is bound to completion-at-point.
>>>
>>> completion-at-point-functions is
>>> (gud-gdb-completion-at-point comint-completion-at-point t)
>>>
>>> (default-value 'completion-at-point-functions) is
>>> (tags-completion-at-point-function)
>>>
>>> None of those completion functions look at the text in buffers.
>>>
>>> What am I missing?
>>
>> Are you certain that it looks at the text in buffers at all?  If you
>> look at gud-gdb-completions, you'll see that it uses gdb's completion
>> mechanism based on symbols in the binary.
>
> It finds names from my code; "Incremental_Parser" above.
>
> I found a workaround by replacing the completion with hippie-expand, but
> I'd still like to understand how the original configuration works.

I'm afraid I don't understand.  If you are debugging a binary that
contains the "Incremental_Parser" symbol, then gdb knows that, and its
completion mechanism returns that.  It's the same mechanism used by gdb
when run outside of Emacs.

Your statement says "it completes on names in the buffer being
debugged."  That would imply that it does not complete names that are
from other files (not in the buffer where the $pc is).  But that is not
the case, no?

-- 
Michael Welsh Duggan
(md5i@md5i.com)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]