unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Welsh Duggan <mwd@md5i.com>
To: Stephen Leake <stephen_leake@stephe-leake.org>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: improve gud-gdb completion
Date: Thu, 29 Jul 2021 21:10:57 -0400	[thread overview]
Message-ID: <87y29ovc66.fsf@md5i.com> (raw)
In-Reply-To: <86fsvwofwz.fsf@stephe-leake.org> (Stephen Leake's message of "Thu, 29 Jul 2021 16:31:56 -0700")

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	other threads:[~2021-07-30  1:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 14:13 improve gud-gdb completion Stephen Leake
2021-07-28 14:50 ` Michael Welsh Duggan
2021-07-29 23:31   ` Stephen Leake
2021-07-30  1:10     ` Michael Welsh Duggan [this message]
2021-07-30 18:51       ` Stephen Leake

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y29ovc66.fsf@md5i.com \
    --to=mwd@md5i.com \
    --cc=emacs-devel@gnu.org \
    --cc=stephen_leake@stephe-leake.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).