GNU bug report logs - #66575
[PATCH] Gud lldb support

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 13:21:41 +0200

17 okt. 2023 kl. 12.03 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

> Hm.  I'd rather see someone run lldb on Windows, and tell us if it even
> prints absolute file names.  It doesn't seem to do that on macOS.

So it seems. Odd. All right, let's use the simple pattern for now.
But doesn't this severely limit the ability of Emacs to locate the source file?
Surely there must be a way to retrieve the directory?

> I've thought about doing that as an initialization, but then it would
> have to be manually undone once lldb is running, since .lldbinit is
> loaded first, AFAIK, if enabled (default = no), which one could
> suppress and load it later, but that might also not be what the user
> wants. And so on...

Would you please explain this slowly to someone who's even less alert than usual this morning?

I got as far as understanding that the commands turn off the emission of source lines around the stopping position. Fine, and this is in general what we want if the source position is shown in an Emacs window.
But the user may have fine reasons for wanting to run lldb outside Emacs from time to time, and would then probably prefer the source lines in that case.

(Besides, I often don't see the position being tracked in a source buffer with your patch. Is this a matter of missing directory in the stop text?)

And here's a completely unrelated problem: the lldb command-line provides tab-completion on which I rely a lot as the command set is vast and my knowledge of it is spotty. Could it be provided in Emacs?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.